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 :
- ''adminBeforeDashboardOptionsUpdate'' : traitement avant enregistrement des options
- ''adminAfterDashboardOptionsUpdate'' : traitement après enregistrement des options
- ''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'] =
''.
''.
form::field('bottom_field',20,255,__("Bottom field"),'maximal').
'
';
// Ajout d'un champ "side field" dans la section metas-box
$sidebar_items['metas-box']['items']["side_field"] =
''.
form::field('side_field',20,255,__("Side Field")).
'
';
// Ajout d'une nouvelle section 'side section'
$sidebar_items["side_section"] = array(
'title' => __('Side section'),
'items' => array(
'side_section_field' =>
''.
form::field('side_section_field',20,255,__("Side Section Field")).
'
'
));
}
}
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 à [[[[actions|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 : [[http://fr.dotclear.org/blog/post/2011/11/13/Dotclear-2.4|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 ''.__('List of blogs').'
';
Les titres des pages peuvent maintenant utiliser la classe ''page-title'' :
echo ''.__('List of blogs').'
';
[[http://dev.dotclear.org/2.0/changeset/500%3Af88db2e809f4/admin/blogs.php|Exemple]] - [[http://dev.dotclear.org/2.0/ticket/1247|Ticket]].
==== Utilisation modérée des fieldsets ====
Les développeurs de Dotclear ont remarqué que la balise '''' était parfois utilisé à tort pour regrouper des champs de formulaire. Cela posait des problèmes avec les logiciels de lecture vocale lisant la balise '''' 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 ''''.
[[http://dev.dotclear.org/2.0/changeset/536%3A535dd04130aa/plugins/antispam/index.php#file0|Exemple]].
[[http://dev.dotclear.org/2.0/changeset/536|Source]].
==== Renommage des boutons de l'administration ====
Certains intitulés de boutons de l'administration ont été renommés, les changement sont visibles [[http://dev.dotclear.org/2.0/ticket/1187#comment:4|ici]].
==== Les "Tags" sont maintenant appelés "Mots-clés" ====
[[http://dev.dotclear.org/2.0/changeset/709|Ticket]].
===== Dotclear 2.3 =====
Sortie : [[http://fr.dotclear.org/blog/post/2011/05/16/Dotclear-2.3|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.
echo
'';
À partir de Dotclear 2.3, les champs obligatoires sont écrits ainsi :
echo
' '.
form::field('blog_id',30,32,html::escapeHTML($blog_id)).'
';