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
(Modif ou ajouts de behaviors, changements de bonnes pratiques code "pur", nouveautés…)
Par défaut les items de menu des plugins se placent dans le bloc "Plugins" mais il faudrait se conformer aux règles suivantes :
A modifier dans le fichier _admin.php
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 :
adminBeforeDashboardOptionsUpdate
: traitement avant enregistrement des optionsadminAfterDashboardOptionsUpdate
: traitement après enregistrement des optionsadminDashboardOptionsForm
: affichage des options du pluginJusqu'à dotclear 2.5.3, lorsqu'un plugin souhaitait ajouter des champs dans l'édition des billets, il utilisait les behaviors :
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 :
Le plugin a alors libre choix de compléter les 2 tableaux en entrée, en ajoutant/supprimant/réordonnant des champs. A noter :
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
Les behaviors suivant sont toujours fonctionnels, mais dépréciés en 2.6:
Il est désormais recommandé d'utiliser les behaviors suivants :
Pour plus d'informations sur les gestions des actions, se référer à cette page
(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) :
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.
(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
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é".
À COMPLÉTER
Sortie : 13 novembre 2011.
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>';
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>
.
Certains intitulés de boutons de l'administration ont été renommés, les changement sont visibles ici.
Sortie : 16 mai 2011.
Cette version introduit une nouvelle interface utilisateur qui laisse aux utilisateurs la possibilité de définir leurs propres icônes favorites.
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>';