Les pages qui restent à automatiser pour les versions maintenues

Dev
#1

Est-ce que cette page Dernières versions stables - SPIP a encore du sens selon vous ?

Les données très techniques comme les globales sont-elles aussi utiles que ça ?

Sinon, je propose https://www.spip.net/fr_article6652.html?var_mode=preview qui est plus à jour sur le site de test : Branches non prises en charge - SPIPremix

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

Enfin, il y a cette page Configuration requise - SPIP

Bref, n’hésitez pas à faire des retours là-dessus aussi !

1 « J'aime »
#2

Pour moi ça n’a pas de sens de présenter cette page, a priori.

La page que je visite / montre régulièrement est plutôt : Configuration requise - SPIP (Configuration requise)

#3

Je les trouve assez redondantes aussi.

#4

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.

2 « J'aime »
#5

cool tout ça :slight_smile:

#6

Toujours ok avec cette proposition ?

#7

Ah oui c’est bien long ! OK pour moi.

#8

Pour info, j’ai remis les pages https://www.spip.net/ecrire/?exec=article&id_article=4449 en cours de rédaction

1 « J'aime »
#9

La rubrique « Changements » : Changements - SPIP

1 « J'aime »
#10