Je relance un sujet qui j’imagine a dû être discuté de longue date (avant que j’arrive dans la communauté en tout cas), mais ça me questionne.
Dans Spip, tout squelette qui ne correspond pas à un objet éditorial est accessible à l’URL spip.php?page=<le_squelette>.
Je ne crois pas qu’il y ait une appellation officielle pour ces pages/squelettes, ça varie d’un article à l’autre, je vais les appeler simplement des « pages » pour la suite.
Ce ne sont pas toutes des « vraies » pages destinées à être accessibles, il s’agit parfois de squelettes techniques : rss, pseudos fichiers texte, xml, erreurs 40x, etc.
Néammoins, rien qu’avec les squelettes de la dist, j’en compte au moins 4 (exemples sur spip.net) : calendrier, contact, plan, recherche.
À ceci s’ajoutent bien sûr les pages du dossier squelettes et des différents plugins.
2 remarques :
-
Ces pages sont complètement invisibles dans le backoffice. Ce sont des pages accessibles au public et à priori répertoriables par les moteurs de recherche, mais dans le backoffice elles n’existent pas. Il est très facile d’oublier leur existence et d’omettre de les styler (cf. liens précédents).
-
Certains plugins ont besoin de repertorier ces pages pour diverses raisons, mais chacun réimplémente ça à sa façon. J’en compte au moins 3 :
-
Compositions : permet de leur attribuer des compositions. Une page = un squelette + un xml avec une balise
<composition> -
Noizetier : permet de leur ajouter des noisettes. Une page = un squelette + optionnellement un xml avec un balise
<page>(et dernièrement possible avec un yaml je crois). - URLs pages persos : permet de leur attribuer des jolies URLs. Il détecte tous les squelettes/pages en tentant de filtrer ceux qui sont « techniques ».
En résumé, il y a 2 cas de figure pour détecter ces pages :
- Soit il s’agit de pages explicitement déclarées en accompagnant le squelette d’un xml ou d’un yaml, avec au minimum un titre, et optionnellement une description, une icône, etc.
- Soit il s’agit de n’importe quel squelette pouvant potentiellement correspondre à une page (option NOIZETIER_LISTER_PAGES_SANS_XML dans le noizetier par exemple, ou de base dans urls pages perso)
Quoiqu’il en soit, le besoin est identique pour ces 3 plugins.
Partant de là, est-ce qu’on ne pourrait pas déporter la gestion de ces pages dans un plugin à part ? Et les 3 autres pourraient se reposer dessus.
Il ferait principalement 2 choses :
- Fournir une mini API pour répertorier ces pages. Il faudrait donc s’accorder sur un formalisme unique quand on veut déclarer explicitement des pages : par exemple comme pour le noizetier, un yaml avec au minimum un titre. Et optionnellement il faudrait pouvoir restreindre selon certains critères : celles qui contiennent des infos de composition ou de blocs, celles qui proviennent de certains plugins, etc. Je pense qu’il faut garder en sus la possibilité de détecter toutes les pages, même celles non déclarées explicitement avec yaml/xml.
- Rendre ces pages visibles dans le backoffice. Ainsi pour une page donnée, on aurait un point d’entrée unique pour lui attribuer une composition, des noisettes, des jolies URLS… Tout comme les pages des objets éditoriaux quoi.
Bon je m’arrête là pour l’instant. Mais ça fait un moment que je pense à tout ça 
