Bonjour la team @architecture !
Des questions se posent à propos de l’installation de SPIP sur ce vieux ticket Installation : Anticiper les problèmes qui risquent de se poser (#1883) · Tickets · spip / spip · GitLab et il y a des débuts de réponses là :Installation : Anticiper les problèmes qui risquent de se poser (#1883) · Tickets · spip / spip · GitLab
ça intéresse du monde d’en discuter ?
@maieul est pour la mise au point d’un composant PHP commun entre spip_loader et spip lui-même 
…
ça tombe bien, @marcimat et moi-même, avions préparé le terrain en découpant le script spip_loader.php. Ce n’est pas un hasard ^^
Alors, je trouve le sujet et la proposition intéressants, je serai plutôt désireux de m’y pencher avec vous, mais j’ai beaucoup à apprendre sur le fonctionnement de SPIP dans son ensemble et de son installation en particulier ; sans parler d’un petit manque de temps disponible…
Ce ticket propose d’afficher une info / un conseil / un bouton d’action qui pourraient être communs à spip et au spip_loader aussi : l’information sur les tailles de cache et une invitation à faire le ménage cf Faire le ménage en plus de l'upgrade (#56) · Tickets · spip-contrib-outils / spip_loader · GitLab et job / effacer les caches périmés (#4338) · Tickets · spip / spip · GitLab
Petite « nouveautés » : Incohérence du comportement du spip_loader avec SPIP (#64) · Tickets · spip-contrib-outils / spip_loader · GitLab
On reprend démarre la conversation ici ?
Selon moi, ce qu’on appelle le « loader » pourrait, voire devrait, être dans SPIP, et être plus cohérent en intégrant tous les aspects d’une mise à jour, rendant ainsi le script indépendant « spip_loader.php » utile qu’à la première installation …
Ça me parait évident, mais il y avait une opposition à spip_loader à une époque qui me laissait penser qu’il était illusoire d’envisager de l’intégrer au core.
L’idéal serait qu’il fasse, du coup, une mise à jour des plugins avant + mise à jour des dépots et des plugins après, sur demande (case à cocher) ou débrayable (?), et la mise à jour éventuelle de la base de données.
Je pense qu’avec ça, fonctionnellement ça devrait couvrir l’ensemble des opérations d’une mise à jour classique pour les utilisateurs pas trop « technique » (cas d’une personne qui s’installe un SPIP juste pour blogger, en étant seule à y écrire).
Est ce que l’ensemble du système de mise à jour devrait aussi être débrayable (par une constante, une config d’env…) ?
et supprimable, oubliable par les utilisateurices une fois SPIP installé une bonne fois pour toute.
Il pourrait garder son utilité pour remettre d’aplomb une distribution abîmée, mais bon ça sort de la réflexion ci dessus s’il reste installable indépendamment à tout moment.
Je partage ça. Mais j’ai plus souvenir des arguments … ça rappelle quelque chose à quelqu’un·e ?
Alors, on était sur une installation de SPIP … de LA distribution SPIP, donc d’un zip généré lors d’une release.
J’ai l’impression que ta liste de courses empiète sur le rôle de SVP … me trompe-je ?
Liste de courses ? Comme tu y vas…
Tu disais très justement :
Je complétais donc juste la liste des actions à faire pour une mise à jour de SPIP.
Je parle bien de SPIP, par extension d’une distribution contenant ecrire prive squelettes-dist et plugins-dist.
utilisation de composer create-project spip/spip à suivre ici composer create-project - #7 par JamesRezo