On ajoute pour chaque plugin du core :
- le paquet.xml sous le nom _paquet.xml pour éviter une utilisation par défaut à la place de plugin.xml Il suffira de le renommer pour effectuer les tests.
- les fichiers de langue nécessaire à la description et au slogan.
- un fichier _paquet-migration qui contient les commandes svn pour migrer ou ajouter des fichiers. Ce fichier n'a plus d'autre intérêt que de lister les fichiers à renommer pour retrouver le fonctionnement des balises disparues : install, fonctions et options.
et en particulier de sa valeur 4 qui n'existe plus (feu oo),
l'accessibilite n'etant pas un mode degrade, mais une propriete intrinseque
de l'interface commune a tous.
cela permet
- de cibler .editer au lieu de li ce qui simplifie grandement les css
- de ne pas imposer le balisage html et de faire des formulaires en <p> si on le souhaite
on renomme de façon cohérente pour tous les objets
xxx_inserer
xxx_modifier
xxx_instituer
Les points d'entrée de l'API sont donc
action_editer_xxx pour le traitement global d'un post
xxx_inserer et xxx_modifier pour les operations elementaires
xxx_instituer n'est pas un point d'entree et ne devrait pas etre appelee en direct : il faut passer par xxx_modifier.
Le fichier inc/modifier contenait de façon centralisee des fonctions
revision_xxx pour les objets historiques de SPIP (essentiellement utilisées par les crayons)
Cette construction centralisée n'est pas facilement extensible. On evacue donc chaque fonction dans le action/edtier_xxx de l'objet concerné, et on propose en remplacement un point d'entrée unique
revision_objet($objet,$id,$c)
qui va dispatcher vers la fonction xxx_modifier de l'objet, ou a defaut la fonction generique objet_modifier de
action/editer_objet. Les fonctions revision_xxx sont par ailleurs dépréciées.
Les anciennes fonctions insert&set sont toujours definies et renvoie vers la fonction a nommage conventionnel, pour eviter trop de rupture de compatibilité
- declaration dans declarer_tables_objets_sql pour eviter d'ecrire du code redondant de gestion des puces de changement rapide.
- utilisation du filtre |puce_statut
- suppression du code mort
puce_statut/site donne un exemple de cas particulier : on y gere les puces clignotantes sur la syndication en erreur, et on rend la main a la fonction generique sinon.
cedric@yterium.com