Les rédacteurs précédents semblent vouloir dire, (semblent !) : laissez tomber vos préoccupations, occupez-vous de moi d'abord.
Non Ce n'est pas l'idée du tout. L'idée est qu'avant de lancer un CMS à l'international, autant qu'il soit fonctionnel de bout en bout. Et de nos jours, avec la virtualisation de serveurs, de postes de travail et autre, le mode multisite des CMS en général est un atout majeur à son déploiement.
Concernant Spip, oui il est mutualisable.
Cela se fait par le plugin "mutualisation facile" Plugin ICI et à l'aide de cette documentation
Ensuite il faut bidouiller le fichier "mes_options.php" et c'est parti.
Donc, dans les faits, c'est simple à mettre en œuvre.
Dans la pratique, ça marche oui, mais ça marchouille plus que ça ne fonctionne réellement.
Les données qui sont ""mutualisés"" sont les dossier "IMG", "config", "local" et "tmp".
Comme le souligne Gauthier, on fait face à des problèmes qui, pour ma part, sont un peu des problèmes sorti du fin fond de la pré-histoire.
Le "super-admin", chef de la plateforme entière ne peux pas rentrer dans le panel admin de chaque site Spip…
C'est la première chose qui m'a choqué.
En cas de soucis sur un site, on ne peut pas intervenir directement dans le panel admin, il faut bidouiller le mot de passe ou se créer un utilisateur à chaque fois…
Quand on a fini de digérer le coup du super-admin on se dit :
"Tiens je vais changer le thème et ajouter des plug-ins pour mon nouveau petit sous-site".
Que néni !
Là encore, l'écureuil frappe fort !
Suivant le plugin, cela fonctionne ou non. Car pour l'esprit Spip, c'est le plugin qui s'adapte à l'architecture et non l'inverse.
Suivant si l'on est en mode mutualisé ou non, le même plugin/le même code ne réagit pas pareil !
Pour contre exemple, sous Wordpress qui est un CMS lui aussi (avec WP Super cache pour le cache ;) ), le moteur s'adapte et crée un vrai environnement pour le plugin.
Sous Spip, on se retrouve, en fonction de quelles ressources à besoin le plugin, avec le plugin qui fonctionne ou non.
Après ce deuxième coup, on attaque la partie thème et là on se fait carrément dérober le sac de noisettes sous les yeux !
Toujours le cas du mutu/pas mutu, certains thèmes fonctionnent, d'autres non et d'autres en partie, suivant quelle page on affiche.
(cas classique : la page d'accueil bug, mais quand on va sur le '/ecrire/' il fonctionne).
En creusant un peu, on s'aperçoit qu'en modifiant le plugin mutualisation, en lui ajoutant la création d'un dossier "squelettes", certains thèmes daigne bien fonctionner.
Avec des CMS vraiment multi-site, ou les développeurs pensent multi-site, mange multi-site, vivent multi-site ont à droit à des architectures vraiment bien pensées.
PS : Pour pas se fâcher, je ne parlerai pas de la mise à jour qui doit s'appliquer sur chaque site via un bouton "update" alors que les autres mettent directement le moteur et ses dépendances à jour.
[^] # Re: Plus urgent que la traduction ?
Posté par jean-jacques (site web personnel) . En réponse à la dépêche Appel à traduction de SPIP. Évalué à 1.
Non Ce n'est pas l'idée du tout. L'idée est qu'avant de lancer un CMS à l'international, autant qu'il soit fonctionnel de bout en bout. Et de nos jours, avec la virtualisation de serveurs, de postes de travail et autre, le mode multisite des CMS en général est un atout majeur à son déploiement.
[^] # Re: Plus urgent que la traduction ?
Posté par jean-jacques (site web personnel) . En réponse à la dépêche Appel à traduction de SPIP. Évalué à 1.
Concernant Spip, oui il est mutualisable.
Cela se fait par le plugin "mutualisation facile"
Plugin ICI et à l'aide de cette documentation
Ensuite il faut bidouiller le fichier "mes_options.php" et c'est parti.
Donc, dans les faits, c'est simple à mettre en œuvre.
Dans la pratique, ça marche oui, mais ça marchouille plus que ça ne fonctionne réellement.
Les données qui sont ""mutualisés"" sont les dossier "IMG", "config", "local" et "tmp".
Comme le souligne Gauthier, on fait face à des problèmes qui, pour ma part, sont un peu des problèmes sorti du fin fond de la pré-histoire.
Le "super-admin", chef de la plateforme entière ne peux pas rentrer dans le panel admin de chaque site Spip…
C'est la première chose qui m'a choqué.
En cas de soucis sur un site, on ne peut pas intervenir directement dans le panel admin, il faut bidouiller le mot de passe ou se créer un utilisateur à chaque fois…
Quand on a fini de digérer le coup du super-admin on se dit :
"Tiens je vais changer le thème et ajouter des plug-ins pour mon nouveau petit sous-site".
Que néni !
Là encore, l'écureuil frappe fort !
Suivant le plugin, cela fonctionne ou non. Car pour l'esprit Spip, c'est le plugin qui s'adapte à l'architecture et non l'inverse.
Suivant si l'on est en mode mutualisé ou non, le même plugin/le même code ne réagit pas pareil !
Pour contre exemple, sous Wordpress qui est un CMS lui aussi (avec WP Super cache pour le cache ;) ), le moteur s'adapte et crée un vrai environnement pour le plugin.
Sous Spip, on se retrouve, en fonction de quelles ressources à besoin le plugin, avec le plugin qui fonctionne ou non.
Après ce deuxième coup, on attaque la partie thème et là on se fait carrément dérober le sac de noisettes sous les yeux !
En creusant un peu, on s'aperçoit qu'en modifiant le plugin mutualisation, en lui ajoutant la création d'un dossier "squelettes", certains thèmes daigne bien fonctionner.
Avec des CMS vraiment multi-site, ou les développeurs pensent multi-site, mange multi-site, vivent multi-site ont à droit à des architectures vraiment bien pensées.
PS : Pour pas se fâcher, je ne parlerai pas de la mise à jour qui doit s'appliquer sur chaque site via un bouton "update" alors que les autres mettent directement le moteur et ses dépendances à jour.