Documentation Dotclear 2.6:resources

2.6:resources:authentication

Wed, 16 Oct 2013 09:56:41 +0200

	Version actuelle
Ligne 1:	Ligne 1:
	+	====== Authentification externe ======

	+	Dotclear 2 stocke par défaut les utilisateurs et leurs mots de passe dans sa propre base de données. Le processus d'authentification passe donc tout naturellement par là. Ceci dit, il peut être utile d'accéder à une autre source de données pour procéder à l'authentification. Nous allons voir que Dotclear 2 le permet assez facilement.
	+
	+	===== Préambule =====
	+
	+	Dotclear 2 permet de spécifier dans sa configuration une constante définissant le nom de la classe qui sera utilisée pour le processus d'authentification.
	+
	+	Il suffit de définir la constante DC_AUTH_CLASS et lui donner le nom d'une classe que vous aurez créée.
	+
	+	===== Une nouvelle classe d'authentification =====
	+
	+	Au même niveau que notre fichier de configuration, nous allons créer un fichier nommé class.auth.php qui contiendra tout simplement le code suivant :
	+
	+	<code php>
	+	class myDcAuth extends dcAuth
	+	{
	+	}
	+	</code>
	+
	+	Enfin, dans le fichier de configuration de Dotclear, nous ajoutons ces lignes à la fin :
	+
	+	<code php>
	+	$__autoload['myDcAuth'] = dirname(__FILE__).'/class.auth.php';
	+	define('DC_AUTH_CLASS','myDcAuth');
	+	</code>
	+
	+	À ce stade, notre installation de Dotclear doit continuer à fonctionner. Pour l'instant nous avons simplement changé la classe d'authentification et comme notre nouvelle classe ne fait rien, rien n'a changé.
	+
	+	<note important>La classe d'authentification doit impérativement hériter de dcAuth pour être utilisée.</note>
	+
	+	===== Scénario =====
	+
	+	Dans le cadre de ces explications, nous allons partir du principe que nous disposons d'un service web XML-RPC qui permet de vérifier la validité d'un identifiant et de son mot de passe et d'obtenir des informations sur l'utilisateur.
	+
	+	Voici les spécifications de notre service Web d'authentification fictif.
	+
	+	L'URL du service est %%http://example.com/auth%% et il possède une seule méthode auth.login.
	+
	+	Cette méthode prend deux paramètres : une chaîne login pour l'identifiant de l'utilisateur et une chaîne password pour le mot de passe.
	+	Elle renvoie un tableau contenant les informations sur l'utilisateur ou provoque une erreur XML-RPC en cas d'erreur d'identifiant et/ou de mot de passe.
	+
	+	Enfin, nous allons partir du principe que notre installation ne contient qu'un seul blog dont l'identifiant est default.
	+
	+	===== Application =====
	+
	+	Dans le cadre de notre service d'authentification, nous devons nous intéresser à la méthode checkUser de dcAuth puisque c'est là que tout se passe. Cette méthode est appelée de différente manière par Dotclear.
	+
	+	Elle peut être appelée avec uniquement l'identifiant de l'utilisateur. Ceci permet d'initialiser les informations dans la classe.
	+
	+	Elle peut être appelée avec l'identifiant et un mot de passe. Ceci permet de vérifier le mot de passe en plus d'initialiser l'utilisateur.
	+
	+	Enfin, elle peut être appelée avec un identifiant, un mot de passe de valeur null et une clé de vérification. Ceci permet de valider la session de l'utilisateur et de l'initialiser à l'aide d'une clé.
	+
	+	Voici comment nous allons procéder :
	+
	+	* Si la méthode checkUser est appelée sans mot de passe, nous passons la main à la méthode parente.
	+	* Si la méthode checkUser est appelée avec un mot de passe, nous vérifions la validité de celui-ci puis créons ou mettons à jour l'utilisateur dans la base de données et enfin, passons la main à la méthode parent sans mot de passe.
	+
	+	On notera que l'utilisateur doit exister dans la base de données pour des raisons d'intégrité référentielle. En effet, il est nécessaire de pouvoir associer des billets (entre autre) à tel ou tel utilisateur.
	+
	+	Il est également nécessaire de stocker le mot de passe de l'utilisateur dans la base de données de Dotclear car certaines opérations en ont besoin. Ceci étant, il est possible d'interdire le changement de mot de passe par l'utilisateur.
	+
	+	Voici donc maintenant le code commenté de notre nouvelle classe d'authentification :
	+
	+	<code php>
	+	class myDcAuth extends dcAuth
	+	{
	+	# L'utilisateur n'a pas le droit de changer son mot de passe
	+	protected $allow_pass_change = false;
	+
	+	# La méthode de vérification du mot de passe
	+	public function checkUser($user_id, $pwd=null, $user_key=null)
	+	{
	+	# Pas de mot de passe, on appelle la méthode parente.
	+	if ($pwd == '') {
	+	return parent::checkUser($user_id,null,$user_key);
	+	}
	+
	+	# Si un mot de passe a été donné, nous allons le vérifier avec la
	+	# méthode auth.login XML-RPC.
	+	try
	+	{
	+	# On démarre une transaction et on ouvre un curseur sur la
	+	# table utilisateur de Dotclear pour créer ou modifier
	+	# l'utilisateur.
	+	$this->con->begin();
	+	$cur = $this->con->openCursor($this->user_table);
	+
	+	# On appelle la méthode de vérification du mot de passe.
	+	# En cas d'erreur le processus s'arrête là et provoque
	+	# une exception.
	+	$client = new xmlrpcClient('http://example.com/auth');
	+	$info = $client->query('auth.login',$user_id,$pwd);
	+
	+	# On définit le mot de passe, il est inséré dans tous les cas.
	+	$cur->user_pwd = $pwd;
	+
	+	# Si l'utilisateur existe, nous allons uniquement mettre à jour
	+	# son mot de passe dans la table utilisateur de Dotclear.
	+	if ($this->core->userExists($user_id))
	+	{
	+	$this->sudo(array($this->core,'updUser'),$user_id,$cur);
	+	$this->con->commit();
	+	}
	+
	+	# Si l'utilisateur n'existe pas, nous allons le créer.
	+	# Afin qu'il puisse se connecter, il est nécessaire de lui donner
	+	# au moins une permission "usage" sur le blog "default".
	+	else
	+	{
	+	$cur->user_id = $info['login'];
	+	$cur->user_email = $info['email'];
	+	$cur->user_name = $info['name'];
	+	$cur->user_firstname = $info['firstname'];
	+	$cur->user_lang = $info['lang'] ? $info['lang'] : 'en';
	+	$cur->user_tz = 'Europe/Paris';
	+	$cur->user_default_blog = 'default';
	+
	+	$this->sudo(array($this->core,'addUser'),$cur);
	+	$this->sudo(array($this->core,'setUserBlogPermissions'),
	+	$user_id,'default',array('usage'=>true));
	+	$this->con->commit();
	+	}
	+
	+	# Les opérations précédentes se sont déroulées sans erreur, nous
	+	# pouvons maintenant appeler la méthode parente afin d'initialiser
	+	# l'utilisateur dans l'object $core->auth
	+	return parent::checkUser($user_id,$pwd);
	+	}
	+	catch (Exception $e)
	+	{
	+	# En cas d'erreur on annule la transaction et on renvoie "false"
	+	$this->con->rollback();
	+	return false;
	+	}
	+	}
	+	}
	+	</code>
	+
	+	<note>On notera l'utilisation de la propriété allow_pass_change qui permet d'interdire le changement de mot de passe par l'utilisateur.</note>
	+
	+	Comme on peut le voir, le processus est assez simple à mettre en place. Quelques remarques maintenant.
	+
	+	* Il est indispensable de stocker le mot de passe de l'utilisateur dans la table utilisateur de Dotclear car celui-ci peut en avoir besoin pour certaines opérations
	+	* Il est bien sûr possible de donner des paramètres à ce code, comme par exemple, le blog et les permissions qui seront assignés à l'utilisateur s'il n'existe pas encore.
	+	* Vous pouvez créer des méthodes afterAddUser, afterUpdUser et afterDelUser dans votre classe d'authentification. Ces méthodes sont appelées respectivement après la création, la mise à jour ou la suppression d'un utilisateur.
	+
	+	Cet exemple simple d'authentification montre ce qu'il est possible de faire. Vous pouvez ainsi authentifier un utilisateur depuis n'importe quelle source telle qu'un serveur LDAP, la table utilisateur d'un forum, ou n'importe quoi acceptant un identifiant et un mot de passe.
	+
	+	Enfin, la class dcAuth permet de réaliser une véritable authentification unique de type SSO par ces fonctions de vérification de session et de changement du formulaire d'authentification.

2.6:resources:code-documentation

Wed, 16 Oct 2013 09:56:41 +0200

		Version actuelle
Ligne 1:		Ligne 1:
		+	FIXME reprendre ces éléments : [[http://www.dotclear.net/trac/wiki/DotClear/fr/Dev/CodeDocumentation]]

2.6:resources:coding-standards

Wed, 16 Oct 2013 09:56:41 +0200

	Version actuelle
Ligne 1:	Ligne 1:
	+	====== Convention de codage de Dotclear =======

	+	Que vous développiez un plugin, vouliez corriger un bug ou simplement ajouter une fonctionnalité, le suivi de ces quelques règles est nécessaire.
	+
	+	===== Code PHP =====
	+
	+	==== Configuration de PHP =====
	+
	+	Tout le code de Dotclear doit fonctionner avec cette configuration de PHP :
	+
	+	* short_open_tag = Off
	+	* allow_call_time_pass_reference = Off
	+	* error_reporting = E_ALL \| E_STRICT
	+	* display_error = On
	+	* register_globals = Off
	+	* magic_quotes_gpc = Off
	+	* allow_url_fopen = Off
	+
	+	Le code doit fonctionner avec PHP 5.2 minimum.
	+
	+	<note tip>
	+	Pour passer la valeur de error_reporting à ''E_ALL \| E_STRICT'', il faut décommenter le début du fichier ''/dotclear/inc/prepend.php'' en ajoutant un slash (''/'') avant ''/*== DC_DEBUG =='' ou ajouter ce code à la fin du fichier ''/dotclear/inc/config.php'' pour ne pas gêner la mise à jour automatique :
	+
	+	<code php>
	+	ini_set('display_errors',true);
	+	error_reporting(E_ALL \| E_STRICT);
	+	</code>
	+
	+	</note>
	+
	+	==== Indentation, longueur des lignes ====
	+
	+	Utilisez une indentation en tabulations vraies (pas en espaces). La largeur courante (et pratique) d'une tabulation est de 5 espaces dans le code de Dotclear.
	+
	+	Il est par ailleurs conseillé de ne pas dépasser 70 caractères dans les lignes.
	+
	+	==== Structures de contrôle ====
	+
	+	Les structures de contrôle sont les instructions if, switch, for, while, foreach, etc. Vous devez laisser un espace entre le mot clé de l'instruction et la condition. La position des accolades est à votre discrétion.
	+
	+	=== Exemple de structures de contrôles : ===
	+
	+	<code php><?php
	+	if (condition1 && condition1) {
	+	action;
	+	}
	+
	+	foreach ($tableau as $k => $v)
	+	{
	+	action;
	+	action;
	+	}
	+	?></code>
	+
	+	==== Appels de fonctions ====
	+
	+	Les fonctions sont appelées sans aucun espace entre le nom de la fonction, les parenthèses et les paramètres. Par exemple :
	+
	+	<code php><?php
	+	maFonction($var1,$var2);
	+	?></code>
	+
	+	Si la fonction est retournée dans une variable, on mettra au moins un espace de part et d'autre du signe égal. Par exemple :
	+
	+	<code php><?php
	+	$var = maFonction($var1);
	+	?></code>
	+
	+	==== Définitions des fonctions ====
	+
	+	Les accolades de la fonction sont placées sous le nom de celle-ci et le code est indenté d'un niveau. Par exemple :
	+
	+	<code php><?php
	+	maFonction($var1,$var2=0)
	+	{
	+	return $var1+$var2;
	+	}
	+	?></code>
	+
	+
	+	==== Commentaires ====
	+
	+	Les commentaires d'une ligne sont fréquemment faits avec le signe #, moins avec les %%//%%. Les commentaires de plusieurs lignes seront faits avec le style /* commentaire */
	+
	+	La désactivation d'une portion de code par un commentaire sera faite avec le code /* %%//%%*/, de cette manière, il suffit d'ajouter un / pour désactiver le commentaire. Par exemple :
	+
	+	<code php><?php
	+	/*
	+	code();
	+	//*/
	+	?></code>
	+
	+	<note tip>
	+	Vous pouvez utiliser les conventions de Doxygen pour commenter votre code à la manière de Dotclear :
	+	* [[http://www.stack.nl/~dimitri/doxygen/docblocks.html\|documentation générale de Doxygen]]
	+	* [[http://www.stack.nl/~dimitri/doxygen/commands.html\|commandes spéciales de Doxygen]]
	+	</note>
	+
	+	==== Inclusions de fichiers ====
	+
	+	Un fichier est inclus dans un autre relativement au premier. Cela est obligatoire. Par exemple :
	+
	+	<code php><?php
	+	require dirname(__FILE__).'/../../fichier.php';
	+	?></code>
	+
	+	==== Tags dans le code HTML ====
	+
	+	Le code PHP est toujours délimité par <?php ?> et non la version abrégée <? ?>. Ceci est obligatoire. La forme <?= ?> est bien entendu proscrite.
	+
	+	==== Conventions de nommage ====
	+
	+	=== Classes ===
	+
	+	Les classes sont toujours nommées avec des lettres non accentuées. Les mots sont séparés par des majuscules et le nom de la classe commence par une minuscule. Par exemple :
	+
	+	<code php><?php
	+	class maClasse
	+	{
	+	//...
	+	}
	+	?></code>
	+
	+	=== Fonctions ===
	+
	+	Les noms de fonctions suivent les même règles que les classes.
	+
	+	=== Variables ===
	+
	+	Les noms des variables doivent avoir un sens. Les mots sont séparés par des _. Par exemple :
	+
	+	<code php><?php
	+	$ma_variable = 'texte';
	+	$var = 'texte...';
	+	?></code>
	+
	+	===== Conventions HTTP =====
	+
	+	Dotclear se conforme au maximum à HTTP ce qui implique de suivre un certain nombre de règles.
	+
	+	==== Modification de données ====
	+
	+	Tout changement d'état (dans la base de données ou ailleurs) doit obligatoirement passer par une requête HTTP de type POST.
	+
	+	Par ailleurs, toute requête de ce type doit envoyer un champ nommé "xd_nonce" contenant un identifiant permettant d'assurer la légitimité de celle-ci.
	+
	+	Il est donc nécessaire de passer ce champ à tout formulaire de type POST. Par exemple :
	+
	+	<code php>
	+	<form action="foo.php" method="post">
	+	<p>....</p>
	+	<p><?php echo $core->formNonce(); ?></p>
	+	</form>
	+	</code>
	+
	+	L'appel à la méthode $core->formNonce() insère automatique un champ caché contenant la valeur du //nonce// dans le formulaire.
	+
	+	Enfin, ce qui est valable pour les soumissions de formulaire l'est également pour les requêtes faites via //XML HTTP Request// (Ajax) de type POST. Dotclear fournit une variable javascript contenant le //nonce// : dotclear.nonce.
	+
	+	Exemple de requête ajax avec le nonce :
	+
	+	<code javascript>
	+	params = {
	+	xd_check: dotclear.nonce,
	+	p: "param"
	+	};
	+
	+	$.post(url,params,function() {
	+	...
	+	});
	+	</code>
	+
	+	<note>
	+	La vérification du //nonce// est automatique et son usage n'est requis que pour la partie d'administration de Dotclear, pas pour la partie publique.
	+	</note>
	+
	+	===== Code XHTML =====
	+
	+	Veillez à valider le code XHTML de votre thème ou plugin. Il est possible de valider du XHTML même s'il n'est pas accessible (par exemple dans l'administration) grâce à l'extension [[https://addons.mozilla.org/fr/firefox/addon/60\|Web Developer]] pour Mozilla Firefox.
	+
	+	===== Base de données =====
	+
	+	Pour qu'un plugin ou un thème qui accède à la base de données puisse fonctionner sur tous les blogs, il faut qu'il soit testé avec les bases de données MySQL et PostgreSQL (PGSQL). Si vous ne pouvez effectuer de tests avec un de ces types de base de données, demandez de l'aide sur le [[http://forum.dotclear.net/\|forum]].

2.6:resources:contribute

Wed, 16 Oct 2013 09:56:41 +0200

	Version actuelle
Ligne 1:	Ligne 1:
	+	====== Contribuer ======

	+	===== Améliorer cette documentation =====
	+	Suivre [[:start#contribuer\|ce guide]].
	+
	+	===== Où envoyer vos œuvres? =====
	+
	+	Pour nous soumettre vos plugins, il suffit de se rendre sur [[http://plugins.dotaddict.org/infos/Deposer-un-plugin\|DotAddict]] et de remplir le formulaire adéquat. (formulaire hors ligne actuellement, pour cause de maintenance de DotAddict).
	+
	+	Pour nous soumettre vos thèmes, il suffit de se rendre sur [[http://themes.dotaddict.org/infos/Deposer-un-theme\|DotAddict]] (encore une fois ^^) et de remplir le formulaire adéquat.
	+
	+	Le [[http://lab.dotclear.org/wiki/WikiStart/fr\|Lab de Dotclear]] permet aux contributeurs d'héberger leurs créations en disposant d'un SVN, d'un wiki, d'un système de tickets accessible à tous les utilisateurs de Dotclear et d'une liste de diffusion dédiée aux contributeurs de plugins et de thèmes.
	+
	+	===== Rapporter les bugs ou proposer une amélioration =====
	+
	+	Vous pouvez chercher de l'aide sur le [[http://forum.dotclear.net/\|forum]], ou encore ouvrir un ticket sur l'interface de suivi de développement de Dotclear (Trac) :
	+	- il faut d'abord [[http://fr.dotclear.org/my/\|ouvrir un compte Dotclear]] si vous n'en avez pas déjà un (ce compte est indépendant du compte sur le forum)
	+	- utiliser ce nom d'utilisateur et ce mot de passe pour [[http://dev.dotclear.org/2.0/login\|se connecter à Trac]]
	+	- [[http://dev.dotclear.org/2.0/newticket\|ouvrir un ticket]] en indiquant le maximum d'informations
	+	- votre ticket sera examiné par les développeurs de Dotclear
	+
	+	<note tip>
	+	Un ticket donnera plus de visibilité à votre idée.
	+	</note>
	+
	+	===== Suggestions =====
	+
	+	Vous avez des idées, des remarques, des suggestions vous pouvez venir en discuter sur le [[http://forum.dotclear.net\|forum de Dotclear.net]]
	+
	+	===== Traduction =====
	+
	+	Si vous souhaitez traduire Dotclear et/ou son site web, rendez vous sur http://dotclear.org/translate.

2.6:resources:date-format

Wed, 16 Oct 2013 09:56:41 +0200

	Version actuelle
Ligne 1:	Ligne 1:
	+	====== Masques date et heure ======

	+	Dans la configuration de Dotclear ou dans certains marqueurs de template, vous pouvez indiquer un format particulier pour les dates et heures. Ce format suit les règles de la fonction [[http://fr.php.net/manual/fr/function.strftime.php\|strftime]].
	+
	+	Par exemple, pour afficher "jeudi 9 novembre 1989" on utilisera le masque %A %e %B %Y.
	+
	+	Voici la liste des masques possibles :
	+
	+
	+	* %a - nom abrégé du jour de la semaine (local).
	+	* %A - nom complet du jour de la semaine (local).
	+	* %b - nom abrégé du mois (local).
	+	* %B - nom complet du mois (local).
	+	* %c - représentation préférée pour les dates et heures, en local.
	+	* %C - numéro de siècle (l'année, divisée par 100 et arrondie entre 00 et 99)
	+	* %d - jour du mois en numérique (intervalle 01 à 31)
	+	* %D - identique à %m/%d/%y
	+	* %e - numéro du jour du mois. Les chiffres sont précédés d'un espace (de ' 1' à '31')
	+	* %h - identique à %b
	+	* %H - heure de la journée en numérique, et sur 24-heures (intervalle de 00 à 23)
	+	* %I - heure de la journée en numérique, et sur 12- heures (intervalle 01 à 12)
	+	* %j - jour de l'année, en numérique (intervalle 001 à 366)
	+	* %m - mois en numérique (intervalle 1 à 12)
	+	* %M - minute en numérique
	+	* %n - retour à la ligne
	+	* %p - soit `am' ou `pm' en fonction de l'heure absolue, ou en fonction des valeurs enregistrées en local.
	+	* %r - l'heure au format a.m. et p.m.
	+	* %R - l'heure au format 24h
	+	* %S - secondes en numérique
	+	* %t - tabulation
	+	* %T - l'heure actuelle (égal à %H:%M:%S)
	+	* %u - le numéro de jour dans la semaine, de 1 à 7. (1 représente lundi)
	+	* %U - numéro de semaine dans l'année, en considérant le premier dimanche de l'année comme le premier jour de la première semaine.
	+	* %V - le numéro de semaine comme défini dans l'ISO 8601:1988, sous forme décimale, de 01 à 53. La semaine 1 est la première semaine qui a plus de 4 jours dans l'année courante, et dont lundi est le premier jour.
	+	* %W - numéro de semaine dans l'année, en considérant le premier lundi de l'année comme le premier jour de la première semaine
	+	* %w - jour de la semaine, numérique, avec dimanche = 0
	+	* %x - format préféré de représentation de la date sans l'heure
	+	* %X - format préféré de représentation de l'heure sans la date
	+	* %y - l'année, numérique, sur deux chiffres (de 00 à 99)
	+	* %Y - l'année, numérique, sur quatre chiffres
	+	* %Z - fuseau horaire, ou nom ou abréviation
	+	* %% - un caractère `%' littéral

2.6:resources:good-practices

Wed, 16 Oct 2013 09:56:41 +0200

	Version actuelle
Ligne 1:	Ligne 1:
	+	====== Bonnes pratiques pour les créateurs et développeurs de thèmes et de plugins ======

	+	===== Thèmes =====
	+
	+	FIXME
	+
	+	===== Plugins =====
	+
	+	==== Côté admin ====
	+
	+	* Un flag d'activation pour la gestion multi-blogs : il peut être utile pour ne plus afficher un widget, définir un nouvel urlHandler, créer un nouveau menu dans le tableau de bord, appeler des behaviours... FIXME exemple de code
	+	* A quel endroit ajoutez-vous le namespace ? Le fichier _prepend.php est un bon candidat.
	+	* Toujours déclarer les settings en global lors de l'installation puis les enregistrer en local dans la configuration du plugin
	+	* Usez de l'autoload pour vos classes. Le fichier ne sera ainsi pas inclus systématiquement si la classe n'est pas instanciée, moins de risque d'inclusion récursive, d'oubli d'inclusion ou de redéclarations.
	+	* Si le plugin a une table, penser également à implémenter les behaviors pour l'import et l'export.
	+	* tester avec le niveau maximal d'erreur de PHP
	+	* tester avec MySQL et PostgreSQL
	+
	+
	+	==== Côté public ====
	+
	+	* appeler les différents fichiers JavaScripts avec le behaviour publicFooterContent FIXME justifier
	+	* si vous ajoutez du contenu, existe-t-il un mode non automatique ou peut-on positionner soi-même le nouveau contenu avec un ou plusieurs tpl ?
	+	* peut-on ne pas ajouter la feuille de style du plugin pour éviter une harmonie farfelue entre les couleurs du blog et les règles du plugin ? FIXME ou l'ajouter avant ...
	+
	+
	+	==== Côté readme, changeset & co ====
	+
	+	* la liste exhaustive des nouveaux settings avec le namespace
	+	* le ou les fichiers template inclus
	+	* les variables et les blocks tpl inclus dans votre plugin et leurs attributs.
	+	* Dans les infos à communiquer, il me parait aussi indispensable de donner les nouveaux types d'UrlHandlers. FIXME pas compris
	+
	+
	+	===== Juste avant de faire le zip =====
	+
	+	* valider le XHTML (côté admin et public, avec le plugin Web Developer par exemple)
	+	* vérifier les traductions (les chaînes sont-elles toutes bien traduites ?)
	+	* Minifier la ou les feuilles CSS incluses : pas de petit profit.
	+	* Minifier les fichiers javascript inclus dans le plugin (un fork du plugin packager est disponible ici pour automatiser cette opération ainsi que pour les feuilles de style)
	+
	+	//(merci à lipki pour la première version de cette page)//

2.6:resources:plugins

Wed, 16 Oct 2013 09:56:41 +0200

	Version actuelle
Ligne 1:	Ligne 1:
	+	====== Plugins ======
	+	===== Réalisation de plugin =====

	+	{{{pagetoc
	+	.:plugins:files
	+	.:plugins:tutorial
	+	.:plugins:admin
	+	.:plugins:public-page
	+	.:plugins:settings
	+	.:plugins:prefs
	+	.:plugins:widgets
	+	.:plugins:antispam
	+	.:plugins:behaviors
	+	.:plugins:jstoolbar
	+	.:plugins:auto-install
	+	.:plugins:services
	+	.:plugins:dashboard
	+	.:plugins:help
	+	.:plugins:changelogs
	+	}}}
	+
	+	<note related>
	+	* [[http://tips.dotaddict.org/tag/clearbricks\|Accéder à la base de données grâce à Clearbricks (Tips DotAddict)]]
	+	</note>
	+
	+	===== Documents annexes =====
	+	{{{pagetoc
	+	.:coding-standards
	+	.:code-documentation
	+	}}}

2.6:resources:templates

Wed, 16 Oct 2013 09:56:41 +0200

	Version actuelle
Ligne 1:	Ligne 1:
	+	====== Référentiel templates ======
	+	{{{pagetoc
	+	.:templates:blog
	+	.:templates:entries
	+	.:templates:comments
	+	.:templates:attachments
	+	.:templates:categories
	+	.:templates:archives
	+	.:templates:languages
	+	.:templates:system
	+	}}}

2.6:resources:themes

Wed, 16 Oct 2013 09:56:41 +0200

	Version actuelle
Ligne 1:	Ligne 1:
	+	====== Thèmes ======

	+	Cette page est destinée à la personnalisation ou la création de thèmes. Si vous cherchez des thèmes déjà réalisés, référez-vous à la documentation [[..:admin:themes\|Habillage du blog]].
	+
	+	===== Guide d'utilisation des thèmes =====
	+
	+	==== Mécanique générale ====
	+
	+	Chaque thème est un ensemble de fichiers rangés dans un sous répertoire de /themes sur votre installation Dotclear. Ce sont ces fichiers qui, une fois interprétés par le moteur de template, vont produire les pages HTML en façade de votre blog. Vous trouverez ci-dessous le détail des différents fichiers
	+
	+	==== Organisation des fichiers ====
	+
	+	=== La fiche d'identité du thème ===
	+
	+	Nommé _define.php ce fichier accueille le nom du thème, sa description, son auteur et son numéro de version. Rédigez-le de préférence en anglais en suivant le même schéma que pour [[.:plugins:tutorial#definition-d-un-plugin\|un plugin]].
	+
	+	=== Capture d'écran du thème ===
	+
	+	Si le répertoire du thème contient un fichier appelé screenshot.jpg, cette image sera affichée sur la page de sélection du thème. Elle permet d'avoir un aperçu du thème. L'image doit mesurer 280 pixels en largeur et 245 pixels en hauteur.
	+
	+	==== Les fichiers templates ou de « contexte » ====
	+
	+	Ces fichiers sont rangés dans un sous-répertoire //tpl//, dans le répertoire du thème.
	+
	+	<note>Il est possible que certains thèmes ayant été conçus avant la version RC1 ne suivent pas cette organisation. Il suffit alors de créer le répertoire //tpl// et d'y mettre les fichiers .html pour que le thème fonctionne correctement.</note>
	+
	+	Ils seront appelés en fonction du contexte de la page dont on demande l'affichage
	+
	+	* home.html : liste tous les billets publiés (par défaut, du plus récent au plus ancien)
	+	* post.html : affiche le contenu d'un billet (avec ses commentaires, notes, pièces jointes, rétroliens)
	+	* category.html : liste tous les billets d'une catégorie ou d'une sous-catégorie
	+	* archive.html : liste les mois comportant des billets
	+	* archive_month.html : liste tous les billets d'un mois
	+	* tags.html : liste de tous les tags saisis
	+	* tag.html : liste tous les billets d'un tag
	+	* search.html : liste tous les billets après une requête de recherche
	+	* 404.html : la page appelée en cas d'erreur
	+
	+	Chaque plugin créant un autre contexte doit prévoir son propre fichier .html. C'est le cas pour ceux par exemple des plugins dayMode et contactMe.
	+
	+	=== Les fichiers inclus dans les « fichiers de contexte » ===
	+
	+	Certains éléments sont récurrents, autant les faire une bonne fois pour toutes et les inclure dans la page de contexte qui nous intéresse. Ce sont les fichiers dont le nom est précédé d'un underscore. Exemple _footer.html.
	+	* _head.html : l'appel des feuilles de style et des scripts jQuery
	+	* _top.html : l'entête du blog
	+	* _footer.html : le pied de page
	+	* _flv_player.html : le lecteur de vidéo
	+	* _mp3_player.html : le lecteur mp3
	+
	+
	+	<note tip>Une class spécifique est attribuée à la balise <body> pour chaque fichier contexte ; on peut donc très facilement modifier la présentation d'un contexte spécifique à l'aide de cette class.</note>
	+
	+	<note tip>Rien n'empêche de retirer l'appel à un fichier inclus pour placer directement dans tel ou tel contexte un contenu qu'on voudrait différent uniquement pour ce contexte.
	+	- rien n'empêche non plus de créer un fichier _pouetpouet.html à inclure dans les fichiers contexte pour un élément que vous voudriez récurrent.</note>
	+
	+
	+	=== Ordre de lecture des fichiers ===
	+
	+	Le moteur va chercher le fichier dont il a besoin d'abord dans le répertoire du thème désigné par l'utilisateur. S'il ne s'y trouve pas, il ira piocher dans le répertoire du thème par défaut.
	+
	+	<note>Le cas des templates des flux Atom et RSS est un peu plus particulier. Ceux-ci sont situés dans le repertoire ''/dotclear/inc/public/default-templates/''. Rien n'empêche bien sûr de les ajouter à son propre thème pour les remplacer.</note>
	+
	+	Deux choses en découlent :
	+
	+	* si l'on ne veut modifier la structure que d'un contexte il suffit d'ajouter son fichier personnalisé dans le sous-répertoire //tpl// de son thème
	+	* il est inutile, voire contre-productif de créer un thème depuis la copie complète de tous les fichiers du thème par défaut.
	+
	+	===== Les balises template =====
	+
	+	Outre le code xhtml, les fichiers template de Dotclear utilisent une syntaxe spécifique pour appeler des fonctions de traitement et/ou d'affichage. Ces « tags » ainsi que leurs attributs sont listés et décrits [[.themes:tags\|dans cette section]]. La création d'une balise template est expliquée [[.:tpl\|dans cette autre section]].
	+
	+	===== Annexes =====
	+	{{{pagetoc
	+	.:themes:appendices
	+	}}}

2.6:resources:tpl

Sun, 24 Nov 2013 23:07:02 +0200

1381910201		Version actuelle
Ligne 79:		Ligne 79:

	<note warning>		<note warning>
-	La déclaration de la fonction se fait en dehors de la classe.	+	Notez bien que si la définition de la fonction se fait dans la classe, sa déclaration au moteur dotclear se fait en dehors de la classe.
	</note>		</note>
-
	===== Les blocs d’instruction =====		===== Les blocs d’instruction =====

2.6:resources:xml-rpc

Wed, 16 Oct 2013 09:56:41 +0200

	Version actuelle
Ligne 1:	Ligne 1:
	+	====== Interface XML-RPC de Dotclear 2.0 =======
	+	<note>Cette page est en construction, et à l'inverse de la page de l'API 1.2 est documenté en reverse engineering.</note>
	+
	+	===== Introduction =====
	+	Dotclear à l'instar de ses concurrents introduit une API permettant de gérer son blog à partir de clients différents de l'interface d'administration.
	+
	+	XML-RPC est un protocole de Web-Services orienté méthodes (par opposition à REST qui est orienté contenu) de nature plus simple que SOAP. Il se pose en surcouche du protocole HTTP.
	+
	+	Doctlear 1.2 couvrait la spécification MovableType, permettant ainsi d'utiliser des clients pour cette plateforme.
	+
	+	Dotclear 2.0 ajoute en supplément certaines méthodes issues de Wordpress 2.X , permettant a priori (non testé) d'utiliser les clients correspondants.