Il ne fallait pas manquer l'occasion de sortir une version pour le 13e anniversaire de Dotclear et donc voilà, la 2.10 est disponible dès maintenant et très rapidement sur votre tableau de bord[1] !

Au menu (liste non exhaustive, voyez le CHANGELOG pour plus de détails) :

  • Quelques vulnérabilités corrigées
  • Pas mal de bugs éradiqués
  • Un nouveau jeu de template nommé dotty utilisant autant que faire se peut les nouvelles balises sémantiques HTML5
  • De nouvelles options pour personnaliser et utiliser un peu plus facilement votre administration (dossiers favoris pour la médiathèque, colonnes optionnelles pour les listes de pages et de billets, …)
  • La mise en place des Content-Security-Policies pour l'administration, prélude à une implémentation côté blogs pour la future version 2.11[2]
  • De nouvelles facilités et possibilités pour les développeurs de plugins (elles sont détaillées ci-dessous)
  • Des mises à jour des librairies Javascript utilisées (CKEditor, Codemirror, …)

Pas de révolution donc, mais des évolutions pour une application plus sécurisée et plus robuste ; pour finir, joyeux anniversaire Dotclear \o/

PS : Cette version nécessite PHP 5.3 a minima, mais je ne saurais trop vous conseiller de passer à PHP 5.6 voire PHP 7 sans attendre — cette dernière offre un gain de vitesse très appréciable. Il est très possible que la version suivante de Dotclear nécessite une version plus récente que la déjà obsolète 5.3.


Quelques détails techniques pour les développeurs de plugins (et de thèmes) et les administrateurs de blog :

CSP, aka Content-Security-Policies

Content Security Policy (abrégé CSP) est un mécanisme de sécurité permettant de restreindre l'origine du contenu (tel qu'un script Javascript, une feuille de style etc.) dans une page web à certains sites autorisés. Cela permet de mieux se prémunir d'une éventuelle faille XSS.

[ Wikipedia « Content Security Policy » ]

Les paramètres utilisés (activation et directives) sont accessibles via le module about:config du menu Réglages système. Voir la partie « system », les paramètres concernés étant les suivants :

  • csp_admin_on : activation/désactivation
  • csp_admin_default : directive CSP default-src
  • csp_admin_img : directive CSP img-src
  • csp_admin_script : directive CSP script-src
  • csp_admin_style : directive CSP style-src

Un plugin tiers devant utiliser les services d'un serveur externe peut compléter tout ou partie de ces directives à l'aide du behavior adminPageHTTPHeaderCSP qui fournit en argument un tableau à clé, Chacune des clés correspond à une des directives CSP, sa valeur fournissant la liste des éléments (séparés par des espaces) de la directive.

Exemple :

Si un plugin utilise côté administration l'API Google Maps (pour les scripts), il peut ajouter le serveur correspondant de cette façon :

$core->addBehavior('adminPageHTTPHeaderCSP',array('myAdminBehaviors','adminPageHTTPHeaderCSP'));

class myAdminBehaviors
{
	public static function adminPageHTMLHead($csp)
	{
		if (isset($csp['script-src'])) {
			$csp['script-src'] .= ' maps.googleapis.com';
		} else {
			$csp['script-src'] = 'maps.googleapis.com';
		}
	}
}

Répertoire privé /var

Un nouveau répertoire, nommé var fait son apparition avec la 2.10. Il est situé à la racine et devrait être utilisé pour le stockage d'éléments n'ayant rien à faire dans la médiathèque ou dans le répertoire de cache (qui peut être supprimé à n'importe quel moment sans remettre en question le fonctionnement de Dotclear).

Une constante, DC_VAR, est disponible automatiquement et peut être personnalisée dans le fichier config.php pour construire des chemins d'accès. Deux fonctions sont également disponibles pour récupérer des URLs :

  • dcPage::getVF() pour une URL basée sur l'URL d'administration du blog
  • dcBlog::getVF() pour une URL publique basée sur l'URL du blog

Les développeurs de plugin sont fortement encouragés à créer leur propre répertoire au sein de ce répertoire /var afin de conserver un semblant d'ordre.

Coloration syntaxique via Codemirror

La librairie Codemirror utilisée par l'éditeur de thème est désormais utilisable (côté administration) par n'importe quel plugin. Deux fonctions sont disponibles pour le chargement de la librairie et pour son exécution :

  • dcPage::jsLoadCodeMirror() pour le chargement
  • dcPage::jsRunCodeMirror() pour l'exécution

Exemple pour du code CSS :

# Get interface setting
$core->auth->user_prefs->addWorkspace('interface');
$user_ui_colorsyntax = $core->auth->user_prefs->interface->colorsyntax;
$user_ui_colorsyntax_theme = $core->auth->user_prefs->interface->colorsyntax_theme;

# in <head>
if ($user_ui_colorsyntax) {
	echo dcPage::jsLoadCodeMirror($user_ui_colorsyntax_theme,false,array('css'));
}

# in <body>
if ($user_ui_colorsyntax) {
	echo dcPage::jsRunCodeMirror('editor_css','css_content','css',$user_ui_colorsyntax_theme);
}

L'activation de la coloration syntaxique et le choix du thème à utiliser (parmi les quarante et plus proposés) se font dans « Mes préférences », onglet « Mes options ».


Si vous avez besoin de plus d'information sur ces développements techniques, utilisez le forum et/ou la mailing-list de développement, voire même le canal IRC #dotclear (irc.freenode.net) où certains d'entre nous traînent parfois…

Notes

[1] Un patch est également disponible pour ceux qui préfèrent cette méthode pour appliquer la mise à jour.

[2] La mise en place des CSP est consécutive à une conférence de Nicolas Hoffmann à ce sujet, à Paris-Web en 2015, à laquelle j'ai assisté.