Merci pour ce boulot et ce récapitulatif. J'ai quelques remarques / questions
Hello,
- 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 debuggable. Sur une proposition de fil, le système d'export XML actuel a été sorti du core dans un plugin Connexion · GitLab
qui permet d'assurer la compatibiité au cas où (réimport d'un XML existant). Mais il est remplacé par défaut par l'extension Connexion · GitLab
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.
Sqlite a moins de choix dans les types de champs que MySQL. Donc est-ce qu'on risque pas d'avoir des soucis (du style un BIGTEXT qui se trouve transformer en TEXT). A moins que tu voulais dire que dans la base sqlite d'exporte il y a une table contenant la structure exact SQL ?
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 a 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é inclus avec quelques améliorations, mais n'est actif que pour l'espace privé.
Question : avec un 2.3 sera-t-il encore nécéssaire d'installer ZPIP pour profiter du moteur Z ? (detection automatique des pages-xxx.html, APL etc.)
Parceque par exemple, pour le moment, je suis obligé de surcharger certains fichiers extras / navigation du ZPIP qui sont différenciés selon le type de page alors que je ne veux des blocs identiques sur tout les types de pages.
Je sais pas si je suis très clair ....
- Reforme 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.
- Reforme des formulaires d'interaction
De même, les formulaires d'interaction de l'espace privé sont peu a peu ré-écrits tous 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), #FORMULAIRE_EDITER_LOGO (logo d'un objet), #FORMULAIRE_REDIRIGER_ARTICLE (article virtuel) #FORMULAIRE_RECHERCHE_ECRIRE.
est-ce que qu'on peut pas imaginer un formulaire_dater générique pour tout type d'objet (exemple : #FORMULAIRE_DATE{table,id,champsdateàmodifier} ?
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.
- 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 mathieu a sorti recemment les brèves et les mots. A 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 2 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.
cool pour les pétitions. On pourra facilement ainsi avoir des champs supplémentaires
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/vieiiles_def existant deja 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.
oui, et surtt prévoir un listing quelquepart (je me rappel encore les migrations 1.9 vers 2.0)
- 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. A moins qu'on ne garde le meme nom article en ajoutant un paramètre ? Cela donnerait /?exec=article&id_article=xxx&edit=oui
bonne idée. Pas d'opinion sur la question de la syntaxe.
- 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
Connexion · GitLab, dans une extension themes/ qui est elle en chantier complet
cool. Ca pourrait se conventionner avec un thème Z pour avoir un espace privé ressemblant à l'espace public ?
- 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.
- Integration du gestionnaire de file job_queue
Le plugin est développé sur la zone depuis un petit moment Connexion · GitLab
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 Présentation de Textwheel - ZZZ
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.
encore +cool. Est-ce que cela s'applique qu'aux raccourcis ou aussi au respect de la typofrancaise ?
- Intégration de l'API de mémoization
L'api dévelopée par fil dans le plugin Connexion · GitLab 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.
qui sera donc mis en extension ?
