Notes de changements de version pour les plugins

Rappel sécurité

La première instruction en début des fichiers _define.php, _public.php, _widgets.php et _prepend.php (s'ils existent) doit être (après le bloc licence) :

if (!defined('DC_RC_PATH')) { return; }

Pour les fichiers _admin.php, _install.php, _uninstall.php et index.php la première instruction doit être :

if (!defined('DC_CONTEXT_ADMIN')) { return; }

Le fichier _prepend.php étant appelé côté public et côté admin, vous pouvez faire ceci :

if (!defined('DC_RC_PATH')) { return; }
 
  // Traitement public et admin
 
if (!defined('DC_CONTEXT_ADMIN')) { return false; }
 
  // Traitement admin seulement

Dotclear 2.6

Avec impact fonctionnel

(Modif ou ajouts de behaviors, changements de bonnes pratiques code "pur", nouveautés…)

Emplacement des plugins dans le menu

Par défaut les items de menu des plugins se placent dans le bloc "Plugins" mais il faudrait se conformer aux règles suivantes :

  • les réglages de la page du plugin n'auront d'impact que sur le blog actif : dans "Blog"
  • les réglages concerneront toute l'install : dans "Plugins"

A modifier dans le fichier _admin.php

Emplacement des plugins dans les préférences utilisateur

Jusqu'à la 2.5.3, les plugins fournissant des options supplémentaires étaient affichés sur le 2e onglet (Mes options). Depuis la 2.6, ceux-ci peuvent également s'inviter sur le 3e onglet (Mon tableau de bord) en utilisant les behaviours suivants :

  1. adminBeforeDashboardOptionsUpdate : traitement avant enregistrement des options
  2. adminAfterDashboardOptionsUpdate : traitement après enregistrement des options
  3. adminDashboardOptionsForm : affichage des options du plugin

Emplacements des plugins dans les attributs des billets/pages (colonne de droite et bas de formulaire)

Jusqu'à dotclear 2.5.3, lorsqu'un plugin souhaitait ajouter des champs dans l'édition des billets, il utilisait les behaviors :

  • adminPostForm pour ajouter des champs en bas de formulaire
  • adminPostFormSidebar pour ajouter des champs dans la barre latérale

Ces 2 behaviors sont dépréciés en 2.6.

La version 2.6 introduit une classification des éléments de la barre latérale, les behaviors précédents étaient donc insuffisants. Un seul et unique behavior les remplace désormais :

$core->callBehavior('adminPostFormItems',$main_items,$sidebar_items, $post);

Chaque plugin voulant ajouter des champs devra donc désormais utiliser cet unique behavior :

  • $main_items est un tableau d'entrées listant les champs de la section principale
  • $sidebar_items est un tableau d'entrées listant les champs de la barre latérale
  • $post contient le record du billet courant (null s'il s'agit d'un nouveau billet)

Le plugin a alors libre choix de compléter les 2 tableaux en entrée, en ajoutant/supprimant/réordonnant des champs. A noter :

  • $main_items est un tableau à une seule dimension, les clefs sont les identifiants des champs, les valeurs le code html à ajouter
  • $sidebar_items est un tableau à 2 dimensions :
    • les clefs du tableau donnent l'identifiant de la "boîte" contenant les éléments
    • les valeurs sont des tableaux :
      • clef "title" : titre de la boîte (localisée)
      • clef "items" : liste des champs de la boîte (clef = id du champ, valeur = contenu du champ)

Les champs définis dans la page principale sont les suivants :

ID Description
post_title Titre du billet
post_excerpt Extrait du billet
post_content Contenu du billet
post_notes Notes du billet

Les sections de la barre latérale sont les suivantes :

ID Section
status-box Boîte "Etat"
metas-box Boîte "Métadonnées"
options-box Boîte "Options"

Champs de la boîte "Etat" :

ID Description
post_status Statut du billet
post_dt Date du billet
post_lang Langue du billet
post_format Format du billet

Champs de la boîte "Métadonnées" :

ID Description
post_selected Billet sélectionné ou non
cat_id Catégorie du billet
post_tags Mots-clés du billet

Champs de la boîte "Options" :

ID Description
post_open_comment_tb Commentaires/rétroliens activés
post_password Mot de passe du billet
post_url URL du billet

Exemple d'ajout de champs pour les billets :

$core->addBehavior("adminPostFormItems",array('AdminPostFormPlugin', 'adminPostFormItems'));
 
class AdminPostFormPlugin {
 
	public static function adminPostformItems($main_items,$sidebar_items, $post) {
		// Ajout d'un champ "bottom_field" en bas de formulaire
		$main_items['bottom_field'] =
			'<p class="col">'.
			'<label class="required no-margin bold"><abbr title="'.__('Bottom Field').'">*</abbr> '.__('Title:').'</label>'.
			form::field('bottom_field',20,255,__("Bottom field"),'maximal').
			'</p>';
 
		// Ajout d'un champ "side field" dans la section metas-box
		$sidebar_items['metas-box']['items']["side_field"] =
			'<p><label for="side_field">'.__('Side Field').'</label>'.
			form::field('side_field',20,255,__("Side Field")).
			'</p>';
 
		// Ajout d'une nouvelle section 'side section'
		$sidebar_items["side_section"] = array(
			'title' => __('Side section'),
			'items' => array(
				'side_section_field' =>
					'<p><label for="side_section_field">'.__('Side Section Field').'</label>'.
					form::field('side_section_field',20,255,__("Side Section Field")).
					'</p>'
		));
	}
 
}

De la même manière pour les pages : le behavior adminPageFormItems remplace les behaviors adminPageForm et adminPageFormSidebar

Gestion des actions / listes

Les behaviors suivant sont toujours fonctionnels, mais dépréciés en 2.6:

  • adminPostsActionsCombo
  • adminPostsActionsHeaders
  • adminPostsActionsContent
  • adminPagesActionsCombo
  • adminPagesActionsHeaders
  • adminPagesActionsContent

Il est désormais recommandé d'utiliser les behaviors suivants :

  • adminPostsActionsPage
  • adminPagesActionsPage

Pour plus d'informations sur les gestions des actions, se référer à cette page

Plugin Maintenance

  • Ajout d'un behavior dcMaintenanceInit pour "enregistrer" une nouvelle tâche de maintenance.

Avec impact esthétique/sémantique

(Changement de bonnes pratiques sémantiques/esthétiques. Ex. Ne plus utiliser les fieldsets pour la déco, remplacer par class="fieldset").

Utilisation de dcPage::breadcrumb() pour les pages d'administration indépendantes des plugins.

Messages (horodatés par défaut) :

  • dcPage::message()
  • dcPage::success() pour les message de succès
  • dcPage::warning() pour les messages d'avertissement

Emplacement des plugins sur le tableau de bord

Dans la 2.5.3 deux zones était disponibles pour l'affichage de plugins tiers, la colonne de droite et sous les favoris (et le formulaire de billet rapide). Dans la 2.6, ces deux zones deviennent polyvalentes et sont affichées sous les favoris : ce qui était dans la colonne de droite étant affiché en premier, puis ce qui était affiché en dessous du billet rapide en second.

Plugin maintenance et ImportExport

  • Le plugin maintenance accueil désormais des onglets
  • Les fonctions d'export de blog sont déplacées dans l'onglet sauvegarde du plugin maintenance avec un lien de importExport vers maintenance.

Bonnes pratiques sur les plugins

  • Il n'est plus nécessaire de passer par l'appel à global (et $GLOBALS) pour utiliser $core et $autoload dans les fichiers _prepend.php (comme tous les _xxx.php) car ces fichiers sont désormais appelés depuis dcModules::loadModuleFile() qui déclare les globals.

Sans impact autre que sur le core ou modifs strictement esthétiques

(Ex1. Les h3 et h4 sont en couleur - Ex2. Ajout d'une aide générale. Peut servir dans le billet d'annonce pour évoquer la nouvelle version.)

"Extension(s)" dans la 2.5.3 est devenu "Plugin(s)" dans la 2.6

Gestion des pluriels multiformes

Depuis la 2.6 nous sommes capables de fournir des pluriels suivant les règles de chacune des langues. Par exemple en anglais le 0 est pluriel alors qu'il ne l'est pas en français (certaines langues possèdent jusqu'à 5 formes différentes de pluriel en fonction de la quantité).

Donc là où avant on faisait :

echo sprintf(__('%d thing(s)'), $nb_things);

avec dans le .po (fr) :

msgid "%d thing(s)"
msgstr "%d bidule(s)"

On peut faire :

echo sprintf(__('%d thing','%d things',$nb_things),$nb_things);

avec dans le .po (fr) :

msgid "%d thing"
msgid_plural "%d things"
msgstr[0] "%d bidule"
msgstr[1] "%d bidules"

En n'oubliant pas de vérifier la présence de la ligne suivante dans le bloc d'en-tête de fichier .po :

"Plural-Forms: nplurals=2; plural=(n > 1);\n"

La fonction de traduction autorise l'utilisation deux paramètres supplémentaires, la forme plurielle et la "quantité" qui va lui permettre de définir s'il doit utiliser la forme plurielle et celle qui convient dans ce cas en fonction de la langue et de la "quantité".

Dotclear 2.5

À COMPLÉTER

Dotclear 2.4

Sortie : 13 novembre 2011.

Titres des pages dans l'administration

Les titres des pages étaient définis ainsi dans les versions précédentes de Dotclear :

echo '<h2>'.__('List of blogs').'</h2>';

Les titres des pages peuvent maintenant utiliser la classe page-title :

echo '<h2 class="page-title">'.__('List of blogs').'</h2>';

Exemple - Ticket.

Utilisation modérée des fieldsets

Les développeurs de Dotclear ont remarqué que la balise <fieldset></fieldset> était parfois utilisé à tort pour regrouper des champs de formulaire. Cela posait des problèmes avec les logiciels de lecture vocale lisant la balise <legend></legend> pour chaque label de champ. Il a été décidé de réduire l'utilisation de ces balises au strict nécessaire. Une nouvelle classe fieldset peut être utilisée pour imiter le style de la balise <fieldset></fieldset>.

Exemple.

Source.

Renommage des boutons de l'administration

Certains intitulés de boutons de l'administration ont été renommés, les changement sont visibles ici.

Les "Tags" sont maintenant appelés "Mots-clés"

Dotclear 2.3

Sortie : 16 mai 2011.

Ajout d'une icône de favori

Cette version introduit une nouvelle interface utilisateur qui laisse aux utilisateurs la possibilité de définir leurs propres icônes favorites.

Liens connexes :

Voir la documentation sur l'ajout d'une icône de favori pour une description détaillée.

Champs obligatoires

Dans les versions précédentes, les champs obligatoires étaient définis comme ceci :

echo
	'<p><label class="required" title="'.__('Required field').'">'.__('Blog ID:').
	form::field('blog_id',30,32,html::escapeHTML($blog_id)).'</label></p>';

À partir de Dotclear 2.3, les champs obligatoires sont écrits ainsi :

echo
	'<p><label class="required" for="blog_id"><abbr title="'.
	__('Required field').'">*</abbr> '.__('Blog ID:').'</label> '.
	form::field('blog_id',30,32,html::escapeHTML($blog_id)).'</p>';

Liens connexes :

Voir la documentation sur les champs textuels pour davantage d'informations.

Wiki powered by Dokuwiki.