NotesOk pour discuter de toutes les questions de Matthieu.
Je n’ai pas vraiment de questions, mais des réflexions en bazar qui rejoignent une bonne partie de la liste précédente.
Dans un logiciel comme SPIP, il y a plein de fonctionnalités différentes, mais si on prend un peu de recul, je pense que l’on peut découper en trois grandes zones :
- Édition de contenu : créer et modifier des objets éditoriaux
- Gestion de contenu : stocker, classer, versionner et gérer les droits d’accès
- Publication du contenu : rendre visible aux autres du contenu, que ce soit celui provenant de l’édition OU d’autre part (boucle DATA, etc)
Publication
Je pense que SPIP est assez fort pour publier du contenu, grâce au langage de squelettes qu’il fournit. Ce dernier permet d’accéder facilement à divers contenus (de la base ou d’autre part) et de les intégrer dans n’importe quel document (le plus souvent dans du HTML/CSS). Mais en plus il aide aussi les néophytes à intégrer automatiquement des bonnes pratiques qui de nos jours sont indispensables pour que nos sites soient accessibles au plus grand nombre. Et notamment un système de cache "transparent", quelque soit ce que le créateur décide de publier.
Ce point là est très bien, et nous avons quand même régulièrement d’assez bons retours dessus, de gens qui sont contents. Et plus encore depuis qu’on a la boucle DATA (c’est mon impression en tout cas).
Pour les deux autres points, je trouve qu’il y a de nombreuses et importantes (voire TRÈS importantes) améliorations possibles (voire fortement recommandées).
Édition
Pour ce qui est de l’édition, une des choses que je vois, serait de renverser la perspective API/interface. Cela parait très centré "développeur", mais le but final est exactement contraire ! Je m’explique.
SPIP a été conçu comme un truc "tout-en-un" au départ. Puis ça s’est clarifié au fil du temps. Et par-dessus l’interface d’édition existante, seulement après coup, on a petit à petit construit des morceaux d’API qui aident à faire des actions dans SPIP autrement que par l’interface d’édition "officielle".
Sur un schéma exactement similaire, plusieurs personnes ont fait la même remarque pour Seenthis : Arno a d’abord fait une interface (plutôt jolie et pratique, aucun problème) puis ensuite a ajouté une API pour récupérer ou éditer le contenu depuis autre part.
Mon propos est de dire qu’il faudrait en premier lieu des API très solides et très complètes, que ce soit ça un des gros morceaux du noyau. Et que l’interface d’édition (pas juste ecrire/ mais tous les CVT aussi) ne soit qu’une couche par dessus, pour ceux qui éditent en mode web/HTML/navigateur.
En quoi ce n’est pas centré développeur ? Parce que le but est de fournir plus facilement DES moyens d’éditer le contenu. Soit par l’interface d’administration officielle, soit par email, soit dans un éditeur local, soit depuis d’autres applications distantes, etc. Et cela, sans devoir bidouiller soi-même chacun dans son coin. L’interface "ecrire/" ne serait qu’un seul des moyens, et non plus le point de passage obligé.
J’ajoute à ce gros point précédent, que je pense aussi qu’il faudrait une refonte ergonomique assez importante de l’interface web d’administration fournie par défaut. C’est encore un autre chantier donc, totalement différent, et qui ne porte que sur une seule des interfaces possibles.
Gestion
Dans la suite de la réflexion "en profondeur" sur l’édition, cela m’amène à reconsidérer aussi comment sont gérés les contenus dans SPIP.
La base SQL ça a des avantages certains, notamment de pouvoir faire des demandes assez complexes dedans. Avec des jointures et tout (les articles de tels auteurs ayant les mots machins et placés quelque part dans la branche truc). Mais en vérité, ce que je décris là c’est un besoin qui n’arrive que lors de la publication. Or avant la publication, pour le stockage, l’édition, le versionnage, et bien le fait que ce soit en SQL, dispersé dans plein de tables, pose des problèmes embêtants et pas faciles à résoudre.
On pourrait imaginer que les tables SQL appartenant aux objets SPIP, bref le stockage que nous connaissons actuellement, soit seulement une vue particulière de nos contenus. Ceux-ci étant stockés autre part, autrement, "pour de vrai". Grâce à notre superbe API dont on a parlé précédemment, on aura des moyens de synchroniser notre contenu et sa vue SQL [1].
Si l’on stocke nos contenus dans des fichiers textes classiques, par exemple, dans un format à la fois lisible par une machine mais aussi par un être humain : cela permet alors de versionner le contenu avec un logiciel conçu uniquement pour cela (comme Git par exemple). Cela permet aussi d’éditer facilement le contenu sur sa machine, chez soi, dans le logiciel que l’on veut, sous n’importe quel système.
Dans un nombre important de cas, notamment pour un blog perso ou un site collectif avec peu de personnes, cela rendrait beaucoup plus facile l’édition de contenu à n’importe qui, sans grande connaissance.
Avec cette conception, le plus gros point qui m’embête pour l’instant, ce sont les droits (d’accès, de création et de modification). Je n’arrive pas trop à voir comment on peut programmer, stocker et gérer des droits complexes (pour un site complexe avec beaucoup de contributeurs, par exemple).
Séparer la publication ?
Les parties "édition" et "gestion" ne correspondent pas à tous les besoins. Notamment pour un site perso, uniquement à une personne, il est possible que l’infrastructure obligée, que SPIP nous force à installer avec lui, soit beaucoup trop grosse, beaucoup trop complexe, et sommes toute inutile.
Une idée serait que le moteur de template de SPIP (les squelettes et le cache), soit séparé dans une librairie à part. Pas juste sorti du noyau et mis en plugin. Mais une librairie toute seule à part.
En revanche, l’implémentation de telle ou telle boucle qui serait propre à SPIP, cela serait dans un plugin intégrant cette librairie, ou même dans le noyau puisque de toute façon la distribution de SPIP a l’obligation d’avoir ces squelettes.
Cette librairie (dont il faudrait trouver le nom) est un peu compliquée (pour moi) à extraire du noyau de SPIP, vu le bazar que c’est parfois. Mais ce n’est pas si horrible que ça à faire, je pense que pour quelqu’un qui connaît le compilateur, ce ne doit pas être trop long.
Avec ces squelettes spipiens, et uniquement eux, il est déjà possible pour des habitués de SPIP (et les autres, les boucles étant relativement simples à apprendre) de publier du contenu venant de diverses sources, dont des fichiers textes basiques (en markdown par exemple) et de les intégrer dans un graphisme agréable sans connaître PHP.