Chantiers achevés :

– Système de sauvegarde

L’export XML des versions stables actuelles utilisé en sauvegarde est peu satisfaisant. Il est peu robuste, pose des problèmes au réimport entre versions différentes, plus ou moins bien gérés. Qui plus est, le code est devenu au fil du temps et des corrections de bug un maquis très difficilement débuggable.

Sur une proposition de fil, le système d’export XML actuel a été sorti du core dans un plugin zone.spip.org/trac/spip-zone/browser/_plugins_/dump qui permet d’assurer la compatibiité au cas où (réimport d’un XML existant).

Il est remplacé par défaut par l’extension zone.spip.org/trac/spip-zone/browser/_core_/plugins/dump qui réalise des sauvegardes complètes dans une base SQLite.
La base incluant la structure des tables, cela facilitera la restauration de bases dans une version plus ancienne, qui viendra naturellement avec sa structure et declenchera ensuite un upgrade classique. Par défaut, la sauvegarde sauve bien toutes les tables de la base, plugin actifs ou non, et restaure aussi toute la base, même celles d’un plugin inactif, ce qui était aussi un défaut du système actuel. [2]

Le système de fusion de bases n’a pas été ré-implémenté, car la logique de fusion est particulière à chaque besoin, mais des points d’entrées à la sauvegarde (conditions WHERE sur les tables sauvegardées) et au réimport (fonction d’insertion) ont été prévus pour permettre de réaliser cette fonctionnalité en plugin, le plus simplement possible.

Une API de copie de base à base a été intégrée dans le core, et peux être utilisée pour proposer un outil de migration MySQL↔SQLite par exemple.

– Liste d’objets en squelettes

Le plugin afficher_objets : zone.spip.org/trac/spip-zone/browser/_plugins_/afficher_objets initié par matthieu qui remplace les listes d’objets (articles, brèves, sites, auteurs, ...) présentes un peu partout dans l’espace privé par des squelettes personalisable a été intégré. Corrolairement, les balises macro nécessaires pour cela (#INFO_xxx, #TRI, et #SAUTER) l’ont été aussi ainsi qu’annoncé précédemment. Toutes les listes d"objets de l’espace privé sont donc maintenant ajaxables (ou non, au choix), triables, paginées...

Chantiers en cours :

– Système de squelette de l’espace privé

Le système de fond html unique placé dans prive/exec avec des commentaires HTML pour repérer des blocs était transitoire. Il a été dénoncé récemment à juste raison comme introduisant des nouvelles syntaxes. Ainsi que je l’avais proposé, j’ai implémenté une structure Z (comme ce qui se fait dans Zpip) dans prive/squelettes/, avec les blocs contenu, extra, hierarchie, navigation, top, head, pied.
_Le moteur styliser de Zpip a donc été inclu avec quelques améliorations, mais n’est actif que pour l’espace privé.

On peut donc écrire une page de l’espace privé avec simplement un squelette dans prive/squelette/contenu/, la page sera aussitôt disponible, complètement habillée et complétée par les autres morceaux (Pour plus de détail sur le fonctionnement, la personnalisation de chaque bloc, les blocs par défaut, cf notamment spip-contrib.net/Zpip-et-la-creation-rapide-de-pages).

L’objectif est donc de ré-écrire autant que possible les pages de l’espace privé en squelettes. Une page ecrire/ ?exec=charte permet de voir tous les éléments utilisables en squelette (boites, icones horizontales, verticales, ainsi que leur syntaxe).

– Réforme des pages et formulaires de configuration

Tous les formulaires de configuration ont été réimplémentés en CVT, ce qui permet d’avoir une structure HTML homogène partout, un comportement identique, et de les utiliser dans des squelettes.
Consécutivement, toutes les pages de configuration ont été ré-écrites en squelettes.

– Réforme des formulaires d’interaction

De même, les formulaires d’interaction de l’espace privé sont peu a peu tous ré-écrits au format CVT pour pouvoir être utilisés dans un squelette, proposer des interactions modernes avec message d’erreur etc.
Ont déjà été faits

• #FORMULAIRE_DATER (date d’un article) [3],
• #FORMULAIRE_EDITER_LOGO (logo d’un objet),
• #FORMULAIRE_REDIRIGER_ARTICLE (article virtuel),
• #FORMULAIRE_RECHERCHE_ECRIRE.

Il reste encore principalement le formulaire de traduction (langue de l’article, ecrire une nouvelle traduction etc.) à réformer en CVT. Cela va naturellement s’accompagner d’une généralisation du code pour permettre d’appliquer ces actions à n’importe quel objet disposant d’un champ lang et id_trad.

– API editer_liens

Pour traiter le cas de formulaire d’association d’auteur à un article, j’ai généralisé les tables spip_auteurs_articles, spip_auteurs_messages et spip_auteurs_rubriques en une unique table spip_auteurs_liens, sur le modèle de ce qui avait déjà été fait sur spip_documents_liens en 2.0. Matthieu a fait de même sur les mots avec une unique table spip_mots_liens.

Une API proposée dans action/editer_liens permet d’associer, dissocier, qualifier, trouver les liens entre objets en fournissant uniquement le nom des objets et leur type. Cette API permet de traiter de manière générique les liens entre objets.

Sur cette base, j’ai mis en place un #FORMULAIRE_EDITER_LIENS générique, qui repose sur deux vues en squelettes (une pour lister les liens existants, et une pour les liens que l’on peut ajouter). Les vues pour les auteurs ont déjà été créées, et cela permet donc d’utiliser #FORMULAIRE_EDITER_LIENS{auteurs, article, 23} pour éditer les auteurs de l’article 23. Mais aussi de faire de même sur n’importe quel objet (brève, document, site, nouvel objet d’un plugin ...).

De même, une fois les vues mots_lies et mots_associer implémentées, les mots pourront être associés nativement à n’importe quel objet de SPIP, sans avoir à écrire le moindre code ni la moindre interface nouvelle.

– Découpe du Noyau en extensions

Outre la sauvegarde évoquée plus haut, les pétitions ont été sorties en extension il y a quelques semaines par bruno, et matthieu a sorti récemment les brèves et les mots.

À l’heure actuelle, il ne reste plus que deux chantiers de découpe : une extension regroupant agenda + messagerie qui sont trop intriquées dans le code pour en faire deux extensions pour le moment, et une extension document.
Sur ce dernier point, l’essentiel du refactoring de code (API, recodage en squelettes et CVT) a déjà été fait dans le plugin mediatheque, et il s’agit surtout d’intégrer celui-ci en extension en le nettoyant quelque peu (compatibiité SPIP 2.0 et quelques nommages), et de nettoyer complètement le noyau des références aux documents.

– Déclaration des pipelines du core

Jusqu’ici les pipelines du core étaient déclarés en globale $spip_pipeline à chaque hit de SPIP.
C’était un peu inefficace, car cette globale n’était utilisée qu’au moment de la compilation des pipelines des plugins. Toutes ces déclarations migrent donc dans core.xml qui est maintenant dans ecrire/ et qui contenait déjà toutes les déclarations de menus depuis l’introduction du bandeau.

– Paquet.xml

Éric et Emmanuel travaillent sur une refonte du fichier de déclaration plugin.xml pour permettre la mise en place d’un annuaire centralisé des plugins, alimenté automatiquement à partir de ce simple fichier de déclaration. Ce sera aussi l’occasion de rationaliser certains nommages. Ce point a déjà été abordé sur la liste dev, et pour le moment le travail se fait en dehors du noyau, mais le but est de l’intégrer dans la prochaine version.

Chantiers à venir

– Isolation des vieilles_def

Suite à tous ces chantiers le noyau commence à contenir pas mal de fonctions maintenues juste pour compatibilités. Les isoler dans un conteneur permettrait de dépolluer le noyau et d’alléger, tout en assurant la compatibilité des plugins existant qui les utilisent.
En extensions/ cela permettrait aussi aux projets nouveau de supprimer ce code inutile.

Cela concerne le inc/vieilles_def existant déjà dans les versions précédentes, le inc/afficher_objets, l’ancienne gestion de l’ajax php de l’espace privé (ajax_declencheur, ajax_action_greffe).
Je crois que c’est camille qui avait proposé cela initialement, mais je n’ai plus trace de la discussion.

– Normalisation des pages de l’espace privé

Une fois tous les composants d’interaction réécrits en CVT comme expliqué plus haut, l’essentiel des pages de l’espace privé peut être réécrit en squelettes. Ce pourrait être l’occasion de normaliser le nommage rationnellement pour tous les objets sur la base du nom de l’objet :

• / ?exec=articles pour voir les articles
• / ?exec=article&id_article=xxx pour voir un article
• / ?exec=article_edit&id_article=xxx pour editer un article.

À moins qu’on ne garde le meme nom article en ajoutant un paramètre ? Cela donnerait / ?exec=article&id_article=xxx&edit=oui

– Finalisation système de thèmes

L’espace privé s’appuie sur un système de thèmes qui permet de décliner les css et les icones par thèmes. Il reste à debugger cela, proposer une interface de choix dans les préférences personnelles, et porter par exemple les travaux d’arno réalisés pour la sortie de la 2.1 : zone.spip.org/trac/spip-zone/browser/_plugins_/themes_interface_privee, dans une extension themes/ qui est, elle, en chantier complet

– Nettoyage des icones

La navigation remaniée s’appuie sur des icones 16px. Presque tout les nommages d’icone ont été rationalisés (pour avoir un nom d’icone qui correspond à ce qu’elle exprime et à son usage). Il y a du nettoyage a faire dans prive/images, mais surtout les icones en 16px actuelles ont été obtenues par réduction des icones 24px traditionnelles, ce qui donne un résultat assez moche.

– Intégration du gestionnaire de file job_queue

Le plugin est développé sur la zone depuis un petit moment : zone.spip.org/trac/spip-zone/browser/_plugins_/job_queue
Il permet une gestion de file d’attente de travaux datés, dans laquelle les crons sont inclus. Il modernise ainsi la gestion des crons, en ne déclenchant de hit que lorsque c’est nécessaire, et permet la programmation de travaux aysnchrone (envoi de mails, syndication etc...) par les plugins.

– Intégration de TextWheel

Le projet a été initié par fil, les explications sont sur son blog : zzz.rezo.net/Presentation-de-Textwheel
Il vise à remplacer l’implémentation PHP de tous les traitements typographiques de SPIP par un moteur unique et un ensemble de règles décrites en yaml. Son utilisation permet une optimisation des traitements, qui sont plus rapides. Il s’agirait donc d’intégrer le moteur sous forme de librairie, et les règles dans le noyau.

– Intégration de l’API de mémoization

L’API développée par fil dans le plugin zone.spip.org/trac/spip-zone/browser/_plugins_/memoization permet de gérer l’utilisation de xcache, memcache ou APC pour stocker le cache par exemple, mais aussi le résultat de toute fonction répétitive.