SPIP 4.2, Mutualisation et `_NOM_PERMANENTS_ACCESSIBLES` comment le modifier proprement ?

Dev
#1

Bonjour,

Je cherche à mettre en place une mutualisation de sites SPIP en 4.2+

Pour cela j’aurais besoin évidemment de pré-définir la constante _NOM_PERMANENTS_ACCESSIBLES en fonction de chaque site (il y aura aussi d’autres constantes à pré-définir comme _NOM_PERMANENTS_INACCESSIBLES, etc… mais je verrais ça dans un deuxième temps quand j’aurais trouvé comment faire pour _NOM_PERMANENTS_ACCESSIBLES)

Selon la documentation _NOM_PERMANENTS_ACCESSIBLES - SPIP il faut modifier ça dans ecrire/inc_version.php. Quid des MAJ SPIP si le fichier inc_version.php est mis à jour ?

J’ai aussi regardé du coté de Mutualisation : un SPIP pour plusieurs sites - SPIP qui parle de la fonction spip_initialisation mais je n’ai pas tout compris (notamment ce que vient faire _SPIP_PATH la dedant !)

Bref, une petite aide serait la bienvenue si vous avez déjà mutualisé des sites sous SPIP 4.2

Merci

#2

Le plus simple, c’est d’utiliser le pseudo plugin (il a un paquet.xml, mais il ne s’installe pas comme un plugin, mais dans un dossier à la racine : mutualisation ; et sa config se fait via config/mes_options.php) : Mutualisation facile - Plugins SPIP

Et j’ai de nombreuses mutualisations de SPIP installées avec.

PS : qui dit mutualisation dit impossibilité d’utiliser SVP pour mettre à jour les plugins.
⇒ moi, j’utilise la ligne de commande et Git pour installer et mettre à jour le code source des plugins.

#3

Salut @RealET
Je n’ai qu’une petite mutualisation et peu d’expérience en la matière car ses sites antédiluviens utilisent très peu de plugins, mais venant d’essayer je viens de voir que certaines choses sont tout de même possibles concernant la mise à jour des plugins avec la simple interface de base de SPIP (UI de SVP) :

  • Sur mon installation il y a un site « hôte » sur le domaine principal et les sites hébergés sont dans des sous domaines.
  • Ce que j’ai constaté c’est qu’en mettant à jour avec SVP via la page Plugins du site hôte ou d’un des sites hébergé, ça met correctement à jour le plugin pour tous les sites,
  • Et ce qu’il m’a semblé c’est que ce faisant ça désactive sur les autres sites où il était activé. Il faut donc restaurer l’activation sur les différents sites qui en font usage après. (Et du coup en faisant comme ça il serait pratique de voir, sur la page « Plugins » du site hôte, pour chaque plugin la liste des sous-sites qui l’utilise)

Est-ce que tu confirmes que c’est ça le contour de ce qui va et de ce qui ne va pas ?

#4

Oui, c’est ça qui ne va pas avec SVP et la mutualisation : comme SVP crée un dossier vx.y.z du plugin téléchargé, le chemin n’est plus valable dans les autres sites.
Et réactiver manuellement est juste ingérable.

Voir aussi : #4150 - SVP + SVP_PREFERER_TELECHARGEMENT_PAR_VCS : vraiment mettre à jour sans changer de doosier - svp - SPIP on GIT

#5

Ah. Du coup faudrait compléter le traitement pour actualiser les chemins des autres plugins…

Tandis qu’avec git, ça met à jour « sur place ». Et ya pas besoin quand même de repasser par la page des plugins pour réinitialiser le plugin (genre pour recharger les caches des chemins si ya eu des changements…) ?

#6

Ou modifier SVP pour qu’il ait un mode écrasement sans sous dossier vx.y.z ?

Moi, je fais tout en ligne de commande, avec des git pull / checkout pour changer de branche si nécessaire.
Et spip-cli avec la commande spipmu pour agir sur tous les sites (en particulier, la mise à jour de la base suite à màj d’un plugins).

#7

Après un update git, pas besoin de lancer les mises à jour dans chacun des sites hébergés et ça se fait tout seul par la suite au fil des appels des pages publiques ? Parce que parfois ya des changements de schéma de la bdd, des fonctions de maj requises…

#8

Alors, j’ai à la racine du spip mutualisé un fichier update.sh avec en substance :

checkout spip -b4.2 .
spipmu "*" "core:maj:bdd"

# adapté de https://stackoverflow.com/questions/3497123/run-git-pull-over-all-subdirectories
find ./plugins -type d -name ".git" -exec git --git-dir={} --work-tree=$PWD/{}/.. pull \;

spipmu "*" "plugins:maj:bdd"
spipmu "*" "cache:vider"

# Pour suivre si y'a des erreurs fatales suite à la mise à jour (attention à la majuscule à Fatal)
echo "Tail fatal"
tail -f /var/log/apache2/error.log | grep Fatal
1 « J'aime »
#9

Merci. C’est donc ce qu’il faudrait reproduire avec le non-plugin mutu.

#10

Franchement, je vois pas ce que ça apporterait.
La mutualisation sans accès à la ligne de commande, donc, sans spip-cli, c’est contre productif.
Et refaire dans le plugin mutualisation ce qui marche déjà en cli, pas grand intérêt.

Le seul truc qui serait positif, c’est une modification de SVP tenant compte des besoins de la mutualisation : garder le même chemin lors de la mise à jour d’un plugin.
Si tu as de l’énergie/temps à mettre quelque part, c’est ça qu’il faudrait viser.
Quitte à ce que ce soit un plugin à part nécessitant SVP et le surchargeant.

1 « J'aime »