Site de test sur lequel j’ai essayé de faire un encart présent sur toutes les pages qui pourrait pointer vers autre chose d’ailleurs, j’ai pas d’idée préconçues … et ça reste à styler proprement, ce qui n’est pas trop mon fort
On pourrait pas aussi déplacer tous les articles changements dans une rubrique « changelog » pour réduire la taille du menu à droite quand on est là Évolutions et mises à jour - SPIP
Quelques travaux plus tard, il s’avère que le fichier spip_loader_list.json qui sert au script spip_loader.php peut aussi être automatisé.
Actuellement, il est mis à jour manuellement dans le dépot du script puis, il est poussé à la place qu’il occupe, manuellement aussi.
J’ai mis en ligne une simulation de ce fichier sur lerebooteux mais ici, le fichier est dynamique et fondé sur les mêmes données que les pages de Versions maintenues.
Avantages : Il n’est plus nécessaire de versionner et mettre à jour le fichier dans le dépôt de l’outil. On peut aussi jouer avec la version de l’api, par exemple avec une version 2 expérimentale en passant un paramètre à l’url comme ceci. À noter que c’est une version qui fournit la liste des versions PHP compatibles, qu’il ne serait plus nécessaire de maintenir dans le script.
Inconvénients : D’une part, la date fournie par le serveur PHP ne dépend pas de la date d’un fichier mais de la requête elle-même. Pour gérer un cache, c’est embêtant. De plus, cela induit une charge serveur qu’il faudrait maîtriser (par exemple, en faisant évoluer le plugin). Enfin, l’URL d’origine, si on souhaite la conserver à des fin de retro-compatibilité, nécessite une configuration apache qui peut s’avérer complexe à mettre en œuvre et pénible à maintenir.
Alternativement, l’automatisation proposée fournit un autre URL basée sur les fonctions action_api() de SPIP qui règle le problème de l’URL original et entre dans la logique API de SPIP. On peut d’ores et déjà trouver cette API sur spip.net.
