Morefnu.org

Nouvelles du front

Dsls — Fri, 10 Dec 2010 09:39:00 +0100

Peu de nouvelles sur ce blog, cependant beaucoup de boulot en coulisses.

Sur dotclear : il y a actuellement plusieurs réflexions internes sur certains point du core :

La refonte de l'interface d'administration, qui donne lieu à pas mal de discussions passionnées en ce moment en interne
La refonte du gestionnaire de médias, encore à l'état de discussions, mais les grandes lignes se dégagent

J'ai pour ma part testé quelques pistes expérimentales concernant le moteur de templates du core de dotclear, avec pour objectif un remplacement pur et simple par un moteur qui a le vent en poupe en ce moment, à savoir Twig. L'idée est bien sûr d'assurer une rétro-compatibilité avec la syntaxe actuelle des thèmes, et de permettre de rendre les templates plus flexibles notamment grâce aux mécanismes d'héritages proposés en natif par Twig.

Ces travaux sur le core sont assez chronophages, mais je vois passer ça et là quelques questions sur Gallery et MyMeta.

Le plugin MyMeta va prochainement sortir dans une nouvelle version, corrigeant quelques bugs signalés.

Quant à Gallery, il est probable qu'il soit (encore) revu à bas niveau. Resituons le contexte :

Une galerie est un billet, dont les métadonnées pointent vers des billets-images (via la table dc_meta). Une miniature de présentation de la galerie est alors un média attaché à la galerie (via la table dc_post_media)
Un billet-image est un billet d'un type particulier, qui contient en pièce jointe le média concerné (via la table post_media).

Le problème de cette situation est qu'il est indispensable d'avoir des billets-images pour créer une galerie. Le choix avait été à l'époque de ne pas toucher aux tables natives de dotclear.

Je suis en train de songer à un changement de modèle :

Une galerie est un billet, dont les images sont directement des pièces jointes (table dc_post_media)
Si on souhaite activer les descriptions/commentaires sur une image, on crée alors un billet-image associé à cette image.

Cela rend alors le passage par les billets-images facultatif.

Pour cette évolution, la table "dc_post_media" sera probablement étendue : une nouvelle colonne qualifiant le lien billet-image sera définie (lien type pièce-jointe, lien type "embedded", miniature de présentation, image de galerie, ...), et peut-être même aussi une colonne de position de ce lien.

Autre point : on ne peut pas associer directement une image à une galerie actuellement : il faut que l'image corresponde au filtre défini par la galerie. Cela déroute un peu les utilisateurs. Je songe à définir 2 types de galerie : les galeries "dynamiques", auxquelles sont associées les images dynamiquement selon un certain nombre de filtres (en gros, les galeries telles qu'elles sont définies dans la version actuelle), et les galeries statiques, où il faudra faire le lien galerie-image à la main.

Coté dates, la seule réponse que j'aurais est "courant 2011", pour le moment le temps libre est rare, et les travaux niveau core vont monopoliser pas mal de ce temps ...

Ajouter des fonctions au plugin ExpAt

Dsls — Fri, 24 Sep 2010 09:26:00 +0200

ExpAt est extensible. La version actuelle possède un nombre minimal de fonctions/objets, mais elle s'enrichira au cours du temps.

Il reste toutefois possible dans la version actuelle du plugin, d'ajouter ses propres fonctions, via le _public.php de son thème ou d'un plugin donné.

L'approche générale est d'utiliser l'objet $core->expatDict, qui est le dictionnaire du plugin ExpAt

La déclaration d'une fonction est très simple, il suffit d'utiliser le behavior expatDictInit :

$core->addBehavior("expatDictInit",array("myExpat","expatDictInit"));
class myExpat {
  public static function expatDictInit($dict) {
    $dict->registerFunction(new expatBasicFunction("map_name","function"));
  }
}

map_name est le nom de la fonction tel qu'il devra être entré dans les expressions du template
function est le nom de la fonction généré dans le template compilé.

Exemple : en déclarant le code

$core->addBehavior("expatDictInit",array("myExpat","expatDictInit"));
function isSame($a,$b) {
 return $a==$b;
}

class myExpat {
  public static function expatDictInit($dict) {
    $dict->registerFunction(new expatBasicFunction("test","isSame"));
  }
}

Il devient alors possible de faire un test du type <tpl:If expr="test(entry.id,12)">...</tpl:if>. L'exemple choisi ici est idiot (on peut faire tout bêtement "entry.id==12"à, mais il montre les possibilité d'extension du plugin.

Il est également possible de définir de nouveaux objets, cela fera l'objet d'un nouveau billet...

Plugin ExpAt pour Dotclear 2.2

Dsls — Wed, 15 Sep 2010 08:17:00 +0200

Le constat

Dotclear propose, via son langage de templates, un certain nombre de balises permettant d'afficher conditionnellement un contenu donné.

Exemple dans le home.html :

<!-- # Entry with an excerpt -->
<tpl:EntryIf extended="1">
	<div class="post-content">{{tpl:EntryExcerpt}}</div>
	<p class="read-it"><a href="{{tpl:EntryURL}}"
	title="{{tpl:lang Continue reading}} {{tpl:EntryTitle encode_html="1"}}">{{tpl:lang Continue
	reading}}</a>...</p>
</tpl:EntryIf>
<!-- # Entry without excerpt -->
<tpl:EntryIf extended="0">
	<div class="post-content">{{tpl:EntryContent}}</div>
</tpl:EntryIf>

Ce bout de code teste si le billet a un extrait (via <tpl:EntryIf extended="1">...</tpl:EntryIf>).

Si c'est le cas, on n'affiche que l'extrait du billet
Sinon on affiche le contenu du billet.

Maintenant, une colle : je voudrais afficher le premier billet complètement si c'est le premier de la page, mais garder le comportement normal dans les autres billets. Je vous épargne le code complet à écrire, mais dans le dernier tpl:EntryIf, il faudrait pouvoir dire : "si le billet n'a pas d'extrait, ou s'il a un extrait mais qu'il est le premier de la liste"... difficile à exprimer simplement avec les balises existantes, à moins de faire quelques redites dans le code.

Une solution

Voici donc une nouvelle extension : ExpAt, c'est à dire "Expressions in Attributes". Il s'agit d'un nouveau moyen d'écrire les tests dans les balises dotclear.

Là où on écrivait avant :

<tpl:EntryIf selected="1" extended="1" operator="||">...</tpl:EntryIf>

On peut maintenant écrire :

<tpl:EntryIf expr="selected || extended">...</tpl:EntryIf>

Revenons au problème initial : afficher le premier billet complètement si c'est le premier de la page, mais garder le comportement normal dans les autres billets. Voilà le code template à effectuer :

<!-- # Entry with an excerpt -->
<tpl:EntryIf expr="extended">
	<div class="post-content">{{tpl:EntryExcerpt}}</div>
	<tpl:EntryIf expr="index!=0">
		<p class="read-it"><a href="{{tpl:EntryURL}}"
		title="{{tpl:lang Continue reading}} {{tpl:EntryTitle encode_html="1"}}">{{tpl:lang Continue
		reading}}</a>...</p>
	</tpl:EntryIf>
</tpl:EntryIf>
<!-- # Entry without excerpt -->
<tpl:EntryIf expr="!extended || (extended && index!=0)">
	<div class="post-content">{{tpl:EntryContent}}</div>
</tpl:EntryIf>

Le moteur d'expressions

Le moteur d'expressions permet les opérations suivantes :

Opérations arithmétiques : +, -, *, /, %
Opérations logiques : || (or), && (and), ^^ (xor)
Comparaisons : < ("<"), > (">"), ≤ ("<="), ≥ (">="), ==, !=
Gestion des parenthèses
négation logique : !expression
Variables : voir référence pour la liste des variables définies
Fonctions : voir référence pour la liste des fonctions définies

"One last thing..."

Au fait, pourquoi s'embêter avec <tpl:EntryIf>, <tpl:CategoryIf>, <tpl:SysIf>, ... ? ExpAt définit tout simplement <tpl:If>, il suffit alors de préfixer les attributs par l'objet souhaité : entry pour tpl:EntryIf, category pour tpl:CategoryIf. En clair, <EntryIf> permet d'omettre "entry", <categoryIf> permet d'omettre "category", ...

Ainsi :

<tpl:EntryIf expr="!extended || (extended && index!=0)">

équivaut à :

<tpl:If expr="!entry.extended || (entry.extended && entry.index!=0)">

Et on peut bien sûr combiner le tout, par exemple dans un category.html :

<tpl:If expr="entry.extended && category.nb_post==1">

"One very last thing..."

Sur le forum a été évoqué un souhait pertinent : je veux afficher le résumé d'un billet (ie. les 300 premiers caractères), et afficher "..." si le contenu du billet dépasse les 300 caractères. Comment faire ?

ExpAt introduit quelques petits concepts supplémentaires.

L'affichage

C'est bien beau de ne faire que des tests, l'idéal serait quand même de pouvoir afficher quelque chose. {{tpl:Echo expr="<expression>"}} est là pour ça :)

Les variables

ExpAt permet de stocker le résultat d'une expression dans une variable, via le template :

{{tpl:Set var="nomvariable" expr="expression"}}

La variable est ensuite déclarée comme attribut de l'objet "my", et donc accessible ensuite via my.variable.

Cas pratique

Bon, maintenant, un cas d'application: afficher l'extrait d'un billet, par exemple les 300 premiers caractères de ce billet, et afficher '...' ensuite si ce billet dépasse 300 caractères, en ajoutant un lien pour le lire en entier.

Voilà le code que ça peut donner :

{{tpl:Set var="content" expr="encode_html(remove_html(entry.content))"}}
{{tpl:Set var="content_length" expr="strlen(my.content)"}}
<div class="post-content">
       {{tpl:Echo expr="substr(my.content,0,300)"}}
       <tpl:If expr="my.content_length &gt; 300">&nbsp; [...]</tpl:If>
</div>
<tpl:If expr="my.content_length &gt; 300">
     <p class="read-it"><a href="{{tpl:EntryURL}}"
     title="{{tpl:lang Continue reading}} {{tpl:EntryTitle
encode_html="1"}}">{{tpl:lang Continue
     reading}}</a>...</p>
</tpl:If>

En clair :

On stocke le contenu billet dans my.content et sa taille dans my.content_length
On test la valeur de my.content_length, et on affiche les "..." seulement si on est supérieur à 300...

La suite

La version actuelle du plugin montre les choses qu'il est possible de faire, mais la liste des objets/fonctions est réduite. J'attends maintenant vos besoins pour les enrichir :)

Crédits

Le compilateur d'expression repose sur un analyseur syntaxique et sémantique généré avec LIME-php.

Téléchargement

Le plugin est pour l'instant disponible ici

Le support du plugin se fait sur le forum dotclear

Plugin "Grumph" pour dotclear

Dsls — Thu, 09 Sep 2010 19:38:00 +0200

Grumph est un plugin filtrant les resources d'un billet, et les gardant au chaud à coté de ce billet.

Grumph est l'acronyme de "Grab Resources and Urls to Manage Posts Handily"

Les resources récupérées sont :

Les images
Les vidéos (html5)
Les sons (html5)
Les objets
Les liens

Il est alors possible d'en faire des traitements spécifiques via les balises templates définies pour l'occasion :

Nouvelles balises de template

<tpl:EntryResources> ... </tpl:EntryResources>

liste les ressources du billet

Attributs possibles

internal = (0|1) : ne sélectionne que les ressources internes au blog
scope = (all|excerpt|content) : ne sélectionne que les ressources de l'entête, du contenu ou des deux
type=link,image,video,audio,object : ne sélectionne que les types de ressources spécifiés (plusieurs valeurs possibles séparées par une virgule)

Les autres balises sont utilisables uniquement dans une boucle tpl:EntryResources :

<tpl:ResHeader>...</tpl:ResHeader>

Affiche le contenu de la balise avant la première ressource trouvée (pas d'affichage si pas de ressources)

<tpl:ResFooter>...</tpl:ResFooter>

Affiche le contenu de la balise après la dernière ressource trouvée (pas d'affichage si pas de ressources)

Affiche l'URL de la ressource en cours

Affiche le titre de la ressource en cours

Affiche le type de la ressource en cours.

Administration

Le plugin nécessite de mettre à jour la table dc_post pour stocker en cache, la page d'administration du plugin permet de mettre à jour les billets.

Il est disponible ici, et prochainement sur dotaddict.

Le truc PHP du jour : hériter dynamiquement d'une classe

Dsls — Mon, 30 Aug 2010 13:43:00 +0200

Aussi moche soit-il, PHP s'est imposé chez bon nombre d'hébergeurs, et souvent, "il faut faire avec".

L'astuce du jour : comment définir une classe héritant dynamiquement d'une autre classe ?

Forcément, le code suivant ne fonctionne pas :

<?php
	$classToInherit = "parentClass";

	class parentClass {
		public function hello() {
			echo "Hello, world !";
		}
	}

	class childClass extends $classToInherit {
		public function hello() {
			parent::hello();
			echo "Hello, too!";
		}
	}

	$o = new childClass();
	$o->hello();
?>

Ce serait trop simple...

Qu'à cela ne tienne, il existe une fonction qui va nous permettre de ruser, la fonction class_alias. Et voilà le travail :

<?php
	$classToInherit = "parentClass";

	class parentClass {
		public function hello() {
			echo "Hello, world !";
		}
	}

	class_alias($classToInherit,"myCustomClass");
	
	class childClass extends myCustomClass {
		public function hello() {
			parent::hello();
			echo "Hello, too!";
		}
	}

	$o = new childClass();
	$o->hello();
?>

(J'entends déjà les "dans les vrais langages, on peut faire ça proprement", et je suis entièrement d'accord :)

Débugger de l'Ajax avec firebug

Dsls — Mon, 30 Aug 2010 08:44:00 +0200

Cet article est d'abord un article intéressé. En effet, dans le cadre du plugin gallery, une bonne partie de l'interface d'administration repose sur des requêtes asynchrones répétées, notamment pour gérer la création/mise à jour des miniatures des images, opérations coûteuses, et pas gérables en une seule page PHP dès lors qu'il commence à y avoir un nombre conséquent de miniatures à générer.

Le plugin Gallery pour dotclear2 repose sur une couche de traitement ajax qui va gérer une queue d'événements. Pour ce qui est des aspects techniques, il repose sur jquery.ajaxmanager.

Seulement voilà, qui dit Ajax dit moins de visibilité sur les erreurs potentielles. Ce petit article est là pour tracer les éventuelles erreurs invisibles.

Il faut d'abord 2 outils : firefox, et l'incontournable firebug (les versions utilisées ici sont firefox 3.6.6 et firebug 1.5.4). L'exemple d'application est ici la page de génération des nouvelles images du plugin gallery en action.

1. Commencez par activer firebug, via la touche F12, et activez la console si ce n'est pas déjà fait :

2. Allez ensuite sur la page générant des appels ajax, et déclenchez-les (pour le plugin gallery, un clic sur soumettre après avoir sélectionné le répertoire dans l'onglet "gestion des nouvelles images" en déclenche un certain nombre). L'onglet "Console" affiche alors les requêtes Ajax effectuées. Dans notre exemple, 5 requêtes "GET" sont faites :

3. En dépliant chaque requête il est possible de voir ce qui a été envoyé, et ce qui a été reçu :

L'onglet "Paramètres" résume les paramètres transmis à l'URL

L'onglet "En-têtes" indique les headers renvoyés en réponse à la requête

L'onglet "contenu" indique le contenu de la réponse

Plugin Gallery 0.4 pour dotclear 2.2

Dsls — Fri, 27 Aug 2010 16:11:00 +0200

Enfin ... après une longue période de gestation depuis la 0.3.8, la version 0.4 du plugin Gallery vient de voir le jour. Merci à tous les contributeurs du forum qui ont pu m'aider à chasser les quelques bugs trouvés.

Changements notables depuis la 0.3.8 :

Compatibilité avec dotclear 2.2 (et uniquement celle-là, comprenez par là qu'avec dotclear 2.1.X il faudra se contenter de gallery 0.3.8)
Onglet "gestion des nouvelles images" mis à jour, avec de nouveaux traitements asynchrones
Correction des url de flux
Ajout du nombre d'images sur l'accueil du tableau de bord
Quelques corrections au niveau des thèmes
Support de jquery 1.4.2
Quelques blindages coté code.
Passage à jquery.ajaxmanager v3 pour la gestion des nouvelles images

En gros, rien de bien visible (si ce n'est l'onglet "Gestion des nouvelles images"), mais une version consolidée et compatible dotclear 2.2

Le plugin est disponible sur dotaddict

Coté support, ça se passe ici

Version mobile, première

Dsls — Wed, 30 Jun 2010 10:41:00 +0000

Depuis ce matin, ~~les gens~~ ~~les quelques gens~~ ~~les rares gens qui viennent sur ce site~~ si vous vous connectez sur ce site depuis un smartphone, vous serez redirigés vers la version mobile du site, à savoir http://m.morefnu.org.

Cette redirection automatique est l'objet de quelques aménagements de ce blog :

J'ai repris l'astuce de tips.dotaddict.org, "Un blog 2 thèmes, 2 URLs", avec une légère modification. Contrairement au tip, ma seconde URL est dans un répertoire distinct (qui n'est pas un sous-répertoire du répertoire du blog). Pour que les thèmes et le répertoire public soient toujours visibles, j'ai effectué un lien symbolique dans ce nouveau répertoire vers les répertoires originaux du blog principal
Pour la redirection automatique, rien de plus simple, quelques petites lignes dans le .htaccess à la racine du site principal:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_COOKIE} !(no_mobile)
RewriteCond %{HTTP_USER_AGENT} ^.*(iPhone|BlackBerry|Palm|Android).*$
RewriteRule ^(.*)$ http://m.morefnu.org/$1 [R=301,L]

Et voilà ... enfin pour le moment : les plus perspicaces auront noté la ligne

RewriteCond %{HTTP_COOKIE} !(no_mobile)

Qui permet de refuser le mode mobile si le cookie "no_mobile" est positionné sur le site. Ce qu'il reste encore à faire :

Ajouter un lien sur le site mobile pour repasser en mode normal, et positionner le cookie
Ajouter un lien sur le site normal quand le cookie est positionné, pour passer sur la partie mobile.

Au passage, un grand merci à Guillaume pour son thème dc2iphone.

Dernier point : le tip mentionné, pour être compatible avec dotclear 2.2, nécessite de modifier la fonction modifConfig de la manière suivante :

function modifConfig($blog) {
        $blog->url = 'http://monsitemobile/';
        $blog->settings->system->theme = 'dc2iphone';
}

MyMeta 0.4.1

Dsls — Mon, 28 Jun 2010 10:59:00 +0000

La phase de beta-test est finie, l'heure est venue de sortir mymeta 0.4

Pour les changements majeurs, ce billet les résume déjà.

Depuis la beta3, quelques petits autres changements sont apparus :

La possibilité de restreindre les mymeta affichés dans le widget à une section donnée (widget liste de mymeta)
La suppression de la classe pour la taille des tags quand des mymeta sont affichées en liste (widget valeurs de mymeta)

Le plugin est disponible ici, et bientôt sur le lab.

Note : la version 0.4.1 corrige un problème signalé par Mirovinben, en cas d'installation sur un multiblog. La mise à jour vers la 0.4.1 du plugin se fera pour le blog courant. Pour les autres blogs, il faudra passer par la page d'administration du plugin au moins une fois pour que les settings soient migrés correctement.

Plugin QuickCat pour dotclear

Dsls — Tue, 22 Jun 2010 11:01:00 +0200

Ce plugin permet de créer une nouvelle catégorie à la volée, lors de l'édition d'un billet.

Le plugin crée une nouvelle entrée dans le combo "Catégorie" dans l'édition d'un billet.

Le plugin est disponible ici et très bientot directement sur dotaddict :)

Il a été teste sur 2.2beta, avec IE7, firefox 3.6 et Chrome, mais marche peut-être sur une 2.1 et d'autres navigateurs ...

Sur le chemin de la 2.2 : une histoire de compilateurs

Dsls — Thu, 17 Jun 2010 11:19:00 +0200

S'il y a bien un point qui a été débattu sur dotclear 2 par rapport à dotclear 1, c'est bien la couche intermédiaire qu'il ajoute pour les développeurs de thèmes, à savoir son moteur de templates.

Pour faire son propre thème, plus besoin de coder des pages en PHP, un nouveau langage intermédiaire a été introduit. Et cela, d'abord pour des raisons de souplesse : ce langage est converti en code php, ce dernier étant stocké en cache. Le theme-designer n'a pas à maîtriser PHP pour faire son thème Ensuite, parce qu'empêcher l'utilisation de PHP, c'est aussi empêcher d'insérer du code potentiellement vulnérable.

Dans le principe, c'est plutôt simple : lorsqu'un utilisateur va sur une page du blog, dotclear va chercher le fichier de template correspondant, le transforme en un fichier PHP, et exécute ce dernier. Le fichier PHP est bien entendu placé en cache afin de ne pas repasser systématiquement par la case compilation.

Je vais essayer de décrire les rouages du compilateur/moteur de templates dans ce billet, ainsi que les évolutions qui lui ont été apportées depuis la 2.1.7.

(Attention, contenu très technique inside)

Le compilateur de la version 2.1.7

Avec dotclear 2.1, le moteur de templates est diablement court en terme de code, et pas moins efficace. Son fonctionnement est le suivant :

Le moteur récupère la liste des blocs déclarés
Pour chaque bloc déclaré, il recherche <tpl:Nomdubloc>...</tpl:Nomdubloc> (j'ai volontairement omis les attributs, pour simplifier)
A chaque bloc trouvé, remplace ce bloc par ce que retourne le traitement de ce bloc (qui a été enregistré via $core->tpl->addBlock)
Le moteur récupère la liste des valeurs déclarées
Pour chaque bloc déclaré, il recherche {{tpl:NomdeLavaleur}}
A chaque valeur trouvée, il appelle le traitement correspondant à la valeur

Techniquement, les recherches/appels s'effectuent via la méthode PHP preg_replace_callback. Les expressions régulières utilisées sont :

$this->tag_block = '<tpl:(%s)(?:(\s+.*?)>|>)(.*?)</tpl:%s>';
$this->tag_value = '{{tpl:(%s)(\s(.*?))?}}';

(les %s sont remplacés par le nom du bloc/tag en cours)

Avantages du compilateur v2.1.7

il a été grandement éprouvé, et fonctionne a priori partout

Inconvénients

Les performances sont inversement proportionnelles au nombre de blocs/valeurs déclarés. Chaque nouveau bloc entraînera un appel à preg_replace_callback supplémentaire
Il n'est pas possible d'imbriquer 2 blocs ayant le même nom
un appel de gestion d'un bloc ne garantit pas que le contenu de ce bloc est du code compilé. Un traitement de bloc peut très bien recevoir comme contenu des <tpl:Block>...</tpl:Block> ou {{tpl:Value}}
les blocs/valeurs inconnus ne sont pas détectés, ils sont laissée tels quels dans le code généré

Le compilateur de la version 2.2beta1

L'évolution apportée dans le compilateur de la 2.2beta1 consiste principalement à optimiser le compilateur précédent, et à permettre l'imbrication des balises homonymes.

Son fonctionnement est le suivant :

Le moteur cherche dans le template une chaîne du type <tpl:'quelquechose'>[...]</tpl:'quelquechose'>, en imposant que [...] ne contienne ni <tpl:quelquechose>, ni </tpl:quelquechose>. En clair, si 2 tags homonymes sont imbriqués, on choisit le plus imbriqué
Pour chaque bloc trouvé, s'il a été enregistré on remplace le bloc par le traitement correspondant
tant qu'on a fait au moins un remplacement, on réitère en 1.
Le moteur cherche dans le template une chaîne du type {{tpl:'quelquechose'}}
Pour chaque texte trouvé, si la valeur correspondante a été trouvée, on appelle le traitement correspondant

Techniquement, les recherches/appels s'effectuent toujours via preg_replace_callback. Les expressions régulières utilisées sont :

$this->tag_block = '<tpl:(\w+)(?:(\s+.*?)>|>)((?:[^<]|<(?!/?tpl:\1)|(?R))*)</tpl:\1>';
$this->tag_value = '{{tpl:(\w+)(\s(.*?))?}}';

Attention au mal de crâne : la regexp utilise une structure récursive (?R). Une autre illustration de ces structures (dont s'est fortement inspiré celle de doclear) est montrée dans la documentation PHP (exemple 3)

Avantages du compilateur v2.2beta1

Support des balises homonymes imbriquées
Gain de performances élevé (environ 3 fois plus rapide que la version précédente)
On peut détecter les blocs/valeurs inconnus

Inconvénients

un appel de gestion d'un bloc ne garantit pas que le contenu de ce bloc est du code compilé. Un traitement de bloc peut très bien recevoir comme contenu des <tpl:Block>...</tpl:Block> ou tpl:Value
on ne peut pas détecter certaines erreurs, comme un bloc non fermé. Le code correspondant sera alors laissé intact
et l'inconvénient majeur : la regexp utilisée entraîne une forte consommation de mémoire sur la pile par le PCRE. Les appels aux traitements de blocs/valeurs s'effectuant au sein de l'appel à preg_replace_callback, il peut arriver fréquemment des erreurs de dépassement de pile. Cela se traduit dans le meilleur des cas par un comportement bizarre, et dans le pire des cas par une erreur 500, voire d'un crash d'apache.

Le nouveau compilateur

La situation laissée par le compilateur de la 2.2beta1 n'est pas acceptable en l'état. Même s'il est possible de contourner le problème dans certains cas, cela laisse sur la touche certains utilisateurs.

Avant de parler du nouveau compilateur, un petit retour aux fondements de la compilation. Les 2 "compilateurs" précédemment cités ne sont pas de vrais compilateurs au sens puriste du terme. Ce sont plutôt de gros moteurs de recherche/remplacement. Lorsqu'on parle de compilateur, on évoque en général plusieurs phases :

L'analyse lexicale, qui consiste à transformer le code en entrée en séquence de jetons (token). c'est en général pris en charge par un Lexer (exemple d'outils : lex/flex)
L'analyse syntaxique, qui consiste à vérifier l'enchaînement des jetons à partir d'une grammaire, et à générer une structure d'arbre interprétant le code en entrée (exemple d'outils : yacc/bison)
L'analyse sémantique, qui enrichit l'arbre précédent d'informations sémantiques (ex: tables de symboles, vérifications de typage, ...)
la génération du code, en parcourant l'arbre enrichi.

(J'ai volontairement simplifié les étapes, il y a d'autres étapes intermédiaires dans un processus complet)

Malheureusement, au niveau de PHP, on est assez mal loti côté outils qui faciliteraient notre compilation. Par ailleurs, la grammaire des templates dotclear est relativement basique, on a des blocs, des valeurs, et du texte... pas besoin d'avoir ces 3 étapes, donc. En revanche, elles vont grandement servir d'inspiration. N'oublions pas non plus qu'il n'est pas souhaité faire une usine à gaz, les performances doivent rester correctes.

Le nouveau compilateur fonctionne donc de la manière suivante :

Découpage lexical du template. A ce niveau, on profite de preg_split pour saucissonner le fichier. on récupère ainsi un tableau contenant des "tokens" qui sont soit du texte, soit un tag d'ouverture ou de fermeture de bloc, soit un tag de valeur.
On parcourt la liste des tokens, en construisant progressivement un arbre php (une structure "classique" d'arbre objet a été définie pour l'occasion)
On demande à l'arbre de se compiler. Si c'est une liste de tokens ou un bloc, on retourne la concaténation des compilation des enfants

Techniquement, le preg_split utilisé est le suivant :

$blocks = preg_split(
	'#(<tpl:\w+[^>]*>)|(</tpl:\w+>)|({{tpl:\w+[^}]*}})#msu',$fc,-1,
	PREG_SPLIT_DELIM_CAPTURE|PREG_SPLIT_NO_EMPTY);

Avantages du nouveau compilateur

on se rapproche plus d'une vraie compilation
on a un contrôle poussé de la grammaire : il est possible de trouver des blocs/valeurs inexistants, et de contrôler que les blocs sont correctement fermés
on a la garantie que quand on appelle un bloc, son contenu a été compilé auparavant.
les performances sont moindres que le compilateur 2.2beta1, mais on note toutefois un gain de performances de l'ordre de 15%
les regexp utilisées sont plus légères que le compilateur 2.2beta1. De plus, les blocs et valeurs sont traités en dehors du moteur PCRE.

Inconvénients

le compilateur est tout frais, et même si plusieurs ont validé son bon fonctionnement, il peut rester quelques défauts
ce compilateur consomme un peu plus de mémoire (heap) que les précédents.

Reste à valider que tout fonctionne correctement avec ce nouveau compilateur :)

Sur le chemin de la 2.2 : balises et behaviors

Dsls — Thu, 17 Jun 2010 09:55:00 +0200

Après une petite pause, suite des évolutions de dotclear 2.2beta :

pour les auteurs de thèmes, les nouveautés côté balises de templates
pour les auteurs de plugins, la liste des nouveaux behaviors

Changements côté balises de templates

Peu de changements de ce côté, outre quelques réparations de bugs, si ce n'est une évolution de taille : les critères de tri des balises tpl:Comments et tpl:Entries ont été améliorés.

Il est désormais possible de spécifier plusieurs critères de tri.

Exemple : si on souhaite afficher les billets sélectionnés d'abord, et conserver ensuite le tri par date décroissante, il suffit d'utiliser la structure :

<tpl:Entries sortby="selected desc,date desc">
[...]
</tpl:Entries>

Pour des raisons de compatibilité, l'attribut order permet de spécifier le sens de tri à prendre par défaut s'il n'est pas précisé ("asc" ou "desc") Les critères de tri disponibles pour les billets sont :

"title" : tri par titre de billet
"selected" : tri par billet sélectionné
"author" : tri par auteur
"date" : tri par date
"id" : tri par id de billet
"comment" : tri par nombre de commentaires
"trackback" : tri par nombre de rétroliens

Les critères de tri disponibles pour les commentaires sont :

"author" : tri par auteur
"date" : tri par date
"id" : tri par id de billet

Par ailleurs, les auteurs de plugins seront ravis d'apprendre que les critères sont extensibles via le behavior templateCustomSortByAlias créé pour l'occasion. Nous y reviendrons dans un prochain billet.

Les behaviors

Ci-dessous, la liste des nouveaux behaviors introduits, en plus de ceux déjà décrits précédemment. La documentation exhaustive de chaque behavior sera disponible sur le site de documentation

Coté administration

L'administration des commentaires bénéficie désormais de ses propres behaviors

adminCommentHeaders : enrichit les headers de la page d'édition d'un commentaire.

La liste des commentaires peut maintenant accueillir des actions personnalisées. Les behaviors définis sont similaires à ceux utilisés pour les actions des billets :

adminCommentsActionsCombo : enrichit la liste des actions pour les commentaires.
adminCommentsActions : ajoute un traitement particulier pour une action donnée
adminCommentsActionsContent : permet l'affichage d'une page intermédiaire lors du traitement personnalisé, avant soumission (ex : saisie d'un champ)

Un petit oublié dans les versions précédentes :

adminBeforeCommentDelete : action avant la suppression d'un commentaire
adminPostsActionsHeaders :

Et un début de behaviors pour la gestion des utilisateurs

adminUsersActionsCombo :enrichit la liste des actions pour les utilisateurs.

Au niveau du core

coreBeforeCategoryCreate et coreAfterCategoryCreate : appelés avant et après la création d'une catégorie
coreBeforeCategoryUpdate et coreAfterCategoryUpdate : appelés avant et après la mise à jour d'une catégorie
coreBeforeLogCreate et coreAfterLogCreate : appelés avant et après la création d'un log
coreBeforePostCreate et coreAfterPostCreate : appelés avant et après la création d'un billet
coreBeforePostUpdate et coreAfterPostUpdate : appelés avant et après la mise à jour d'un billet

Gestionnaire de médias

coreMediaConstruct : appelé à l'initialisation de dcMedia

Partie publique

templateCustomSortByAlias : ajout des critères de tri personnalisés
urlHandlerGetArgsDocument : permet de modifier très tôt l'URL appelée pour y faire des traitements spécifiques

Plugin IntegrityCheck 1.0 pour dotclear2

Dsls — Fri, 11 Jun 2010 15:09:00 +0000

Ce plugin permet de vérifier que les fichier natifs de dotclear 2 n'ont pas été altérés depuis l'installation.

Il sert notamment à vérifier qu'une éventuelle défaillance d'un plugin ne vient pas d'un mauvais transfert d'un fichier du core, ou d'un oubli de transfert.

Il est compatible depuis la version 2.1.5 de dotclear (et peut-être même les versions antérieures), jusqu'à la dernière 2.2beta.

Le plugin est disponible ici

MyMeta 0.4beta : les changements techniques

Dsls — Wed, 09 Jun 2010 15:55:00 +0200

Après avoir brièvement présenté la version 0.4beta, les détails techniques pour ceux qui ont déjà du code MyMeta fonctionnel...

Pour éviter les confusions par la suite, et parce qu'il y a des ambigüités avec la terminologie Metadata, les termes utilisé dans MyMeta sont :

Identifiant de mymeta : correspond à la colonne "ID" dans l'administration, c'est aussi la valeur renseignée dans la colonne meta_type en base de données
Type de mymeta : type de données entrées dans l'administration (chaîne, liste de valeurs, checkbox, ...)
Valeur de mymeta : valeur spécifiée dans la colonne mymeta correspondante lors de l'édition d'un billet, c'est aussi la valeur renseignée dans la colonne meta_id en base de données

Note: en écrivant cette documentation, je me rends compte qu'il reste pas mal d'incohérences, et du code à simplifier. La documentation sera mise à jour en conséquence lors de la 0.4 finale. La présentation de ce billet ne me plaît pas non plus, je ferai plus clair dès que j'ai le temps ;)

Blocs

<tpl:MyMetaData>...</tpl:MyMetaData>

Contextes d'utilisation

Dans un fichier de template de type mymetas.html

Paramètres

les mêmes que pour tpl:Tags (anciennement tpl:MetaData)

Description

Récupère l'ensemble des valeurs de mymeta pour le mymeta en cours

<tpl:MyMetaIf>...</tpl:MyMetaIf>

Contextes d'utilisation

Au sein de blocs où le contexte "posts" est défini (tpl:Entries par exemple)
Dans le template post.html

Paramètres

type (obligatoire): ID du mymeta à tester
defined="true" : affiche le contenu du bloc si le mymeta est défini
value : affiche le contenu du bloc si le mymeta a bien la valeur renseignée

Description

Teste la valeur ou l'existence d'une valeur de mymeta pour le billet en cours

Valeurs

Contextes d'utilisation

Dans une boucle tpl:MyMetaData ou similaire (tpl:Tags, ou tpl:EntryTags par exemple)
Dans un fichier de template de type mymeta.html

Paramètres

aucun

Description

Affiche le type de métadonnée (qui est l'ID du mymeta, et correspond au meta_type en base).

Contextes d'utilisation

Si le paramètre id est défini, n'importe où
Sinon :
- dans une boucle tpl:MyMetaData
- dans les templates mymetas.html et mymeta.html

Paramètres

id (facultatif) : identifiant du mymeta
type : identique à type, déprécié

Description

Affiche l'invite d'un mymeta (s'il est activé):

Si id est spécifié, affiche l'invite du mymeta correspondant
Sinon, affiche l'invite du mymeta dans le contexte de la page ou de la boucle tpl:MyMetaData

Contextes d'utilisation

dans une boucle tpl:MyMetaData
dans les templates mymetas.html et mymeta.html

Paramètres

id (facultatif) : identifiant du mymeta
type : identique à type, déprécié

Description

Affiche la valeur d'un mymeta (s'il est activé):

Si id est spécifié, affiche la valeur du mymeta correspondant
Sinon, affiche la valeut du mymeta dans le contexte de la page ou de la boucle tpl:MyMetaData

Note: cette balise a un comportement différent dans MyMeta 0.3. Dans un contexte de billet, en 0.4, il faut utiliser tpl:EntryMyMetaValue

Contextes d'utilisation

dans une boucle tpl:MyMetaData
dans les templates mymetas.html et mymeta.html

Paramètres

id (facultatif) : identifiant du mymeta
type : identique à type, déprécié

Description

Affiche l'URL d'un mymeta (s'il est activé):

Si id est spécifié, affiche l'URL du mymeta correspondant
Sinon, affiche la valeut du mymeta dans le contexte de la page ou de la boucle tpl:MyMetaData

Contextes d'utilisation

Au sein de blocs où le contexte "posts" est défini (tpl:Entries par exemple)
Dans le template post.html

Paramètres

id (obligatoire): identifiant du mymeta
type : identique à type, déprécié

Description

Affiche la valeur d'un mymeta (s'il est activé) correspondant à l'ID donné pour le billet en cours (dans la boucle, ou le billet courant si dans le template post.html par exemple)

Plugin MyMeta 0.4beta2

Dsls — Tue, 08 Jun 2010 00:58:00 +0200

Il s'est passé du temps depuis la dernière version du plugin MyMeta. Pourtant le développement ne s'est pas arrêté, loin de là.

La version 0.4 constitue une évolution majeure du plugin, incluant une refonte des mécanismes internes. La version 0.4-beta est disponible au téléchargement, tous les feedbacks sont les bienvenus.

Nouvelle administration

L'administration du plugin a été revue pour plus de souplesse.

Il est possible d'ordonner les mymeta, et de les placer dans des sections particulières
Deux nouveaux types de mymeta voient le jour : Date (enfin!) et checkbox. Le nouveau modèle plus souple permet d'ailleurs de définir de nouveaux types de mymeta sans casser la structure existante. Un plugin externe peut ainsi enregistrer ses propres types de mymeta
Pour chaque mymeta, il est désormais possible de définir :
- Si une page publique est définie pour afficher les valeurs du mymeta, ou la liste des billets correspondant à une valeur donnée
- les fichiers de template à utiliser pour ces pages publiques (par défaut mymetas.html et mymeta.html)
- les types de billets concernés par ce mymeta. Avec l'arrivée du plugin muppet, cela prend tout son sens.
Il est possible d'appliquer des mymeta sur plusieurs billets, via la liste des billets

Il est possible de renommer une valeur mymeta pour tous les billets

Widgets

2 widgets font leur apparition :

la liste de MyMeta, affichant les mymeta définis pour le blog
La liste de valeurs MyMeta (similaire au widget Tags), affichant l'ensemble des valeurs prises par un mymeta donné

Balises template

Il y a quelques changements au niveau des balises tpl pour la partie publique, je reviendrai dessus prochainement. En attendant, si vous avez inséré des balises MyMeta dans un thème, je vous invite à attendre le prochain billet sur le plugin.

Téléchargement

Le plugin en version 0.4-beta2 (compatible dotclear 2.1.6 et supérieur) est disponible ici : MyMeta 0.4 beta

Note: la beta2 corrige quelques bugs au niveau du widget et de l'attribut "key" de tpl:EntryMyMetaValue

Tout feedback est bien sûr le bienvenu.

Note : pour revenir en arrière vers la version 0.3, en cas de souci :

dans about:config, copiez la valeur mymeta_fields_backup dans mymeta_fields
installer la 0.3.x sans passer par le tableau de bord

Sur le chemin de la 2.2 : les settings

Dsls — Wed, 02 Jun 2010 13:40:00 +0000

Autre nouveauté sous le capot de dotclear 2.2, le changement dans la gestion des settings. Le sujet a déjà été traité sur la liste du lab dotclear, mais cela ne fait pas de mal d'en rappeler principes

dotclear 2.1 proposait regrouper les settings en "namespaces", mais ces namespaces n'étaient pas utilisés directement dans la récupération des settings : pour récupérer un setting, il fallait faire appel à $core->blog->settings-><nomdusetting>.

Conséquence intrinsèque, il était impossible de définir 2 settings de même nom dans 2 namespaces différents

dotclear 2.2 ajoute le nom de namespace dans la récupération des settings. Là où en 2.1.7 on utilise $core->blog->settings->themes_path par exemple, en 2.2 on utilisera désormais $core->blog->settings->system->themes_path

L'ancien mécanisme d'appel des settings sera toujours opérationnel en 2.2, mais il est fortement conseillé de faire évoluer les plugins vers les nouvelles méthodes. Pour ce faire :

Remplacer tous les appels à $core->blog->settings->setNameSpace() par $core->blog->settings->addNameSpace()
Remplacer les appels à $core->blog->settings->setting par des appels à $core->blog->settings->namespace->setting
Remplacer les appels à $core->blog->settings->put() par des appels à $core->blog->settings->namespace->put()

Par ailleurs, les nouveaux nommages des settings incluant le nom du namespace, on peut se passer complètement de l'appel à $core->blog->settings->setNameSpace. L'appel à $core->blog->settings->addNameSpace() n'est obligatoire que dans le cas d'ajout d'un setting, si on n'est pas sûr que le namespace existe déjà

A noter, si votre blog est configuré en mode DEBUG, et uniquement dans ce cas (voir à cet effet les lignes à décommenter dans inc/prepend.php) un NOTICE PHP apparaîtra en cas d'utilisation d'un plugin se basant sur les anciens mécanismes.

Sur le chemin de la 2.2 : au revoir Metadata, bonjour Tags

Dsls — Wed, 02 Jun 2010 09:04:00 +0000

Le passage à dotclear 2.2 est l'occasion de remettre à plat le plugin Metadata.

Jusqu'alors, Metadata avait 2 rôles : la gestion des métadonnées, et la gestion des tags. Metadata fera désormais partie intégrante du core de dotclear, sous la forme du fichier inc/core/class.dc.meta.php.

Les parties spécifiques à la gestion des tags ont été déplacées au sein d'un nouveau plugin livré de base, le plugin Tags.

D'autres améliorations ont été apportées :

Maintenant qu'il est intégré au core, il n'est plus besoin d'instancier la classe dcMeta à tout-va. Une instance est désormais systématiquement créée dans $core->meta
La méthode $core->meta->getMeta est dépréciée. L'ancienne méthode avait pour signature :

public function getMeta($type=null,$limit=null,$meta_id=null,$post_id=null) {

Il faudra désormais compter sur deux nouvelles méthodes :

public function getMetadata($params=array(), $count_only=false){}
public function computeMetaStats($rs) {}

Concrètement, getMeta avait 2 rôles : récupérer des métadonnées, et calculer les statistiques de ces métadonnées (occurences d'apparition, notamment utilisées par les nuages de tags). Ces 2 rôles sont désormais séparés.

getMetadata récupère les métadonnées en fonction de certains critères. Son mécanisme est très similaire à getPosts de $core->blog. $params peut prendre les attributs suivants :

meta_type : récupère les métadonnées d'un type donné
meta_id : récupère les métadonnées ayant une valeur donnée
post_id : récypère les métadonnées d'un billet donné
limit : limite le nombre d'entrées récupérées
order : spécifie l'ordre de récupération des métadonnées

computeMetaStats enrichit le résultat renvoyé par getMetadata en y insérant les champs statistiques percent et roundpercent.

En pratique, un ancien appel à getMeta de la forme :

$meta = new dcMeta($core);
$rs_meta = $meta->getMeta($type,$limit,$meta_id,$post_id);

sera à modifier en :

$rs_meta = $core->meta->getMetadata(array(
	'meta_type' => $type,
	'meta_id' => $meta_id,
	'post_id' => $post_id,
	'limit' => $limit));

ou, s'il y a des statistiques à récupérer, en :

$rs_meta = $core->meta->computeMetaStats(
		$core->meta->getMetadata(array(
			'meta_type' => $type,
			'meta_id' => $meta_id,
			'post_id' => $post_id,
			'limit' => $limit)));

L'ancienne méthode getMeta est toujours présente pour des raisons de compatibilité avec l'existant.

Sur le chemin de la 2.2 : urlHandlers et gestion d'erreurs

Dsls — Wed, 02 Jun 2010 07:21:00 +0000

Autant le premier article de la série était tout public, autant celui-là est principalement dédié aux développeurs de plugins.

Dotclear 2.2 introduit de nouveaux mécanismes au niveau des urlhandlers, afin de faciliter la vie des plugineurs.

Nouveaux behaviors

De nouveaux behaviors ont été ajoutés à bas niveau dans la gestion des urlHandlers, ils sont au nombre de 3 : urlHandlerBeforeGetData, urlHandlerBeforeSearchCount et urlHandlerGetArgsDocument.

urlHandleBeforeGetData est appelé juste avant de servir un fichier de template. Il permet notamment de changer au dernier moment le fichier à livrer.

Exemple pratique basé sur l'astuce de Pep pour servir un template personnalisé pour une catégorie donnée. Le code à produire devient grandement réduit, et évite de réécrire du code du core :

$core->addBehavior('urlHandlerBeforeGetData',array('myBehaviors','beforeGetData'));
class myBehaviors
{
	public static function beforeGetData($_ctx)
	{
		global $core;
		if ($_ctx->current_tpl == "category.html") {
			$tpl = 'category-'.$_ctx->categories->cat_id.'.html';
			if ($core->tpl->getFilePath($tpl)) {
				$_ctx->current_tpl = $tpl;
			}
		}
	}
}

Le handler en question récupère le contexte en paramètre, et il peut le modifier à sa guise. Dans notre cas, si category-<id_cat>.html existe, alors il est servi en lieu et place de category.html

urlHandlerBeforeSearchCount permet d'agir avant d'afficher le nombre de résultats dans la page search.html. avec dotclear 2.1.7, il n'était pas possible de modifier la requête de comptage des billets correspondant à la recherche. Le behavior prend en paramètre le tableau de paramètres ($params) qui sera transmis à la requête getPosts

urlHandlerGetArgsDocument permet de modifier les arguments avant l'appel du handler. Le behavior prend en paramètre l'urlHandler courant, dont on peut réaffecter les attributs. On peut imaginer par exemple un plugin extraierait des informations supplémentaires à la fin de l'url d'un billet (ex: /fr, /page/xxx si le plugin gère la pagination de billet), et qui restaurerait l'url attendue par l'urlhandler, ni vu, ni connu.

Gestion des pages d'erreur

Avec dotclear 2.1.7, il n'était pas possible de gérer des pages d'erreurs particulières, en dehors d'une modification de la page 404.html : lorsqu'un urlHandler ne savait pas quoi faire de l'url entrée, ou détectait qu'elle correspondait à une page inexistante, il renvoyait vers la dcUrlHandler::p404(), et rien n'était interceptable à ce niveau-là.

doclear 2.2 introduit une gestion des pages d'erreurs, par le biais la méthode "registerError" ajoutée à clearbricks:

class urlHandler
{
	...
	public function registerError($handler){}
	...
}

Désormais, lorsqu'un urlHandler ne sait pas servir une page donnée (ex: page non trouvée, erreur de traitement, ...), plutôt que de rappeler dcUrlHandler::p404, il lui suffit de lever une exception, avec pour code le code d'erreur http voulu. Pour garder une compatibilité avec les anciens plugins, l'ancienne méthode dcUrlHandler::p404 a été modifiée comme suit :

public static function p404()
	{
		throw new Exception ("Page not found",404);
	}

A ce niveau-là, doclear intercepte l'exception, et déroule les handlers d'erreur un par un (dernier enregistré, premier servi), jusqu'à ce qu'un handler d'erreur lui indique qu'il a traité la page. En dernier recours, c'est le le handler d'erreur par défaut de dotclear qui sert la page, en l'occurrence l'ancien p404.

Au niveau du plugin, pour enregistrer un nouvel errorHandler, ça se passera au niveau du _public.php :

$core->url->registerError(array('myPublicBehaviors','error'));

class myPublicBehaviors
{
	public static function error($args,$type,$e) {
		// exemple de filtrage pour une erreur 404
		if ($e->getCode() == 404) {
			if (iCanHandleErrorAndServePage) {
				// Traitement spécifiques, et renvoi de la page
				return true;
			}
	}

Les paramètres transmis au handler sont :

$args contient les arguments transmis à l'urlHandler initial
$type contient le type d'urlHandler appelé ('post', 'category', 'archive', ...). Il correspond au type enregistré lors de l'appel à $core->url->register
$e contient l'exception levée

Si l'errorHandler retourne true, dotclear arrête de parcourir les errorHandlers et considère le traitement comme OK. Sinon il passe par le handler suivant.

Si vous voulez voir une mise en pratique de ce nouveau mécanisme d'errorHandler, allez faire un tour du coté du plugin meuh, qui intercepte les erreurs pour voir dans une table d'alias si un billet n'avait pas l'url donnée auparavant.

Sur le chemin de la 2.2 : les changements visibles

Dsls — Tue, 01 Jun 2010 19:43:00 +0200

Ils sont peu nombreux, mais ils sont quand même là, coté administration. Ce (court) billet les détaille.

Administration : tableau de bord

Le "billet rapide" est désormais repliable :

Administration : billets/commentaires

Gmail a fait des émules : il est désormais possible de sélectionner/désélectionner une plage de billets/commentaires. Pour ce faire, cliquez la case à cocher à coté du premier billet, et shift-cliquez sur la case à cocher à coté du dernier billet à sélectionner...
Une option "aucune sélection" fait son apparition dans les listes de billets/commentaires

Au niveau de l'édition de billets, l'auto-complétion des tags est active : entrez le début d'un tag, et il proposera les tags déjà existants. Cela fonctionne aussi lors de l'ajout de tags à un ensemble de billets.

Coté tags, au niveau des préférences utilisateurs, il est possible de choisir si on souhaite une liste courte (toutefois extensible via un lien "tous les tags"), ou la liste complète des tags dans la barre de droite de l'édition des billets.

Administration : utilisateurs

Le statut admin/super admin des utilisateurs est visualisable dans la liste des utilisateurs, via une "médaille"

Du coté des widgets

Si le blogroll est vide, le widget "Liens" ne sera pas affiché
Le widget tags propose une nouvelle option, permettant de ne pas afficher le lien "tous les tags"

Et plus généralement

jquery passe en version 1.4.2, coté public et administration
Si le blog est mis hors-ligne, un message d'erreur explicite s'affiche coté public.

Sur le chemin de la 2.2 ...

Dsls — Tue, 01 Jun 2010 19:06:00 +0200

Ce ne sera une surprise pour personne, ça a déjà été annoncé: dotclear 2.2 sortira "quand il sera prêt". Mais visuellement rien ne sera bien différent. Et pourtant, ce sont nombre de corrections de bugs et de nouvelles fonctionnalités qui apparaissent sous le capot.

Je vais donc essayer de dégrossir les nouveautés au travers de quelques billets thématiques. Ils seront pour la plupart destinés aux développeurs de plugins, afin qu'ils puissent pleinement tirer partie des nouvelles fonctionnalités, mais pas qu'eux... Dans le désordre :

les changements visibles, car il y en aura quand même un peu
du nouveau dans les urlhandlers et la gestion des pages d'erreurs
La "corification" des tags
la gestion des settings
Balises de template et behaviors
Le moteur de templates évolue

Les différents billets seront postés et mis à jour au fur et à mesure du recensement des évolutions apportées au core...

Morefnu.org

Nouvelles du front

Ajouter des fonctions au plugin ExpAt

Plugin ExpAt pour Dotclear 2.2

Le constat

Une solution

Le moteur d'expressions

"One last thing..."

"One very last thing..."

L'affichage

Les variables

Cas pratique

La suite

Crédits

Téléchargement

Plugin "Grumph" pour dotclear

Nouvelles balises de template

<tpl:EntryResources> ... </tpl:EntryResources>

<tpl:ResHeader>...</tpl:ResHeader>

<tpl:ResFooter>...</tpl:ResFooter>

{{tpl:ResURL}}

{{tpl:ResTitle}}

{{tpl:ResType}}

Administration

Le truc PHP du jour : hériter dynamiquement d'une classe

Débugger de l'Ajax avec firebug

Plugin Gallery 0.4 pour dotclear 2.2

Version mobile, première

MyMeta 0.4.1

Plugin QuickCat pour dotclear

Sur le chemin de la 2.2 : une histoire de compilateurs

Le compilateur de la version 2.1.7

Le compilateur de la version 2.2beta1

Le nouveau compilateur

Sur le chemin de la 2.2 : balises et behaviors

Changements côté balises de templates

Les behaviors

Coté administration

Au niveau du core

Gestionnaire de médias

Partie publique

Plugin IntegrityCheck 1.0 pour dotclear2

MyMeta 0.4beta : les changements techniques

Blocs

<tpl:MyMetaData>...</tpl:MyMetaData>

Contextes d'utilisation

Paramètres

Description

<tpl:MyMetaIf>...</tpl:MyMetaIf>

Contextes d'utilisation

Paramètres

Description

Valeurs

{{tpl:MetaType}}

Contextes d'utilisation

Paramètres

Description

{{tpl:MyMetaTypePrompt}}

Contextes d'utilisation

Paramètres

Description

{{tpl:MyMetaValue}}

Contextes d'utilisation

Paramètres

Description

{{tpl:MyMetaURL}}

Contextes d'utilisation

Paramètres

Description

{{tpl:EntryMyMetaValue}}

Contextes d'utilisation

Paramètres

Description

Plugin MyMeta 0.4beta2

Nouvelle administration

Widgets

Balises template

Téléchargement

Sur le chemin de la 2.2 : les settings

Sur le chemin de la 2.2 : au revoir Metadata, bonjour Tags