Ferme à SPIP

Un petit article synthétique qui explique en quelques mots et captures d’écrans comment faire une « ferme à SPIP » avec le plugin "Mutualisation" à partir d’un nom de domaine principal.

ATTENTION , cet article nécessite d’utiliser une version stable > à 2.0

Les prérequis (au 1er janvier 2008) :

-  posséder un nom de domaine disponible
-  avoir la possibilité de modifier la configuration apache

Dans l’exemple suivant on supposera que l’on cherche à mettre la ferme sur le site GrmlEU [1]

Installation SPIP

Installer un SPIP (une version récente est recommandée). Pour la suite de l’exercice on supposera que le SPIP est installé dans le répertoire « /home/grml/public_html/ ».

Installation plugin mutualisation

Installer le plugin Mutualisation [2] (il est plus simple de ne pas le mettre dans le répertoire plugin) . Nous avons donc « /home/grml/public_html/mutualisation »

Configuration apache

Modifier la configuration apache

Si vous êtes sur apache2 il faut créer un fichier grml.eu.

etc/apache2/sites-available# more grml.eu 
<VirtualHost *>
ServerName grml.eu
ServerAlias *.grml.eu
DocumentRoot /home/grml/public_html
</VirtualHost>

Ce qui veut dire que tous les sous domaines de grml.eu vont pointer vers le répertoire « /home/grml/public_html ».

Ensuite il faut faire une lien symbolique pour que le domaine soit actif

cd etc/apache2/sites-enable
ln -s /etc/apache2/sites-available/grml.eu  grml.eu 

Enfin il faut prendre en compte ces changements

/etc/init.d/apache2 force-reload 

Configuration DNS

Il faut maintenant que lorsque l’on tape grml.eu, il redirige vers l’adresse ip du serveur

voici la config utilisée chez gandi

Configuration de la mutualisation

Copier le fichier /home/grml/public_html/mutualisation/mes_options.php.txt vers « /home/grml/public_html/config » et enlevez l’extension « .txt » . Ouvrez ce fichier et procédez au paramétrage.

Pour vous aider voici le fichier de config utilisé sur scriibe

<?php

        $GLOBALS['taille_des_logs']=1000;
        #parametrage a faire 
        $monTld="scriibe.net";

        require _DIR_RACINE.'mutualisation/mutualiser.php';
        define ('_ID_WEBMESTRES', 1);

        $site = $_SERVER['HTTP_HOST'];

        $type_urls = 'propres2'; # par defaut, surchargeable ci-dessous

        switch($site) {
                case "www.$monTld":
                        $site=$monTld;
                        break;
                case 'www.spip-blog.net':
                        $site='spipblog';
                        break;
                case 'spip-blog.net':
                        $site='spipblog';
                        break;
                default :
                        $site = str_replace('.scriibe.net', '', $site);
                        break ; 
        }
        define ('_SITES_ADMIN_MUTUALISATION', ''); // ici sites esclaves
        define ('_INSTALL_SERVER_DB', 'mysql');
        define ('_INSTALL_HOST_DB', 'plouf');
        define ('_INSTALL_USER_DB_ROOT', 'plouf');
        define ('_INSTALL_PASS_DB_ROOT', 'plouf');
        define ('_INSTALL_TABLE_PREFIX', 'spip');
        define ('_INSTALL_NAME_DB', 'scr_'.prefixe_mutualisation($site));
        if ($site != "$monTld") {
                demarrer_site($site,
                        array(
                        'creer_site' => true,
                        'creer_base' => true,
                        'code' => 'plouf',
                        'url_img_courtes' => true,
                        'creer_user_base' => true,
                        'mail' => 'ben.spip@gmail.com'
                        )
                );
        }
        else {
        $GLOBALS['dossier_squelettes']=":mutualisation";
        }

?>

pour celui sur GrmlEU

<?php

        if (!defined("_ECRIRE_INC_VERSION")) return;
        require _DIR_RACINE.'mutualisation/mutualiser.php';

        $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
        if ($site != $_SERVER['HTTP_HOST']) {
                include_spip('inc/headers');
                redirige_par_entete('http://'.$site.'/');
        }

        define ('_INSTALL_SERVER_DB', 'mysql');
        define ('_INSTALL_HOST_DB', 'localhost');
        define ('_INSTALL_USER_DB', 'plouf');
        define ('_INSTALL_PASS_DB', 'plouf');
        define ('_INSTALL_NAME_DB', 'grml');
        #define ('_INSTALL_TABLE_PREFIX', 'spip');
 
        define ('_SITES_ADMIN_MUTUALISATION', 'grml.eu');


        demarrer_site($site,
                array(
                        'creer_site' => true,  
                        'creer_base' => false,
                        'creer_user_base' => false,
                        'mail' => 'ben.spip@gmail.com',               
                        'code' => 'ecureuil',
                        'table_prefix' => true,     
                        'cookie_prefix' => true,   
                        'repertoire' => 'sites',     
                        'url_img_courtes' => true, 
                        'url_creer_base' => '' 
                )
        );

?>

On peut noter que pour scriibe, une base et un utilisateur mysql sont créés pour chaque site. Par contre sur GrmlEU, il n’y a qu’un user et qu’une seule base, avec un préfixe différent pour les tables de chaque site.

Notes

[1GrmlEU est un site qui permet d’essayer SPIP : vous pouvez créer un SPIP en quelques clics. Les sites sont effacés tous les mois

Discussion

50 discussions

  • Bonjour,
    Je dois faire une mise à jour de ma ferme. Est-ce qu’il y a un qq part tuto sur la procédure à suivre ?
    Je m’interroge notamment dans le cas où la BDD doit être mise à jour, ça va bien se passer ?
    Merci pour vos éclairages.

    Répondre à ce message

  • 8

    Bonjour,
    J’ai mise en place une ferme SPIP 4.1.9 (PHP 7.4) d’une dizaine de sites.
    J’ai voulu faire une mise à jour complète et :
    1 - la mise à jour de SPIP via spip_loader ne fonctionne pas (page blanche). Quelle est la procédure recommandée ?
    2 - la mise à jour des plugins provoque leur inactivation sur les sites dépendants de la ferme (les anciennes versions des plugins n’étant pas conservées). Quelle est là aussi la meilleure procédure ?
    Merci pour vos conseils.

    • Bonjour,

      1. tu as quel version du loader ?
      2. oui il est recommander de travailler avec git pour géré une mutualisation car quand on met à jour les plugins cela changement le chemin si tu le fait avec SVP. Sinon il faut que chaque site est son répertoire de plugins

    • Bonjour Pierre,
      Pour spip_loader, j’utilise la version 6.1.2, et j’obtiens une erreur SHA512. Cela ne semble pas une erreur propre à la ferme, je m’en rends compte maintenant.
      Pour la mise à jour des plugins, j’ai contourné le problème en mettant en place un mini-plugin qui spécifie la nécessité d’activation de tous plugins. C’est un peu fastidieux, mais c’est pratique.
      Je ne sais pas ce que travailler avec GIT signifie, mais si ça peut aider, je suis preneur.
      Merci pour ton aide _||_

    • Faire de git clone et autre commande du coup ton chemin de plugins ne change pas
      Après tu as spip-cli qui avec des ligne de commande rajoute des plugins et les actives ou met à jour la bdd sans passer dans le BO mais je ne l’utilise pas.

    • Merci encore pour ton aide si rapide !
      Je ne connais pas du tout ces outils Git, et ne saurai pas pour l’instant procéder de cette manière. Mais j’ai partiellement résolu mes problèmes :
      1) je vais faire la mise à jour du SPIP centralisé de la ferme de manière manuelle.
      2) je vais créer un plugin pour chaque website qui liste tous les plugins et les qualifie comme nécessaires. Ainsi je mets à jour tous les plugins en 1 clic.
      Pour autant, ce qui aurait été sécurisant et pratique, c’est que le dossier Plugins de la ferme SPIP conserve les versions anciennes des plugins après mise à jour. SPIP est manifestement maintenant structuré pour rendre possible cette option, mais comment la rendre effective ?

    • A propos du problème SHA512 « spip_loader.php on line 18 », il semble que ce ne soit pas propre à la ferme mais général... Affaire à suivre.

    • @Pierre Kuhn : Cette histoire de git m’interesse...
      Quelle sont les commande git pour mettre à jour un plugin ? Pour changer de version (rétrograder comme mettre à jour la dernière version) ? Y a-t-il un petit memento quelque part à ce sujet ?
      Merci d’avance

    • J’utilise https://git.spip.net/spip-contrib-outils/checkout
      Je pense pas que tu puisse retrograder, je vois pas le besoin non plus d’ailleurs.
      Si tu git pull un dossier pour le mettre à jour cela met à jour le plugins sur la dernière version, attention au branche pour ne pas se perdre ou casser le site

    • Pour solution,
      j’ai opté pour la création d’un petit plugin « Activation Automatique » (un simple paquet.xml) dédié à chaque site, qui liste les plugins nécessaires à l’utilisation du site.
      Quand je fais une mise à jour, je n’ai qu’à le réactiver AA pour que tous les plugins soient eux-mêmes réactivés.

    Répondre à ce message

  • 6

    Bonjour,
    Je suis intéressée pour monter une ferme à SPIP.
    Quelques questions avant de me lancer :
    -  le plugin « Mutualisation » est-il toujours maintenu ? Il semble que oui, mais je préfère m’en assurer.
    -  combien de sites maximum dans une « ferme à SPIP » ?
    -  est-il possible d’avoir une peu d’aide quand les choses sérieuses commenceront ?
    -  les plugins sont-ils installés de façon individuelle pour chaque site ?
    Merci d’avance de toute réponse ou échange me permettant de mieux comprendre le fonctionnement d’une « ferme à SPIP ». (Je connais le multisite WordPress, mais il y a certainement des différences que j’essaie de cerner.)
    Merci encore et bonne journée à chacun.

    • Bonsoir,

      Si tu veux géré des sites en mutualisation, il faut maitriser SPIP en git pour faciliter les mises à jour ensuite.
      Les plugins sont commun à tous les sites, comme le core de SPIP.
      Tu n’as pas de nombre de site maxi, cela va dépendre des sites, du serveur ...
      Il faut prévoir une base par site et pas une base pour tous les sites.

      Le problème de la mutu c’est en cas de faille exploité, tous les sites seront impacté.

      Mais on peut en parler plus si tu as vraiment ce besoin.

      Cordialement
      Pierre

    • Bonjour,

      Le plugin mutualisation est maintenu par ceux qui l’utilisent (j’en fais partie).

      J’aurais tendance à dire que pour l’utiliser, il faut que tu sois en mesure de le maintenir toi aussi.

    • Euh, je comprends pas trop pour quelle raison il faudrait être en mesure de maintenir un plugin pour l’utiliser.
      Cet outil est formidable, grand merci à tous ceux-celles qui le maintiennent, (et plus généralement, grand merci à l’ensemble de la communauté des développeurs dont le travail et l’esprit de partage permet aux utilisateurs de base de disposer de merveilleux outils).
      Mais, assurément, ouf, il n’est pas nécessaire d’être codeur pour se servir de SPIP.
      Aussi je trouve qu’écrire : “J’aurais tendance à dire que pour l’utiliser, il faut que tu sois en mesure de le maintenir toi aussi" ne reflète pas la réalité (= on peut se servir d’un plugin sans devoir être capable de le maintenir) et n’est pas très encourageant (voire culpabilisant), ce qui est dommage.
      SPIP est un outil génial, invitons les débutants à affronter patiemment la courbe d’apprentissage qui peut paraître assez pentue pour le(a) débutant(e).
      Enfin, c’est comme ça que je vois les choses...

    • Alors, je vais préciser :

      • le fonctionnement du « plugin » de mutualisation facile implique de bien comprendre ce qu’il fait, et ce qu’il implique
      • d’ailleurs, ça n’est pas un plugin, mais un ensemble de scripts qui facilitent la mutualisation, en utilisant un mécanisme se trouvant en fait au cœur de SPIP
      • utiliser la mutualisation, c’est grosso-modo renoncer à SVP
      • donc installer les plugins avec Git (ou FTP, mais là, franchement, c’est long)
      • donc savoir choisir la branche de ce qui a été récupéré par Git
      • et installer manuellement les lib/ parce que Git ne les installe pas (contrairement à SVP)

      Bref, y’a du pour, y’a du contre, mais ça aide de comprendre les rouages de l’intérieur.

    • Bonjour à tous et merci pour vos réponses rapides.

      Si tu veux géré des sites en mutualisation, il faut maitriser SPIP en git pour faciliter les mises à jour ensuite.

      Ce n’est pas encore le cas, mais j’aime bien apprendre. Donc si je sais que je peux avoir des coups de pouce dans la mise en place, c’est faisable ;)

      Mais on peut en parler plus si tu as vraiment ce besoin.

      Je vais l’avoir très bientôt. Donc il faut que je teste dès maintenant (enfin plutôt cet été) et oui je veux bien avoir des interlocuteurs pour les détails au fur et à mesure de mes essais.

      J’aurais tendance à dire que pour l’utiliser, il faut que tu sois en mesure de le maintenir toi aussi.

      Jamais fait, mais prête à me lancer :) avec votre aide !

      Toutes vos remarques et indications ne me font pas peur, mais nécessitent que je passe au niveau supérieur sur SPIP. Pas de souci si je sais que je peux avoir des réponses de quelques uns.

      Je vais donc installer une ferme à SPIP test prochainement et cela me permettra d’avancer tranquillement.

      Encore merci de vos réponses. Je reviens vers vous prochainement.
      Bonne journée.

    • Mes premiers pas :

      • installer SPIP : OK
      • copier le dossier mutualisation : OK
      • modifier et mettre dans config/ le fichier mes_options.php : OK mais pas sûre d’avoir tout fait correctement
      • installer un premier site : OK
      • afficher https://mon-site/spip/ecrire/?exec=mutualisation : « Fichier mutualisation introuvable. » mais n’ayant pas fait l’étape ci-dessous, c’est probablement normal
      • configurer apache et DNS : à faire (mais pas sûre d’avoir les droits suffisants, peut-être à demander à la DSI de mon service)

    Répondre à ce message

  • Bonjour et merci pour ce plugin !

    J’ai un petit souci avec le compresseur CSS :
    La fonction compresseur_ecrire_balise_css_dist du plugin compresseur passe en entête de la page un prefetch pour le fichier CSS compressé. C’est une bonne pratique.
    Mais avec le plugin de Mutualisation et l’option ’url_img_courtes’ le prefetch ne se fait pas sur l’URL du fichier classique (http://exemple.com/local/cache-css/aaaaa.css) mais directement vers le fichier dans l’arborescence de la mutualisation (http://exemple.com/sites/monsite.com/local/cache-css/aaaaa.css).

    Le fichier CSS est donc chargé deux fois :

    1. sur http://exemple.com/sites/monsite.com/local/cache-css/aaaaa.css via le prefetch
    2. sur http://exemple.com/local/cache-css/aaaaa.css via l’inclusion dans le head
      Et c’est pas l’idéal pour les performances :(

    Voici un exemple en situation réelle :
    Si on regarde l’entête HTTP de réponse de la page via curl -sSL -D - legras-industries.com -o /dev/null on voir que le prefetch est fait sur la mauvaise URL (Link: <https://legras-industries.com/sites/legras-industries.com/local/cache-css/5efddd078ece692a340105a6e4adc57a.css?1548639575>;rel="stylesheet prefetch")

    J’ai vraiment du mal à voir à quel moment ça cloche.

    Répondre à ce message

  • 1

    Bonjour,
    Il y a a priori une erreur dans la version 1.4.4, ligne 17 et 19 de mutualiser_creer.php : il manque les quotes autour du nom de la constante _SPIP_LOGO_MUTU. Cela entraîne un warning avec la version 7.2 de PHP (et ce sera une erreur fatale avec la 7.3)
    Voici ci-dessous le code corrigé :

    if (find_in_path('images/logo-spip.png')) {
    	define( '_SPIP_LOGO_MUTU',find_in_path('images/logo-spip.png'));
    } else {
    	define( '_SPIP_LOGO_MUTU',find_in_path('images/logo-spip.gif'));
    }

    Cordialement,
    Bruno

    Répondre à ce message

  • 2

    Bonjour à tous,
    J’ai plusieurs sites installés en mutualisation et pour la première fois, je dois en rajouter un nécessitant son propre fichier mes_options.php (à ne pas confondre avec le fichier mes_options.php de la mutu elle-même).
    Mais où placer ce fichier mes_options.php dans le cas d’une mutualisation ?
    Lorsque je le place dans le sous-dossier /config propre à ce site, il ne semble pas pris en compte ?
    Merci.
    PS : j’ai posé la même question sur la liste spip@rezo.net

    • Bonjour,

      Tu as trouvé la solution ?

    • Bonjour,

      Comme évoqué, mettre le fichier dans le sous dossier config propre au site concerné.
      Exemple (avec « sites » comme dossier des différents sites) :
      /sites/mon_site_mutualise/config/mes_options.php

      Normalement, cela fonctionne.

    Répondre à ce message

  • 5

    Bonjour,
    J’utilise spip 3.2.1 avec mutualisation et via le site privé, mes logos d’article sont téléchargés sur ecrire/IMG/LOGOS et sont donc identiques sur tous les sites.
    Puis-je modifier les paramètres de config pour que les logos soient téléchargés sur un sous-dossier de sites/mysite .com pour avoir des logos d’articles différents pour chaque site ?

    • Bonjour,

      On peut voir ton fichier mes_options avec la config de la mutu ?

    • Voila, j’ai supprimé les commentaires et infos privés :

      <?php
      	if (!defined("_ECRIRE_INC_VERSION")) return;
      	if (!is_readable (_DIR_RACINE.'mutualisation/mutualiser.php')) {
      		echo _L("Fichier 'mutualisation/mutualiser.php' manquant dans la racine " . _DIR_RACINE);
      		exit;
      	}
      	require _DIR_RACINE.'mutualisation/mutualiser.php';
      
      	$site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
      	if ($site != $_SERVER['HTTP_HOST'] AND !in_array($site, $www)) {
      		include_spip('inc/headers');
      		$req = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '/';
      		if (isset($_SERVER['HTTPS'])
      		AND test_valeur_serveur($_SERVER['HTTPS']))
      			$protocole = 'https';
      		elseif (!isset($_SERVER["SCRIPT_URI"]) OR !($p = strpos($_SERVER["SCRIPT_URI"], '://')))
      			$protocole = 'http';
      		else $protocole = substr($_SERVER["SCRIPT_URI"],0,$p);
      		redirige_par_entete($protocole . '://' . $site . $req);
      	}
      
      	if (strpos($site, ':')) {
      		if (preg_match('/:80$/', $site)) $site = substr($site,-3);
      		else $site = str_replace(':', '_', $site);
      	}
      
      	define ('_INSTALL_SITE_PREF', $site);
      	define ('_INSTALL_NAME_DB', 'mytable');
      
      	define ('_INSTALL_SERVER_DB', 'mysql');
      	define ('_INSTALL_HOST_DB', 'localhost');
      	define ('_INSTALL_USER_DB', 'root');  
      	define ('_INSTALL_PASS_DB', ''); 
      
      	define ('_INSTALL_TABLE_PREFIX', myprefix);
      	$cookie_prefix = strtok($site, '.'); 
      
      	demarrer_site($site,
      		array(
      			'creer_site' => true,
      			'creer_base' => false,
      			'creer_user_base' => true,
      			'mail' => 'myemail@test.org',
      			'code' => '********',
      			'table_prefix' => false,
      			'cookie_prefix' => false,
      			'repertoire' => 'sites',
      			'url_img_courtes' => false,
      			'url_creer_base' => '',
      			'avant_initialisation' => ''
      		)
      	);
      ?>
    • Je vois pas pourquoi cela va dans ecrire/IMG ...
      Pas logique.

      Les docs dans la médiathèque sont identique partout du coup ?
      Ensuite je vois une base pour tous les sites .... pas top si tu as de gros site je pense.

    • J’ai en fait 3 sites distincts mais disons frères jumeaux, ils utilisent la même base de données, et les tables supplémentaires sont identiques pour les 3 sites.
      Les photos des utilisateurs sont enregistré pour les trois sites dans IMG/LOGOS et IMG/INTRO, donc communs aux 3 sites.
      Le problème est juste que pour les logos des articles qui devraient être distincts et non communs.

    • Je sais pas si cela est possible par contre ...

    Répondre à ce message

  • 7

    Bonjour,

    Il m’arrive de surcharger la présentation de certains plugins dans l’espace privé dans par exemple : sites/monsite.com/squelettes/prive/formulaire/...

    Mais en mutualisé cela ne fonctionne plus. Une idée comment corriger ce souci ?

    En attendant, j’ai mis mes fichiers personnalisés à la racine de spip dans le dossier squelettes. Ce qui n’est pas très pratique car je ne peux choisir sur quel sites doit s’appliquer le/les fichiers modifier.

    • Bonsoir

      Est sans le dossier prive ?

      PS : Pourquoi surcharger les configuration de plugins ?

    • Non j’ai déjà essayé. Cela ne fonctionne pas.

      Pour certains plugins je change un peu la présentation html dans l’espace privé.

    • Dans ce cas pourquoi ne pas faire amélioré les plugins ?

    • Parce que ce n’est pas vraiment une amélioration. Voici l’issue d’un plugin que je souhaiterais surcharger :

      https://contrib.spip.net/Identite-Extra#forum487993

    • en effet, j’ai jamais fais ça en mutu.

    • Flute. Pas de solution alors ?

    • Salut,

      Tu peux surcharger le prive dans le dossier squelettes de ton site hein^

      Il est également possible de ne pas mutualiser les plugins... (c’est bien mieux amha en production)

      # desactiver le dossier plugins classique
      define('_DIR_PLUGINS','');
      # Definir un dossier plugins pour chaque site
      define('_DIR_PLUGINS_SUPPL',_DIR_RACINE.'sites/'.$site.'/plugins/'); 
      # Definir un dossier plugin/auto pour chaque site
      define('_DIR_PLUGINS_AUTO',_DIR_RACINE.'sites/'.$site.'/plugins/auto/'); 

      Les plugins-dist et le core de spip restent mutualisés mais chaque site a ses plugins persos

    Répondre à ce message

  • Bonjour,

    Nous mettons à disposition des établissements de notre académie une ferme de SPIP environ 110 hébergements actuellement. Nous utilisons pour cela le plugin mutualisation facile version 1.3.5 stable installé via la gestion des plugins. Nous souhaitons mettre à jour les plugins de l’ensemble des sites via la fonction l’admin de mutualisation « ecrire/ ?exec=mutualisation »

    Le script Upgrader intégrés à la mutualisation et servant à automatiser les mises à jour (extensions et noyau) semble ne pas fonctionner.

    L’option « Upgrader tout » n’a aucune action, le mode débogueur du navigateur nous apporte pas plus d’informations.

    Cependant, d’autres fonctionnalités sont opérationnelles (calcul des volumétries : documents, cache,...).

    Merci par avance de toute aide qui me sera apportée !

    Le plugin couteau suisse Version locale : 1.9.12 Révision : 101356 est aussi installé, nous avons activé L’Ecran de sécurité et mises à jour automatiques. L’écran de sécurité s’installe et se met à jour sans problème ainsi que les mises à jour automatiques.
    Serveur Debian 7.11 wheezy
    Server version : Apache/2.2.22 (Debian)
    php5 vers : 5.4.45-0+deb7u7
    SPIP 3.1.3 [23214]

    Répondre à ce message

  • 1

    J’aime beaucoup l’idée mais en terme de sécurité, cela ne craint pas trop d’avoir tout ses sites sur un seul noyau SPIP ? Si un compte utilisateur ftp est compromis, cela met tout les autres domaines en danger non ?

    • Cela dépend comme tu donnes tes accès ftp.
      Il vaut mieux garder le ftp pour l’admin général et donner des ftp restreint ensuite.

    Répondre à ce message

  • 8

    Bonjour,

    J’ai testé cette procédure en local et tout fonctionne parfaitement. J’ai juste un soucis dans l’espace privé ou tout les styles ont sautés (affichage brute) sur l’ensemble des sites mutualisés. En revanche, coté publique cela fonctionne nickel.

    Est-ce que quelqu’un a déjà eu ce problème ? Une constante dans mes_options.php a définir ?

    J’ai vidé le dossier tmp, vider le cache, supprimer mes plugins, restauré la base de donnée mais rien n’y fait.

    J’utilise php 5.6.30 avec Spip 3.1.3

    Merci pour votre aide.

    • J’ai un peu avancé dans mon problème.

      C’est au moment de la création du dossier « plugins » que le problème arrive.

    • En faite, je crois que j’ai pas bien compris comment définir de nouveaux squelettes dans mes sites mutualisés (différent par site).

      Chacun de mes sites on des dossiers squelettes différents. J’ai donc mis pour chacun, un fichier mes_options.php dans leur dossier config avec des appellations de squelettes différents.

      $GLOBALS['dossier_squelettes'] = _DIR_SITE . 'squelettes' . _DIR_SITE . 'squelettes-01' . _DIR_SITE . 'squelettes-02';

      Mais il semblerait que cela soit faux... :(

    • Bonjour,

      Tu veux faire un squelettes par site ?

      Normalement /sites/site1.example.com/squelettes fonctionne.

    • Ben j’aimerais faire quelque chose du style :

      /site1/config/mes_options.php
      (squelettes, squelettes-abc, squelettes-def)

      /site2/config/mes_options.php
      (squelettes, squelettes-ghi, squelettes-jkl)

      /site3/config/mes_options.php
      (squelettes, squelettes-mno, squelettes-pqr)

      Mon code plus haut fonctionne mais il fait planté mon espace privé.

    • Et sans les _DIR_SITE ?

      L’idée est de proposer plusieurs squelettes par site ?

    • Cela ne marche pas non plus en enlevant les « _DIR_SITE ».

    • Si on se réfère à : http://www.spip.net/fr_article1825.html

      La syntaxe est

      <?php
          $GLOBALS['dossier_squelettes'] = 'mes_skel1:mes_skel2';
      ?>

      Donc la syntaxe serais plutôt :

      $GLOBALS['dossier_squelettes'] = _DIR_SITE.'squelette1:'._DIR_SITE.'squelette2';

      @chez moi ça marche,

      cela dit je ne vois pas trop l’intérêt ou le but, moi je m’en sert plutot pour faire de A/B test et passer rapidement d’un skel à un autre avec une ligne par skel et en commentant/dé-commentant.

      Bonne journée

    Répondre à ce message

  • Bonjour,

    J’ai pu configurer sans problème un SPIP 3.1 mutualisé avec 4 sous-domaines. Très intéressant cette méthode. Cependant, j’aurais deux questions :

    1. Est-ce que je peux avoir en commun un dossier « squelettes-all » pour tout mes sous-domaine et partager les mêmes ressources (css, js, img, formulaires, modèles, etc...) ?

    2. Dans ma configuration j’ai ces 4 sites ci-dessous :

    site1.example.com
    site2.exemple.com
    site3.exemple.com
    site4.exemple.com

    Mais quand au site principale : www.exemple.com, est-ce que je peux acquérir les informations de chaque sous-domaines ? Ou chacune des ces ressources sont distinctes.

    Merci, Julien.

    Répondre à ce message

  • Bonjour,
    Je viens de tester sous Spip 3.1 et la dernière version du plugin.
    Quand je crée un nouveau site, tout est parfaitement géré, sauf qu’à la fin il m’envoie vers http://www.example.com/ecrire/ecrire/?exec=install, donc un ecrire/ de trop dans l’url ...

    Répondre à ce message

  • 7

    Ce plugin est-il compatible avec la nouvelle version 3.1 ?

    • Bonsoir,

      Pas encore tester mais tu peux et nous dire si tu as des problèmes.

    • Merci, mais très honnêtement, j’ai plus de vingt sites mutualisés, je ne vois pas commenter tester avec un seul et voir si ça marche ou pas ! je préfère d’autres retours d’expériences que mon crash éventuel... :- !

    • Je te conseil de monter une mutu en 3.1 et modifier tes vhost pour tester.
      perso je passe pas encore en 3.1 car j’ai des plugins non compatible.

    • Ça tombe bien, moi aussi ;-) J’attendrai donc !

    • Bonjour,

      J’ai testé en local ce plugin avec SPIP 3.1 et j’ai des problèmes pour créer de nouveaux sites. A noter que tout fonctionnait parfaitement en 3.0 . Avec les sites déjà installés tout semble OK.

      Les fichiers connect.php et chmod.php ne sont pas créés dans config.

      Tout semble se passer bien jusqu’à la phase d’installation de SPIP c’est à dire :
      -  Activation avec un code OK
      -  Création du répertoire dans sites/ OK
      -  Création des répertoires config, IMG, local et tmp OK
      -  Création de la base de donnée (vide !) OK

      On arrive alors à l’écran indiquant : La base de donnée mu_mondomaine a été créée. Vous pouvez poursuivre l’installation de SPIP.

      On démarre la phase Installation du Système de publication... puis suivant... puis on reste bloqué sur Installation du système de publication à l’étape 1. Dans les logs de SPIP, on a : Pub : !INFO : spip_connect : fichier de connexion ’’ non trouve .

      A suivre !

    • Pour ma part, je suis passé en 3.1 dès juillet 2015. En mutu. Et j’ai créé plusieurs sites sans problème.

      Voici mon config/mes_options.php :

      require _DIR_RACINE.'mutualisation/mutualiser.php';
      
      $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
      $site = str_replace('ww2.', '', $site);
      $site = str_replace('ww3.', '', $site);
      
      define ('_INSTALL_SERVER_DB', 'mysql');
      define ('_INSTALL_HOST_DB', 'localhost');
      define ('_INSTALL_HOST_DB_LOCALNAME', 'localhost');
      define ('_INSTALL_USER_DB_ROOT', 'root');
      define ('_INSTALL_PASS_DB_ROOT', 'mot2passeroot');
      define ('_INSTALL_NAME_DB', 'mutu_'.prefixe_mutualisation($site));
      define ('_INSTALL_USER_DB', prefixe_mutualisation($site));
      define ('_INSTALL_TABLE_PREFIX', 'spip');
      
      demarrer_site($site,
      	array(
      		'creer_site' => true, 
      		'cookie_prefix' => false, 
      		'table_prefix' => false,
      		'creer_base' => true,
      		'creer_user_base' => true,
      		'code' => 'ecureuil',
      		'mail' => 'mutualisation@domaine.tld',
      		'annonce' => '<h3>SPIP 3.1</h3>',
      		)
      	);
      // Pour bloquer l'installation automatique des plugins
      define('_DIR_PLUGINS_AUTO', '');
      // Pas de log pour gagner en écritures
      #$GLOBALS['nombre_de_logs'] = 0;
      #$GLOBALS['taille_des_logs'] = 0;
      
      # Dans le cadre d'une mutualisation, l'affichage d'une nouvelle version de SPIP est inutile
      function genie_mise_a_jour($t) {
      	effacer_meta('info_maj_spip');
      	return 1;
      }
    • J’ai finalement entièrement réinstallé SPIP sans rien changé à mon fichier mes_options.php et ça marche !

      Désolé pour le bruit !

    Répondre à ce message

  • 2

    Bonjour,
    J’essaie d’installer la mutualisation sur Gandi Simple Hosting.
    J’avais réussi sur Gandi Serveurs, mais là je sèche.
    J’ai suivi la méthode indiquée ici : http://www.spip-contrib.net/La-mutualisation-facile-modifications-manuelles, avec le plugin Mutualisation, et le fichier mes_options.php dans /config/ + .htacess à la racine.
    J’ai mis les fichiers spip 2.1 dans un répertoire de vhosts, sans site spip installé.

    Seulement, quand je lance l’install pour un 1er site mutualisé (depuis un nom.domaine.tld dirigé vers le vhost où se trouve Spip, j’ai les formulaires d’installation de Spip standards (pas de mutualisation, pas de code d’activation ecureuil demandé).
    Que faire ?

    Peut-être qu’il faut avoir obligatoirement déjà installé un site spip standard avant d’en installer des mutualisés ?

    Merci pour toute piste utile.

    Voici mon mes_options.php (on dirait qu’il n’est pas pris en compte du tout ?) :

    <?php
    
    	/*
    	 * Inscrire ici le nom du site d'administration du tableau de bord
    	 * de la mutualisation (ou plusieurs, separes par des virgules)
    	 * (dans cet exemple, 'scriibe.net' est le top level domain, TLD)
    	 * pour autoriser tous les sites, ne pas definir la constante ;
    	 * Si le site maitre n'est pas dans sites/ mais a la racine, mettre ''
    	 * et ajouter 'mutualisation' dans $dossier_squelettes
    	 */
    	define ('_SITES_ADMIN_MUTUALISATION', 'nom.domaine.tld');
    
    	if (!defined("_ECRIRE_INC_VERSION")) return;
    	if (!is_readable (_DIR_RACINE.'mutualisation/mutualiser.php')) {
    		echo _L("Fichier 'mutualisation/mutualiser.php' manquant dans la racine " . _DIR_RACINE);
    		exit;
    	}
    	require _DIR_RACINE.'mutualisation/mutualiser.php';
    
    	/* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */ 
    	$www = array();
    	
    	$site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
    	if ($site != $_SERVER['HTTP_HOST'] AND !in_array($site, $www)) {
    		include_spip('inc/headers');
    		$req = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '/';
    		if (isset($_SERVER['HTTPS']) 
    		AND test_valeur_serveur($_SERVER['HTTPS']))
    			$protocole = 'https';
    		elseif (!isset($_SERVER["SCRIPT_URI"]) OR !($p = strpos($_SERVER["SCRIPT_URI"], '://')))
    			$protocole = 'http';
    		else $protocole = substr($_SERVER["SCRIPT_URI"],0,$p);
    		redirige_par_entete($protocole . '://' . $site . $req);
    	}
    
    	// Compatibilite avec le ":" de $dossier_squelettes
    	// Si l'url indique explicitement un port (grace a ":")
    	// tout eliminer s'il s'agit du port 80
    	// et remplacer ":" par _ pour les autres ports
    
    	if (strpos($site, ':')) {
    		if (preg_match('/:80$/', $site)) $site = substr($site,-3);
    		else $site = str_replace(':', '_', $site);
    	}
    
    	define ('_INSTALL_SITE_PREF', prefixe_mutualisation($site));
    	define ('_INSTALL_NAME_DB', 'mu_'. _INSTALL_SITE_PREF);
    
    	define ('_INSTALL_SERVER_DB', 'mysql'); 
    	define ('_INSTALL_HOST_DB', 'localhost'); 
    	define ('_INSTALL_USER_DB_ROOT', 'root');  
    	define ('_INSTALL_PASS_DB_ROOT', 'mon-mot-de-pass-root');
    	
    	/* mettre en commentaire la ligne suivante si vous utilisez l'option table_prefixe plus bas dans la config */ 
    	define ('_INSTALL_TABLE_PREFIX', 'spip');
    
    	/* 
    	 * Si le nom du serveur est different du nom dns, 
    	 * ca peut parfois poser probleme
    	 * il faut alors le definir ici
    	 */
    	# define ('_INSTALL_HOST_DB_LOCALNAME', 'nom_serveur');
    	
    	/* 
    	 * Si le serveur n'est pas mysql, il faut le preciser obligatoirement.
    	 * # define ('_INSTALL_SERVER_DB', 'pg'); // mysql|pg|sqlite2|sqlite3
    	 * 
    	 * /!\ En PG, il est conseille d'utiliser la creation d'utilisateur SQL
    	 */
    	
    	/*
    	 * Creer automatiquement les users SQL (pg|mysql)
    	 * 
    	 * Cela permet 
    	 * - d'avoir un utilisateur root possedant les droits 
    	 * de creation de bases (cet utilisateur possedant obligatoirement 
    	 * une base a son nom en PG - PG ne se connecte pas sans donner un nom de bdd)
    	 * - de creer des utilisateurs sql automatiquement 
    	 * ne possedant que les droits d'administation 
    	 * de leur base de donnee qui sera creee
    	 * 
    	 * Il faut remplacer alors 
    	 * _INSTALL_(USER|PASS)_DB par _INSTALL_(USER|PASS)_DB_ROOT
    	 * 
    	 * et ajouter dans demarrer_site l'option
    	 * 'creer_user_base' => true
    	 */ 
    	# define ('_INSTALL_USER_DB_ROOT', 'mon_root');
    	# define ('_INSTALL_PASS_DB_ROOT', '********');
     
    	/*
    	 * Creer les bases de donnees via un ping sur une URL (methode AlternC)
    	 *
    	 * Il suffit de renseigner l'option url_creer_base, en lui passant les bons parametres :
    	 * 'url_creer_base' => 'https://bureau.tld/admin/sql_doadd.php?username=USER&password=PASS&dbn='.prefixe_mutualisation($site)
    	 */
    	 
    	 
    	/*
    	 * Transformer sur les pages publiques les url des images
    	 * /sites/mon_site/IMG/* -> /IMG/*
    	 * /sites/mon_site/local/* -> /local/*
    	 * 
    	 * - Necessite le mod_rewrite (reecriture d'url) d'apache
    	 * - Ne fonctionne qu'avec des mutualisations de nom de domaine 
    	 * ('http_host' : http://mon_site_mutu.tld)
    	 * (donc pas avec une mutualisation de repertoire - http://site/mon_spip_mutu/)
    	 * 
    	 * et ajouter dans demarrer_site l'option
    	 * 'url_img_courtes' => true
    	 * 
    	 * Il est possible de regenerer les fichiers .htaccess 
    	 * crees automatiquement dans /IMG et /local
    	 * grace a ?var_mode=creer_htaccess_img
    	 * 
    	 */
    	
    	demarrer_site($site,
    		array(
    			'creer_site' => true,        // Creer ou non le site s'il n'existe pas (defaut: false) 
    			'creer_base' => true,        // Creer ou non la base de donnee si elle n'existe pas (false) 
    			'creer_user_base' => true,  // Creer ou non un utilisateur pour la nouvelle base de donnee (false)
    			'mail' => '',                // Adresse mail pour recevoir un mail lors d'une creation de site mutualise ('') 
    			'code' => 'activation',        // Code d'activation ('actvation') pour tentative VHOST spip
    			'table_prefix' => false,     // Definir automatiquement le prefixe de table (false) ... mettre true si tous les sites dans la meme base 
    			'cookie_prefix' => true,     // Definir automatiquement le prefixe de cookie (false)
    			'repertoire' => 'sites',     // Nom du repertoire contenant les sites mutualises ('sites')
    			'url_img_courtes' => true,   // Utiliser la redirection des URL d'images courtes dans la partie publique (false)
    										 // /!\ il faut qu'apache ait le droit d'ecrire dans les dossiers IMG/ et local/ a la racine du site !
    										 // C'est la que la mutualisation va ecrire les regles de redirection automatiques pour les images de chaque site
    			# 'utiliser_panel' => false, // Utiliser une table externe pour recuperer des identifiants ... (code, user, pass) permettant a un utilisateur d'installer le site (false) 
    			# 'annonce' => '<p>Un service propos&eacute; par <a href="http://www.spip.net/">la communaut&eacute; SPIP</a></p>', // Texte a afficher en bas du formulaire d'activation de la mutualisation
    			'url_creer_base' => ''       // Creer la base de donnees via une URL (methode AlternC)
    		)
    	);
    
    ?>
    • Bon, finalement, ça a marché !, avec ce même fichier mes_options.php
      en repartant à zéro sur un autre espace vhost, pourtant les réglages sont les mêmes
      Pas compris pourquoi avant ça ne marchait pas, bizarre...

      Conclusion, la mutualisation spip (2.1 en l’occurence) peut fonctionner sur Gandi Simple Hosting, si ça peut servir à d’autres...

    • Bonjour,
      Malgré les indications précédentes, je n’arrive pas à installer une mutualisation spip 3 sur Gandi Simple Hosting... Est-il possible de contourner le réglage des fichiers VirtualHost ? (etc/apache2/sites-available/ n’est pas accessible). Je serais curieux de savoir ce que DM a ajouté dans son .htaccess.
      Merci d’avance pour votre aide,
      Sébastien

    Répondre à ce message

  • 9

    Bonjour,
    je rencontre un problème avec les sites de ma ferme. Les images des squelettes des sites ne s’affichent pas avec la nomenclature classique : « squelettes/img/image.jpg ».
    Je suis obligé d’utiliser celle-ci : « sites/nomdusite/squelettes/img/image.jpg ».
    Ce qui est très embêtant lorsque je dois mettre un site en production sur un serveur client. Comment faire pour changer ce fonctionnement ?

    Merci par avance.

    • Bonjour, vous pouvez donnez le fichier mes_options ?

    • Bonsoir Pierre,
      le fichier mes_option.php à la racine dans le dossier config contient ce code :

      <?php
      define ('_SITES_ADMIN_MUTUALISATION', '');
      
      if (!defined("_ECRIRE_INC_VERSION")) return;
      if (!is_readable (_DIR_RACINE.'mutualisation/mutualiser.php')) {
      echo _L("Fichier 'mutualisation/mutualiser.php' manquant dans la racine " . _DIR_RACINE);
      exit;
      }
      require _DIR_RACINE.'mutualisation/mutualiser.php';
      
      $www = array();
      	
      $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
      if ($site != $_SERVER['HTTP_HOST'] AND !in_array($site, $www)) {
      include_spip('inc/headers');
      $req = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '/';
      if (isset($_SERVER['HTTPS']) 
      AND test_valeur_serveur($_SERVER['HTTPS']))
      $protocole = 'https';
      elseif (!isset($_SERVER["SCRIPT_URI"]) OR !($p = strpos($_SERVER["SCRIPT_URI"], '://')))
      $protocole = 'http';
      else $protocole = substr($_SERVER["SCRIPT_URI"],0,$p);
      redirige_par_entete($protocole . '://' . $site . $req);
      }
      
      if (strpos($site, ':')) {
      if (preg_match('/:80$/', $site)) $site = substr($site,-3);
      else $site = str_replace(':', '_', $site);
      }
      
      define ('_INSTALL_PREFIX_DB','mu_');
      define ('_INSTALL_SITE_PREF', prefixe_mutualisation($site));
      define ('_INSTALL_NAME_DB', _INSTALL_PREFIX_DB. _INSTALL_SITE_PREF);
      
      define ('_INSTALL_SERVER_DB', 'mysql'); 
      define ('_INSTALL_HOST_DB', 'localhost'); 
      define ('_INSTALL_USER_DB', 'root');  
      define ('_INSTALL_PASS_DB', 'root'); 
      	
      define ('_INSTALL_TABLE_PREFIX', 'spip');
      	
      demarrer_site($site,
      array(
      'creer_site' => true,  
      'creer_base' => true,       
      'creer_user_base' => false, 
      'mail' => '',  
      'code' => 'ecureuil',
      'table_prefix' => false,
      'cookie_prefix' => true,  
      'repertoire' => 'sites',  
      'url_img_courtes' => true, 
      'url_creer_base' => '' 
      )
      );
      ?>

      Je pensais que ça pouvait venir d’une mauvaise configuration de Mamp mais sur serveur OVH il y a le même problème. Le problème concerne uniquement les images référencées dans les squelettes, les images du back-office s’affichent normalement.

      Merci par avance.
      Mathieu.

    • Comment tu appels les images sur le site ?

    • Classique : <img src="squelettes/img/image.jpg" alt="" />

    • Euh utilise #CHEMIN alors

    • Malheureusement ça ne donne rien.

    • Tu fait comment exactement ?
      </code

    • <img src="#CHEMIN{img/image.jpg}" alt="" />

    • Yes merci ça marche, je faisais <img src="#CHEMIN{squelettes/img/image.jpg}" alt="" />

      Merci encore.

    Répondre à ce message

  • 2

    Bonjour, J’ai 16 sites SPIP mutualisés en 3.0.16. Jusque là je n’ai eu aucun problème non résolu mais là... Le code d’activation ne fonctionne plus pour le 17e site ! Le pire c’est que je l’ai noté quelque part et donc c’est ce code que je rentre mais j’ai toujours « Erreur » qui s’affiche. Mystère très ennuyeux...
    Où puis-je trouver le code ? J’ai fait une première recherche dans chmod.php sans succès.
    Merci d’avance.
    Philippe G.

    • Honte sur moi, le code est dans mes_options.php (en plus c’est moi qui l’ai mis). Par contre il ne marche plus ! !! :-(

    • Bonjour,
      Je vois un caractère  sur la capture, c’est pas logique déjà.

    Répondre à ce message

  • 18

    Bonjour,

    J’ai un soucis avec les plugins sur un spip3 mutualisé.
    Dès que je mets à jour un plugin sur le noyau mutualisé et que je repasse sur chacun des sites, le plugin mis à jour ne se réactive pas... je suis obligé de les réactiver un par un manuellement.
    Dans spip2 ca fonctionnais correctement, un plugin mis a jour dans la mutualisation était automatiquement mis à jour et activé dans les sites mutualisés.

    Help, c’est hyper pénible !

    • Bonjour

      Tu as une dépendance par hasard qui s’active en même temps ?
      Comment mets tu à jour ?

    • Je mets a jour les plugins dans la mutualisation / gestion des plugins quand elle est signalée.
      Mes plugins sont dans plugins/auto/
      Pas de problèmes de dépendances, même une mise à jour mineure (3.1.1 à 3.1.12 par exemple) n’est pas réactivée automatiquement. J’ai testé sur tous les plugins de ma mutualisation (50 au moins), ca ne marche jamais (CFG, Couteau suisse, Court cirtuit, barre typo, etc...) je dois réactiver 1 par 1.

    • Je réactive le sujet car il semble que ce soit un souci récurrent cette histoire de désagréments constatés mise à jour de plugin dans le cadre d’une mutualisation...
      Quelqu’un pourrait-il faire un point là-dessus et donner la bonne méthode pour effectuer les mises à jour sans que « ça casse » ?

    • pierrot

      Je constate le même problème et pour l’instant j’envisage de basculer sur un dossier plugins par site au lieu d’un dossier plugins central pour éviter ce problème.
      Mais je rencontre un problème avec le plugin Saisies (enfin pas forcément avec ce plugin mais c’est ce plugin qui semble le révéler), je le décrit ici :

      http://contrib.spip.net/Saisies?debut_comments-list=-1#forum470211

      P.

    • Même problème (spip 3.0.14) chez moi.
      Seul le site d’où la mise à jour du plugin se fait reste activé. Le plugin se désactive sur les autres sites, et du coup peut générer des erreurs sur le site public, etc.
      Parfois (dans le cas je crois des mises à jour Saisies et/ou Couteau Suisse), j’ai été obligé de vider le cache pour me sortir des pages publiques blanches qui ont suivies ce genre d’erreurs.
      (le problème est le même qu’une mise à jour soit lancée depuis la page plugin de l’admin ou depuis la page « mise à jour auto » du Couteau Suisse)

      Donc, peut-être que je vais devoir faire comme Pierrot, un dossier plugin par site, au moins pour les sites les plus importants. Mais c’est ennuyeux car on perd un des intérêts de la mutualisation du noyau...

    • Non ! Il faut garder la mutualisation car sinon, effectivement on perd l’intérêt du truc.
      Le souci rencontré est dû au fonctionnement de SVP qui « nomme » les dossiers.Lors d’une mise à jour, le nom du dossier change, et du coup, paf, les plugins des autres sites se désactivent. Normal.
      La solution consiste à faire les mises à jour sans passer par SVP.
      Soit tu mets à jour par SVN
      Soit tu fais la mise à jour par FTP : le nom du dossier ne changeant pas (seuls les fichiers contenus sont modifiés) et rien ne se désactivera.

    • Pour ma part j’ai essayé ceci :

      http://contrib.spip.net/Et-si-on-automatisait-tout-ca

      Vers le bas, Gestion des plugins et suggestions de modifs du plugin SVP pour que la mise à jour de plugins conserve les versions précédentes et ainsi ne désactive rien dans les autres sites de la ferme. Il faut ensuite bien sûr passer sur chaque site pour activer les nouveaux plugins si on souhaite les mettre à jour.

    • Ok Manu, merci pour le truc.
      Par ftp, je sais faire, ce n’est pas très pratique, mais c’est mieux que de devoir réactiver les plugins sur chaque site.
      Par SVN, je ne sais pas bien faire. Il faut un accès ssh pour le faire direct sur l’espace d’hébergement des sites c’est ça ? Pas sûr que ça marche sur mon hébergeur Gandi Simple Hosting...

      J’imagine que je peux gérer un dossier des plugins sur mon disque dur mis à jour par SVN ?, et envoyer ça par FTP ensuite (en gardant les mêmes noms des dossiers des plugins)
      Dans ce cas, il vaut mieux sortir les plugins du site du dossier « auto » non ?

      Pour les solutions de Pierrot, ça parait trop compliqué pour mo !, ça a l’air intéressant, mais j’attendrai une version ad hoc du plugin Mutualisation. En tout cas, merci, là je comprends mieux pourquoi ça plante actuellement.
      D’autant que je n’ai pas de sites Maître/esclaves, ils sont tous au même niveau a priori.

      -  Idée : Pour l’avenir, un truc qui serait top, c’est que la page admin (plugins actifs ou inactifs) des plugins dans Spip puisse afficher la liste des sites web qui utilisent chaque plugin, pour mieux s’y retrouver.

    • Si on ne peut pas utiliser SVP pour faire la mise a jour (c’est presque aussi dommage de pas pouvoir mutualiser ses mises a jour ;-), il faut peut-etre revenir au systeme précédent :
      avant, en SPIP2 (et meme au debut de SPIP 3 par habitude), j’utilisais une lame du couteau suisse pour identifier et lancer les mises a jour..... http://contrib.spip.net/Mise-a-jour-automatique-des-plugins

      Mais, ne l’ayant pas appliqué sur des mutualisations, je n’ai pas vérifié le fonctionnement en détail sur le point évoqué.... l’un d’entre vous peut-il essayer ? et transmettre son résultat...

      Cdlt
      @+

    • DavidM : - Idée : Pour l’avenir, un truc qui serait top, c’est que la page admin (plugins actifs ou inactifs) des plugins dans Spip puisse afficher la liste des sites web qui utilisent chaque plugin, pour mieux s’y retrouver.
      => tu as cela sur la page exec=mutualisation, disponible dans le site maitre uniquement.

    • @YannX, j’ai testé la mise à jour auto par la lame Couteau Suisse, pour le plugin Saisies ça a désactivé pareillement les plugins sur les autres sites.
      Donc a priori ça ne marche pas mieux que SVP de spip 3...

    • @ Pierre, je croyais qu’il n’y avait plus de site Maître dans cette configuration ? C’est le site où est installé les fichiers spip communs ? Je ne l’ai pas créé celui-ci (j’utilise 7 sites mutualisés, dont 4 en production).

    • Euh perso j’en indique 1 dans le fichier de configuration du plugins afin de limiter qui utilise cette page.

    • Pardon, je n’avais pas regardé ça attentivement. Du coup, j’avais mal compris et mis un site non actif (celui avec Spip) dans le code         define ('_SITES_ADMIN_MUTUALISATION', 'monsite.tld'); de mes_options.php

      Là j’ai mis un site actif à la place, et j’ai effectivement une liste utile avec ecrire/ ?exec=mutualisation, merci !

    • J’ai testé pour un plugin le fait de l’avoir dans un dossier « plugins » pour un seul site mutualisé :

      Il faut mettre un code dans le fichier mes_options.php du site concerné :
      // code pour que le dossier plugins/auto du site concerné soit prix en compte en plus du dossier plugins/auto de l’install spip mutualisée qui est à la racine :

      define('_DIR_PLUGINS_SUPPL',_DIR_RACINE.'sites/monsite.tld/plugins/');

      En mettant ce code (remplacer monsite.tld par le bon nom de site), le plugin test apparaît bien sur le site concerné (il faut juste le réactiver après son déplacement d’un dossier à l’autre), et la mise à jour ensuite est ok.

      Comme ça je peux mettre à jour les plugins de chaque site séparément, en évitant les plantages dues aux mises à jour qui ne sont pas suivies par les autres sites (problème SVP indiqué ci-dessus).
      Accessoirement, ça permet de tester une màj plugin sur un seul site.

    • Pierrot

      Bonjour,

      J’ai évoqué cette solution mais elle me pose (en tous cas me posait) des pbms évoqués ici :

      http://contrib.spip.net/Saisies?debut_comments-list=-1#forum470211

      Certains plugins semblent buguer sur cette solution, peut-être n’utilisez-vous pas ces plugins ou peut être qu’un bug a été corrigé. Pour ma part j’ai fini par peu à peu abandonner ces mutualisations qui me posaient plus de soucis que de gains, chaque mise à jour était un sac de noeuds, la modif de SVP était à surveiller ... bref j’ai re-séparé mes installations et c’est beaucoup plus zen (j’avais 3 fermes avec environ 25 sites).

    • Après quelques essais supplémentaires, je me suis rendu compte que le système décrit ci-dessus n’est pas terrible. En fait, si on met les plugins de chaque site dans « auto », avec une mise à jour du plugin la nouvelle version du plugin se remet dans le dossier plugins du spip mutualisé, c’est retour à la case départ.

      Finalement, j’ai laissé tel quel (les plugins mutualisés pour tous les sites), c’est encore le moins compliqué, et je met à jour les plugins un par un depuis un site, avec ensuite réactivation du plugin sur chacun des autres sites.
      En attendant une solution intégrée, je ferai donc les mises à jour moins souvent.

    • @ Pierrot : Récemment (sur spip 3.0.14), je n’ai pas eu de problème avec la mise à jour de Saisies. Faut juste le réactiver sur tous les sites.... comme pour les autres plugins. Perso j’ai 7-8 sites, donc 5 seulement sont publics, donc c’est gérable.

      Sinon, comme disait je crois Pierrot sur un autre fil, peut-être que pour la méthode que j’ai testée (http://contrib.spip.net/Ferme-a-SPIP#forum475819, ci-dessus) marche pour les mises à jour, il faudrait supprimer le dossier plugins du site mutualisé ? (pour éviter que Spip ne remette les plugins dedans lors d’une mise jour de plugin)
      Mais je ne testerai pas, pas le temps. Je préfère rester comme ça et attendre une vraie solution qui permette de vraiment mutualiser les plugins efficacement en plus de spip.

    Répondre à ce message

  • 1

    Bonjour,

    J’ai passé la matinée pour réussir à monter une ferme, je pense avoir à peu près tout compris, même si certaines zones restent un peu obscures pour moi.

    Je pense que la partie configuration du fichier mes_options mériterait quelques informations supplémentaires car il y a plusieurs façons de travailler (il suffit de voir les deux exemples qui sont différents)
    Particulièrement le paramétrage de la variable de SITE_ADMIN ... parfois blanc, parfois pas ... comment cela marche exactement m’échappe.

    Ce que je sais uniquement c’est qu’en le remplissant et en essayant de configurer un site qui n’était pas le même que la dedans, ça plantait ...

    Bon mes questions sont les suivantes :

    La doc du wiki indique que le site « principal » n’est pas accessible. Moi je me suis inspiré du fichier de scriibe.net et l’ai configuré pour créer mon premier site. La procédure a été jusqu’au bout.
    Initialement j’ai créé le spip à l’adresse « fermeaspip.e-delmotte.com », installation sans soucis, j’ai ajouté tout un jeu de plugins à l’intérieur, les ai activé, puis suis passé à la suite ...

    Question 1 :
    -  si je tape aujourd’hui « fermeaspip.e-delmotte.com » j’arrive sur une page avec erreur de squelettes, à priori autour de z ... pourquoi mon domaine est joignable ? Je pensais arriver sur un dashboard particulier.
    Si tel n’est pas le cas, à quoi sert cette adresse ? Comment accede t on a « l’administration de la mutualisation » comme on en parle dans le wiki ?

    Question 2 :
    -  quand j’ai installé le second site, il avait tous les plugins ... mais inactifs, c’est le comportement attendu ? On active les plugins qui nous intéresse en fonction des sites ?

    Question 3 :
    -  on peut installer des plugins depuis n’importe quel site et ils sont mis à disposition de tout le monde ?

    Merci d’avance

    Répondre à ce message

  • Bonjour,

    Depuis la mise en place du pluggin (spip 3) je n’arrive plus à lire mes fichiers pdf (plugin pdf.js) -> spip.php ?page=pdfjs&id_document=x..
    Dans le fichier sip.log j’ai le message d’erreur ci dessous :
    :Pri:ERREUR : fonction execute_pipeline_renseigner_document absente : pipeline desactive

    Auriez vous déjà rencontré ce genre de problème ?

    Cordialement,
    Arielle.

    Répondre à ce message

  • Hello,

    J’ai rédigé un petit billet concernant l’installation de spip mutualisé en spip 3 sur un mutualisé OVH avec serveur sql dédié : http://www.soon7.com/developpements/mutualisation-du-noyau-spip-3-sur-un-mutualise-de-chez-ovh/

    Répondre à ce message

  • 2

    Bonjour,

    Je veux installer plusieurs sites en mutualisation, dont un déjà existant ailleurs.
    Le site existant, domaine1.org, doit être refondu avant.

    Je voudrais créer un site en mutualisation, temp.domaine1.org, qui serait une version de développement de domaine1.org.
    Puis, une fois les nouveaux développements terminés, remplacer temp.domaine1.org par domaine1.org.
    Est-ce possible avec l’install de mutualisation ?
    Là j’ai essayé, sur Gandi Simple Hosting, de faire un lien symbolique d’un site nouveau vers un site déjà installé en mutu, mais l’installation se déclenche come si c’était un nouveau site.
    Si je fais une redirection « redirect permanent » avec un htaccess, c’est toujours l’url du site visé qui s’affiche.

    Est-ce donc possible de faire pointer domaine1.org vers le temp.domaine1.org, pour utiliser l’install de temp.domaine1.org, en ayant l’url de domaine1.org d’affichée ?
    Ou est-on obligé d’installer un nouveau spip mutu avec domaine1.org (avec la base développée dans temp.domaine1.org), en ayant un temps de coupure le temps de l’installation spip + plugins + paramétrages divers ?

    Je sais pas si ma question est claire ? (j’ai l’habitude des installs spip, j’ai déjà réalisé une mutualisation spip sur Gandi AI et GAndi Simple hosting, mais je ne connais pas les serveurs, Apache, etc.)

    Autre question : quelqu’un a déjà fait de la mutualisation spip sur Ouvaton ? Ca parait pas gèrable par l’utilisateur, car là on a juste des espaces web « séparés » sur son espace, et pas de moyens apparemment de faire un lien symbolique entre deux espaces... A moins qu’il y ait d’autres moyens ?

    Merci pour toute aide utile
    DM

    • Bonjour

      Tu as renommer le dossier dans /site ?

    • Eh oui, bien vu !, il suffit de renommer le dossier du site dans /sites/
      Je n’avais pas osé le faire en me disant que forcément ça allait perturber tout.

      Là on a la bonne url et on récupère le site déjà développé du coup ! Il suffit de changer aussi l’url dans configuration/identité du site

      Merci, ça va me simplifier bien le travail !

    Répondre à ce message

  • 3

    Bonjour
    impossible de faire fonctionner les thèmes et le Zen-Garden avec la mutualisation.
    J’ai essayé de placer le dossier « thèmes » soit à la racine de spip, soit à la racine de chaque site, rien à faire.
    Dans les deux cas, le Zen-Garden « voit » bien les thèmes et les propose dans l’espace privé, mais n’arrive pas à les activer, ni en visualisation, ni en choix....
    Une solution ?
    merci

    • Bonsoir

      Version de spip ? parce que en 2.1 ça fonctionne et en 3 aussi chez moi.

    • Merci de la réponse rapide (malheureusement elle ne me rassure pas ;)
      je suis en SPIP 3.0.2 de hier soir, le plugin mutualisation 59992 commit du 02/04/12
      Je ne vois pas trop quoi réinstaller....
      quelle est la config qui marche chez toi ?
      dans mes plugins j’ai
      saisies
      yaml
      zen-garden
      (peut-être fautil bonux mais je crois que en SPIP 3 ca ne sert à rien ?)

    • je me réponds en remerciant encore pierre.
      il faut le plugin
      Zpip-dist v1 1.7.19

      Mais comme Zen-Garden ne le met pas en « required » et que je pensais que Spip 3 était « natif Zpip », et bien cela ne marchait pas...

      Mes excuses
      MJ

    Répondre à ce message

  • Lupitek

    J’ai une ferme a spip avec 20 sites dessus et je viens de me rendre compte qu’en faisant www.monsite1.com/sites/ j’obtient le listing de tous mes sites dans la mutualisation.

    Je n’ai pas vu dans la procédure d’installation qu’il fallait protéger le dossier /sites/ avec un .htaccess... ou alors j’ai raté un truc.

    Répondre à ce message

  • 3
    ERNCHEMILLOIS

    Bonjour,
    avec une seule base est il possible de jouer uniquement sur les préfixes des tables en réutilisant le nom du site, sans recréer une base de donnée indépendante ?

    Merci !

    • Affirmatif :
      -  le répertoire config est propre a chaque site !
      -  son fichier « connect.php » permet de choisir le $prefix

    • ERNCHEMILLOIS

      Merci pour la rapidité de la réponse, je m’attèle à la tâche de suite ,
      Et merci aux développeurs du plugin !

    • IL faut juste que tu régles bien le fichier de config pour que les sites s’installe correctement.
      Ne fais pas ça avec de gros site sinon j’ai peur que la base déconne.

    Répondre à ce message

  • Bonjour,

    Est-ce que ce plugin peut-être utilisé avec des sites en sous-répertoire au lieu de sous-domaine ? Je voudrais que mes adresses soient comme ça : www.mondomaine.com/site1, www.mondomaine.com/site2, etc.

    merci !

    Répondre à ce message

  • 1
    Tipoussin

    Bonjour,

    Je sèche sur l’utilisation de ce plugin. Lorsque je tape mondomaine.tld, j’arrive sur une page « Installation de votre site SPIP » où on me demande un code d’activation du site...

    Qu’est-ce que c’est ?

    Merci

    Répondre à ce message

  • 4
    Apprenti geek

    Bonjour, j’ai installé le plugin mutualisation et tout marche impeccable.

    Seulement voilà, je ne sais pas comment faire un lien du dossier IMG d’un nouveau site mutualisé vers le dossier IMG du site existant avant la mutualisation...

    Dans le carnet Wiki sur la mutualisation, un auteur a écrit :
    “Ces répertoires peuvent être des liens symboliques vers les originaux du site à la racine, mais dans ce cas, le fichier mes_options.php devrait être déplacé dans /ecrire”

    J’ai bien mis mon fichier mes_options.php dans /ecrire/ mais je ne sais pas comment mettre en place ces liens symboliques.

    Quelqu’un aurait-il une idée ?

    Merci d’avance et comme d’hab, bravo pour le travail collaboratif de toute cette communauté !

    • Bonjour

      Pourquoi ne pas déplacer le fichier IMG vers la mutualisation ?

    • Apprenti Geek

      Bonjour,

      Tu as raison, mais étant que deux sites utiliseront la même base de données et donc les mêmes ressources à savoir le répertoire IMG, j’aurai aimé automatiser un peu le truc...

      Deux solutions s’offrent à moi :
      -  soit je mets en place une synchronisation automatique des deux sous répetoires IMG (aucune idée comment procéder mais cette solution supposerait de dupliquer automatiquement tout fichier dans le dossier IMG du site 1 vers le dossier IMG du site 2 ;
      -  soit je permets au site 2 d’aller chercher son dossier IMG non pas dans son sous répertoire, mais dans le sous répertoire du site 1 ;

      J’espère que je suis suffisamment clair... tu penses pouvoir m’aider ?

      Merci d’avance en tout cas pour ta réponse

    • Alors à ta réponse voici une question : 2 sites OK

      Pourquoi la même base et les même images, autant faire un site non ?

    • Apprenti Geek

      non parce que le site 1 n’a pas le même design et ne propose pas les mêmes fonctionnalités que le site 2 ... donc des templates différents mais un contenu de base similaire pour certaines rubriques...

    Répondre à ce message

  • 5

    Bonjour,

    Je pense créer un site internet et un blog. Idéalement le site sera multilingue et le blog dans une seule langue.

    Mon but est d’avoir une adresse internet www.adresseweb.com et un sous-domaine interne pour mon blog : blog.adresseweb.com

    Est ce que ce plugin est adapté à mon objectif ?
    Si non, y a t il une autre solution ?

    Merci

    • Bonsoir
      L’intéré de ce plugins est de mutualiser un spip et ses plugins donc si tu as 2 sites et 2 squelettes cela ne vos pas le coup a mon avis.

      Peux tu nous en dire plus sur ton projet ?

    • Comme indiqué dans mon précédent message, je souhaite réaliser un site sur une adresse et un blog sur un domaine interne (par exemple http://blog.adresseweb.com.
      L’une des solution que je vois, est de créer des compositions différentes (une pour le site + une autre pour le blog) avec plusieurs rubriques dont l’une blog. Sur mon FTP, dans mon répertoire /blog, je pourrais placer un fichier de redirection php vers l’url générée par spip pour la rubrique blog.

      Néanmoins, tout ça me semble de la bricole. D’où mes recherches s’il n’y aurait pas une meilleure solution plus « propre ».

    • Pierre KUHN

      Dans ce cas autant monter 2 sites a moins que tes plugins soit commun car si je comprend bien tu utiliserais Composition ?

    • Oui, j’utiliserais Compositions et d’autres plugins certainement en commun.
      Néanmoins, le désavantage de 2 sites est d’avoir 2 espaces privés. Mon but est d’en avoir idéalement un seul. D’ou mas recherche sur la mutualisation.

    • Pierre KUHN

      Euh alors tu as pas compris ce qu’est la mutualisation. La mutu te permets d’avoir x sites sur 1 SPIP et donc x espaces privés.

      Si tu veux 1 espace privé, il te faut dans ce cas jouer avec le plugins multidomaine http://www.spip-contrib.net/Plugin-Multidomaines

    Répondre à ce message

  • 1

    La personnalisation de la variable $dossier_squelettes> via $GLOBALS['dossier_squelettes'] = 'mon_dossier' dans mes_options.php ne fonctionne pas chez moi dans le cadre d’une ferme à spip. C’est normal ça ?

    • Je me réponds à moi-même...
      En fait il faut indiquer le chemin complet du répertoire que l’on souhaite prendre en compte

      Par ex : pour le site1 :

      dans
      www/sites/monsite1/config/mes_options.php

      il faut indiquer
      $GLOBALS['dossier_squelettes'] ='sites/monsite1/skel';
      et le rép. skel est bien pris en compte.

      Quand on y réfléchit, c’est assez logique, mais c’est tout de même perturbant au premier abord puisqu’on a envie d’écrire
      $GLOBALS['dossier_squelettes'] ='skel';

      et dans ce cas, SPIP s’attend à trouver un dossier ’skel’ à la racine.. de la mutualisation ! Et non pas à la racine « du site1 »

      Logique, mais pas tout à fait « portable » : si on sort le site de la mutualisation (ex : sur mon site de développement en local, c’est en mutu <==> sur le site en production, ce n’est plus le cas), le contenu de mes_options.php n’est pas strictement le même

      N’y aurait-il pas moyen d’homogénéiser les deux écritures ?

      Allez, bonne année à notre écureuil et un énoooorme merci à ses développeurs !

    Répondre à ce message

  • 4
    Marc VALLETEAU de MOULLIAC

    Bonjour, je trouve ce plugin vraiment formidable, car je suis en train de mettre en place sur mon serveur dédié (Apache 2) un hébergement de sites accessibles par nom de domaine et non en sous-domaine.

    J’ai alors modifié les lignes du haut pour les remplacer par ceci :

    $site = $_SERVER['HTTP_HOST'];
       if ($site != $_SERVER['HTTP_HOST']) {
          include_spip('inc/headers');
          redirige_par_entete('http://'.$site.'/');
    }

    En effet, en laissant le code d’origine, impossible d’accéder à mon site « maître » (http://www.atoutsweb.org)

    Ai-je bien fait ? La mise en place d’un autre site a été un peu cahotique, - en utilisant un autre domaine pointant sur le « maître », il m’a mis directement dans la fenêtre de création d’un répertoire, et non sur la demande du code (ecureuil) - mais ça a bien fonctionné en fin de compte.

    Par contre, j’ai un souci plus embêtant : sur la partie publique, il n’arrive pas à afficher les images du dossier IMG ou local/cache-vignettes car le chemin est incomplet (alors que tout s’affiche bien en privé).

    La modification ci-dessus en est-elle la cause ? Sinon, comment faire pour corriger cela ?

    Merci d’avance

    Marc

    • Delorimier

      Idem - j’ai le même problème avec les images dans la partie publique

    • Bonjour

      Est ce que l’on peux avoir l’adresse du soucis et le code du mes_options ?

    • VALLETEAU de MOULLIAC

      Bien, d’une part, je suis content d’avoir enfin (!) une réaction au sujet de mon post ...

      Par ailleurs, le problème a été résolu en complétant la config sur mon serveur (Mac os X) : j’ai autorisé toutes les dérogations, ce qui fait que depuis, cela fonctionne. Donc, le code du fichier mes_options.php n’est pas en cause ...

      Ce qui me soucie le plus, depuis cette solution, c’est la gesiton des plugins (en 2.0.10), car la plugin sensé permettre d’ajouter/enlever des plugins directement dans chaque site mutualisé est absolument inefficace. Il apparaît bien, en effet, la possibilité d’ajouter des plugins, mais ensuite, impossible de les activer !!

      Je suis donc obligé de les mettre dans le site maître, ce qui ne m’arrange pas toujours ...

      Merci à quiconque pourra m’aider à trouver une solution ...

    • Bonsoir

      ton message est dater de 2009 ... alors que j’en ai répondu en 2010 quand meme

      Est ce que tu peux nous en dire plus ?

      -  Tu es parti de quel exemple ?
      -  droit sur les dossiers ?
      ...

      Pour infos, sur ma mutu j’ai domaines et sous domaine et j’ai pas de soucis, les webmaster ont tous les droits

    Répondre à ce message

  • J’aimerai bien installer le plugin mutualisation chez free-h.org au travers d’une interface Plesk
    certain d’entre vous ont-ils réalisé cette installation

    merci

    Répondre à ce message

  • 1

    Salut et merci pour ce super plugin qui facilite vraiment les choses.

    Une précision pour les futurs utilisateurs, fruit d’une petite heure de prise de tête :

    il est préférable de s’arranger pour que le nom du répertoire de chaque site (donc dans l’exemple de cet article dans le répertoire ’sites/’) ne comporte pas de point !

    Je sais, c’est bateau mais si l’expérience peut servir ... j’aurai moins l’impression d’avoir perdu une heure pour une erreur d’inattention ;-)

    Explication rapide du problème rencontré :
    Si le répertoire d’un site est nommé du type ’sites/mondom.fr/’, certaines actions et notamment les téléchargements et accès aux documents sont impossibles (cas sur un serveur mutualisé OVH avec chmod limité à 755) ...
    Préférez donc des noms de répertoires du type ’mondom_fr/’ ou ’mondomfr/’

    Tchuss

    • Bonsoir

      Cela est possible chez OVH mais je n’ai pas ce soucis avec mon hébergeur même avec des sous.domaine.fr par exemple.

    Répondre à ce message

  • Bonjour,

    Petit truc de Matthieu Marcillaud passé sur l’IRC.

    Dans le cas d’une installation d’un mutualisation sur un site déjà existant, afin de conserver le site maitre accessible, rajouter autour des lignes 8/10 de mes_options.php :

    $mutualisation = ($_SERVER['HTTP_HOST'] == 'ledomaine.tld') ? false : true ;
    	if ($mutualisation) {
    	define ('_SITES_ADMIN_MUTUALISATION', 'ledomaine.tld');
    /* ici, tout le reste de votre mes_options.php concernant la mutualisation, et mettre le } pour finir le  if */
    }

    Une grand merci à Matthieu et à la communauté SPIP.

    Répondre à ce message

  • François Daniel Giezendanner

    Recherche spécialiste SPIP pour enseigner la maîtrise de la création de Fermes à SPIP : Etat de l’art

    Pour dispenser cette formation à une équipe du SEM nous cherchons un spécialiste SPIP ayant la maîtrise et l’expérience de la mise en place de Fermes à SPIP avec les technologies les plus performantes.

    Les personnes intéressées sont priées de s’adresser à :

    François Daniel Giezendanner : francois-daniel.giezendanner at edu.ge.ch

    en indiquant des exemples de réalisations de fermes à SPIP.

    Information complémentaire : http://icp.ge.ch/sem/cms-spip/spip.php?article1039

    Répondre à ce message

  • 7

    Bonjour,

    Je voudrais signaler un truc qui me semble important, dans le cadre d’une installation mutualisée par sous-domaines ou le serveur Apache n’est pas le serveur MySQL, et ou on souhaite utiliser le même utilisateur MySQL sur les bases des sites mutualisés (plutôt que de créer un utilisateur par base à chaque création de nouveau site). Cet utilisateur étant préexistant.

    L’installation plantait systématiquement après la création de la base, au moment de créer les tables, en déclarant que la connexion à la base était impossible. On se retrouvait avec un utilisateur MySQL déclaré comme opérant depuis le serveur MySQL (user@serveur_mysql), alors qu’il aurait du l’être depuis le serveur Apache (user@serveur_apache). Dans mon cas c’était user@IP_du_serveur_apache vu que l’utilisateur est unique pour tous les noms de domaines (même ceux qui n’existent pas encore).

    En clair : la connexion avec root fonctionne bien, elle crée la base, crée un utilisateur (alors qu’elle devrait juste ajouter des droits à l’utilisateur existant) et dès que ce nouvel utilisateur est utilisé -> connexion impossible.

    Finalement, en commentant la ligne 157 du fichier mutualiser_creer.php « define (’_INSTALL_HOST_DB_LOCALNAME’, _INSTALL_HOST_DB) » et en initialisant _INSTALL_HOST_DB_LOCALNAME avec l’IP du serveur Apache tout rentre dans l’ordre.

    Je sais pas si c’est très clair :) mais il me semble qu’au lieu d’affecter directement la valeur la ligne 157 devrait le faire uniquement dans le cas ou _INSTALL_HOST_DB_LOCALNAME n’est pas défini.

    Evidemment ça fonctionne bien tel quel sur les environnements de développement (testé sur WAMP et MAMP) puisque tous les serveurs sont sur la même machine (localhost).

    • @philip : tu n’as pas besoin de commenter la ligne en question pour ajouter ton propre

      define (’_INSTALL_HOST_DB_LOCALNAME’, '...');

      un peu en amont dans le fichier qui définit tes paramètres de mutualisation.

    • J’ai fait ce dont tu me parles dès le début.

      La solution a consisté à commenter la ligne 157 du fichier mutualisation/mutualiser_creer.php « define (’_INSTALL_HOST_DB_LOCALNAME’, _INSTALL_HOST_DB) » et en initialisant _INSTALL_HOST_DB_LOCALNAME avec l’IP du serveur Apache dans le fichier /config/mes_options.php.

      J’ai perdu plusieurs heures là-dessus, ce n’est pas une situation simple, merci de bien lire mon message :) ...

      Voici le contenu du fichier mes_options.php :

      $TLD=« domaine.ext » ;

      $site = str_replace(’www.’, ’’, $_SERVER[’HTTP_HOST’]) ;
      if ($site != $_SERVER[’HTTP_HOST’])
      include_spip(’inc/headers’) ;
      redirige_par_entete(’http://’.$site.’/’) ;
      else $site = str_replace(’.’ . $TLD, ’’, $site) ;

      define (’_INSTALL_HOST_DB’, ’nom_serveur_mysql’) ;
      define (’_INSTALL_HOST_DB_LOCALNAME’, ’IP_serveur_apache’) ;
      define (’_INSTALL_USER_DB_ROOT’, ’root’) ;
      define (’_INSTALL_PASS_DB_ROOT’, ’root_passwd’) ;
      define (’_SITES_ADMIN_MUTUALISATION’, ’’) ;
      define (’_INSTALL_SERVER_DB’, ’mysql’) ;
      define (’_INSTALL_TABLE_PREFIX’, ’spip’) ;
      define (’_INSTALL_NAME_DB’, ’toto_’ . prefixe_mutualisation($site)) ;
      define (’_INSTALL_USER_DB’, ’tata’) ;
      define (’_INSTALL_PASS_DB’, ’tutu’) ;
      define(’_PRIVILEGES_MYSQL_USER_BASE’,’Alter, Select, Insert, Update, Delete, Create, Drop’) ;

      demarrer_site($site,
      array(
      ’creer_site’ => true,
      ’creer_base’ => true,
      ’code’ => ’tagada’,
      ’url_img_courtes’ => true,
      ’creer_user_base’ => true,
      ’table_prefix’ => false,
      ’cookie_prefix’ => true,
      ’repertoire’ => ’sites’,
      ’mail’ => ’admin@spip.u-bordeaux4.fr’
      )
      ) ;

      Si je ne commente pas cette ligne, je me retrouve avec un utilisateur_mysql@serveur_mysql qui ne risque pas d’ouvrir de connexion, au lieu de l’utilisateur_mysql@serveur_apache attendu.

    • Il y a un truc qui m’échappe. Le défine que tu commentes est conditionné par le fait de créer un utilisateur pour la nouvelle base, or tu dis :

      on souhaite utiliser le même utilisateur MySQL sur les bases des sites mutualisés (plutôt que de créer un utilisateur par base à chaque création de nouveau site). Cet utilisateur étant préexistant.

      J’en conclus qu’il devrait y avoir ’creer_user_base’ => false, et non true ?

      Il est possible qu’il y ait un bug avec cette configuration que tu décris cependant, mais on devrait s’en sortir à coup de define(). Si c’est pas le cas, il faut corriger… mais commenter le code n’est peut être pas la meilleure correction :)

    • Oui, mais d’après ce que j’ai compris du code et les essais que j’ai faits, si je mets ’creer_user_base’ => false j’obtiens « La connexion à la base de données a échoué. » à l’étape 1 « Connexion à votre base de données », avec la nouvelle base créée et vide...

      Le ’creer_user_base’ => true me permet de passer dans le code qui ajoute les droits MySQL à l’utilisateur unique (qui ne doit pas être root) sur la base nouvellement créée.

      En utilisant la version actuelle de mutualiser_creer.php je me retrouve avec un nouvel utilisateur créé sur le serveur MySQL, qui porte le même nom que _INSTALL_USER_DB mais au lieu d’être @le_serveur_http il est @le_serveur_mysql, et évidemment ça ne peut pas fonctionner.

      J’avais commenté la ligne pour tester, et maintenant je pense qu’il faudrait mettre à la place quelque-chose comme

      if (!defined(’_INSTALL_HOST_DB_LOCALNAME’))
      define (’_INSTALL_HOST_DB_LOCALNAME’, _INSTALL_HOST_DB) ;

      qui permettrait de pouvoir différencier le cas ou le serveur MySQL n’est pas le serveur HTTP : la création de nouveau site fonctionnait sans modification avec la configuration de mes_options.php donnée précédemment sur l’environnement de développement ou serveur_MySQL = serveur_HTTP = localhost, le problème est apparu lorsque je l’ai essayée « en vrai », ou le serveur MySQL n’est pas le serveur HTTP et ou on doit donner à l’utilisateur MySQL nommé utilisateur_MySQL@serveur_HTTP (le _INSTALL_USER_DB donc) les droits sur la nouvelle base du nouveau site Spip.

      Sans modif du code, on se retrouve avec les droits de utilisateur_MySQL@serveur_HTTP inchangés, et un nouvel utilisateur_MySQL@serveur_MySQL ayant les droits sur la nouvelle base, mais inutilisable puisqu’on va s’en servir pour se connecter depuis serveur_HTTP...

      Avec modif, on obtient une mise à jour des droits de utilisateur_MySQL@serveur_HTTP, lui donnant les droits nécessaires sur la nouvelle base.

      Bon, d’accord, ce qui m’arrive n’est pas facile à expliquer :) ...

    • La correction proposée est tout aussi inutile, en théorie, que la première.

      if (!defined(’_INSTALL_HOST_DB_LOCALNAME’))
      define (’_INSTALL_HOST_DB_LOCALNAME’, _INSTALL_HOST_DB) ;

      Comme disait Fil, cela revient à laisser tel quel mutualiser_creer.php et à définir un define(’_INSTALL_HOST_DB_LOCALNAME’, ’serveur’) ; dans le mes_options.php du SPIP (avant l’appel à demarrer_site() donc).

      Si cela ne fonctionne pas, c’est que le problème est ailleurs.

      Par ailleurs aussi, le fait de mettre « creer_user_base = true » alors que ça ne semble pas répondre à votre besoin - si je comprends un peu - est ennuyeux. Peut être faut il ajouter une option « ajouter_user_base » (ou un meilleur nom) qui ne ferait qu’ajouter la permission à un utilisateur existant ?

    • Tout ce que je peux dire c’est que par défaut je me retrouve avec une création du même nom d’utilisateur depuis un hôte portant le nom du serveur MySQL, et que ça ne fonctionne pas !

      Mais bon, ici le DNS est parfois un peu bizarre. Peut-être est-ce l’explication...

      Quoi qu’il en soit, « ajouter_user_base » correspond effectivement à ce j’ai besoin de faire : si vous pouviez étudier cette possibilité dans une future évolution ça éviterait de demander à chaque fois la création d’un utilisateur qui existe déjà, et c’est peut-être aussi ça qui me crée des problèmes.

      J’en sais rien en fait. L’essentiel pour moi étant d’obtenir le résultat recherché dans le temps imparti, je vais me contenter de ça pour l’instant jusqu’à ce que la cause de ce bronx soit isolée.

      Merci en tous cas pour votre disponibilité, et pour ce développement qui permet de voir plus grand.

    • J’ai beau regarder le code, je vois pas où ça pourrait coincer.
      « creer_user_base » sous MySQL remplit bien ce que vous attendez : la requête SQL semble la même si on ajoute un utilisateur à une bdd que si on « crée et ajoute » un utilisateur à une bdd. Les define paraissent corrects également et devraient définir un « user@ip » que vous attendez SI le define est indiqué avant. Je ne vois pas ce qui pourrait clocher dans la mutu et ce que vous avez fait. C’est étrange.

    Répondre à ce message

  • 1
    Maxwell

    il doit le faire automatiquement
    Quant tu va apeller le site http://www.tartenpion.org il va te créer les dossier manquant dans sites/ tartenpion / et quand tu va faire http://intranet.tartenpion.org il va te créer les dossier manquant dans sites/ intranet.tartenpion /
    mais si tu veux faire des sites http://www.tartenpion.org/intranet c carement autre chose

    C’est bon j’ai réussi à faire ce que je voulais !!Ca marche quand je fais http://serveur/spip/intranet ou http://serveur/spip/internet avec la creation des tables utilsant le prefixe intranet et internet.
    J’avais un gros souci avec le fichier mes_options.php.En fait je voulais faire de la mutualisation de répertoire.
    Merci beaucoup de m’avoir aidé :D

    • Christophe Sevin

      Bonjour Maxwell,

      Si tu as réussi à faire de la mutualisation de repertoire avec SPIP 2.0, peux tu faire une contrib qui explique ou bien indiquer les contribs qui t’on été utiles pour le faire car j’aimerais faire la même chose mais je rencontre des difficultés.

      Merci.

    Répondre à ce message

  • Christophe Sevin

    Bonjour, la question peut paraitre stupide mais ou trouve t’on le lien pour télécharger le plugin (j’aimerais l’installer sur une SPIP 2.0.8).

    J’aimerais par ailleurs faire une mutualisation de répertoire, existe t’il une solution à privilégier dans ce cas (en fait j’aimerais simplement que mes utilisateurs ne soit pas déboussolés et gardent les mêmes adresses, mais ça je pourrais le faire grâce à une petite réécriture d’url) ?

    Merci beaucoup à tous les contributeurs ^^.

    Cordialement,

    Christophe Sevin.

    Répondre à ce message

  • 1

    Salut,

    Je vais poser la question con : si on a apache 1 chez notre hébergeur, ça marche toujours ?...

    Voici ma config chez MavenHosting :
    Version Apache : 1.3.41 (Unix)
    Version PHP : 5.2.9
    Version MySQL : 5.0.81-communit

    • Oui sans problème. Sauf que la méthode de configuration n’est pas la même. Mais si tu sais configurer ton apache , alors pas de soucis.

      A la limite copie colle ton httpd.conf pour voir

    Répondre à ce message

  • 2

    Un exemple de bidouille pour permettre à certains webmestres des sites mutualisés de disposer d’un dossier /plugins dans leur instance de site en plus du dossier /plugins du SPIP central est expliqué dans le Carnet Mutualisation : Gestion des dossiers /plugins (ou utiliser _DIR_PLUGINS_SUPPL)

    • cy_altern

      ça marche pas ton truc

    • tt tt tt ! tu ne dis pas « ça marche pas » alors que c’est simplement que tu n’as pas suivi la doc correctement ! (cf discussion sur l’IRC #spip ce matin)

    Répondre à ce message

  • 1
    Maxwell

    Bonjour,

    Merci beaucoup pour toutes vos réponses,

    Alors tu as fait une connerie, tu me vide le dossiers sites au plus vites

    Spip te les créera (c pour ça les chmod 777)mais un conseil ne les apelle pas pareils

    J’ai fait comme vous avez dit.Comment je dois faire dans ce cas, pour qu’il me crée un dossier intranet par exemple dans sites ??Quand je lance l’url http://serveur/spip/intranet il me crée en fait un dossier portant le nom de mon serveur dans sites.C’est pas vraiment cela que je souhaiterai avoir.J’ai du raté une étape ou je n’ai pas compris le principe.
    Merci d’avance
    Bonne journée !!

    Répondre à ce message

  • 1
    Maxwell

    Oui c’est bien cela.Pour l’instant je teste ca sur un serveur de développement.
    C’est plus pratique pour la maintenance des sites de mutualiser.Il suffit de mettre à jour une seule fois.

    « Sinon Tu mets spip dans un dossier spip, tu rajoute le plugins mutualisation et sites chmod 777) dans ce meme dossiers spip »

    Ceci a été fait.

    J’ai crée dans sites 2 dossiers intranet et internet avec chacun 4 dossiers( tmp,local,IMG et config)
    Ce que je comprend pas, c’est que lorsque je lance l’url http://serveur/spip/ ou http://serveur/spip/intranet
    il me demande de créer un répertoire et du coup me crée un dossier serveur(nom du serveur) dans sites.
    Il y aurait un systeme de redirection à mettre en place non ??

    • Alors tu as fait une connerie, tu me vide le dossiers sites au plus vites

      Spip te les créera (c pour ça les chmod 777)mais un conseil ne les apelle pas pareils

    Répondre à ce message

  • 1
    Maxwell

    Bonjour à tous

    Je souhaiterai me créer un intranet et un internet en utilisant la mutualisation
    Je possede un serveur : je lance mes appli web par exemple par l’url http://serveur/appli1...http://serveur/appli2

    Je me suis installé un SPIP dans http://serveur/spip
    J’ai installé le plugin mutualisation dans la racine de spip
    J’ai crée un dossier sites/ dans la racine spip avec acces ecriture
    J’aimerai pour lancer mes sites mutualisés de cette facon :
    http://serveur/intranet et http://serveur/internet
    Je n’y arrive pas du tout.Je n’arrive pas à configurer mon fichier mes_options.php
    Est ce que quelqu’un pourrait m’apporter un peu d’aide ??
    Merci d’avance

    • Bonjour

      Si je comprens bien tu vas monter 2 intrénet sur le même serveur ? Je trouve ça bizard mais bon, si c que pour deux site ne fais pas de mutualisation a mon goût

      Sinon
      Tu mets spip dans un dossier spip, tu rajoute le plugins mutualisation et sites chmod 777) dans ce meme dossiers spip

      Les dossier tmp, IMG et local doivent être supprimer. POur le mes_options a tu bien lu nos indications ?

    Répondre à ce message

  • une question bete,

    le plugin fonctionne tres bien sur ma machine sauf dans un cas qui me dérange beaucoup, celui du www.
    alors suis je une trume ? ou ais je raté quelque chose ?

    Répondre à ce message

  • 5

    Bonjour,
    Je voudrais mettre en place un site regroupant plusieurs marchands de chevaux, on pourrais accéder à ce site suivant 2 methode soit :
    -  www.<nom du marchand>.com et on aurait acces seulement aux articles liées à ce marchand (il a une rubrique perso ou sont tous ses articles)
    -  www.<nom du site>.com ou on aurait acces à l’ensemble des articles.

    est-ce possible avec le plugin mutualisation ? et si oui comment ?
    Merci d’avance pour les réponses

    • Bonjour, non la mutualisation ne vas pas spécialement t’aider, c’est une question SPIP et il y a plusieurs solutions possibles, va demander de l’aide sur la liste SPIP

      Cet article et exemple traite uniquement du cas site1.nomdedomaine.com , site2.nomdedomaine.com, site3.nomdedomaine.com ....

    • Salut,

      Merci pour cette contribution, juste une remarque le titre « ferme à SPIP » n’est pas explicite au premier abord.

    • Bonjour, que proposes tu comme titre ? ;-)

    • Silo à SPIP pourrait être sympa

    • et hop ! Je rebondis là dessus :

      ... www._site 1_.com, www._site 2_.com ...

      non la mutualisation ne vas pas spécialement t’aider.
      Cet article et exemple traite uniquement du cas site1.nomdedomaine.com , site2.nomdedomaine.com, site3.nomdedomaine.com ....

      Derrière, par le biais d’une redirection 301 ? Ca n’est toujours pas possible ?

      Ou alors faut-il installer sa ferme sur un dédié et avoir les clés du-dit dédié ???

    Répondre à ce message

  • 1

    Bonjour,
    Le lien GrmlEU donne l’erreur : « Fatal error : Call to undefined function : generer_url_article() in /home/grml/public_html/ecrire/public/composer.php(51) : eval()’d code on line 62 ».

    Répondre à ce message

  • Salut et merci pour ce superbe plugin !

    Comment je fais pour avoir :
    -  quelques plugins mutualisés (réponse : à la racine dans plugins)
    -  pour un site donné, ses propres plugins

    Sur IRC, _fil_ m’a dit dir_plguins => sites/ccc/plugins

    Après, le débat a tourné sur l’amateurisme des spipiens ;-)

    Je mets ça dans mes_options ?

    Répondre à ce message

  • 1

    dans l’intro est indiqué :
    "Installer le plugin Mutualisation (il est plus simple de ne pas le mettre dans le répertoire plugin) . Nous avons donc « /home/grml/public_html/mutualisation"

    c’est pas clair voire contradictoire.

    gnn ?

    • en fait tu peux soit l’installer dans le repertoire plugin soit à la racine ... mais comme ce plugin ne doit pas être désactivé, il est préférable de l’installer à la racine .

      donc en résumé il est préférable de l’installer dans /home/grml/public_html/mutualisation plutôt que dans /home/grml/public_html/plugins/mutualisation (l’installation du spip étant dans /home/grml/public_html/ )

      c’est plus clair comme cela ?

    Répondre à ce message

  • Oo que je suis content un article pour mutualisé spip ; depuis le temps que je me bagarre avec malgré le carnet et bien c’est pareil...

    Je suis nul.

    Donc j’ai installé ubuntu avec tous keskifo ;)

    l’adresse : www.bachant.info pointe sur la machine d’ailleurs j’ai la page d’accueil de la mutu.

    mais lorsque je fait www.test.bachant.info j’arrive a rien .Serveur introuvable

    je pense que c’est le fichier mes_options que je ne sais pas comprendre le voici donc en copie.
    Si vous pouvez faire en sorte que mon ecureuil et des jeunes j’en serais ravie merci

    @micalement stéphane

    <?php
    
            $GLOBALS['taille_des_logs']=1000;
            #parametrage a faire 
            $monTld="bachant.info";
    
            require _DIR_RACINE.'mutualisation/mutualiser.php';
            define ('_ID_WEBMESTRES', 1);
    
            $site = $_SERVER['HTTP_HOST'];
    
            $type_urls = 'propres2'; # par defaut, surchargeable ci-dessous
    
            switch($site) {
                    case "www.$monTld":
                            $site=$monTld;
                            break;
                    case 'www.spip-blog.net':
                            $site='spipblog';
                            break;
                    case 'spip-blog.net':
                            $site='spipblog';
                            break;
                    default :
                            $site = str_replace('.scriibe.net', '', $site);
                            break ; 
            }
            define ('_SITES_ADMIN_MUTUALISATION', ''); // ici sites esclaves
            define ('_INSTALL_SERVER_DB', 'mysql');
            define ('_INSTALL_HOST_DB', 'plouf');
            define ('_INSTALL_USER_DB_ROOT', 'plouf');
            define ('_INSTALL_PASS_DB_ROOT', 'plouf');
            define ('_INSTALL_TABLE_PREFIX', 'spip');
            define ('_INSTALL_NAME_DB', 'scr_'.prefixe_mutualisation($site));
            if ($site != "$monTld") {
                    demarrer_site($site,
                            array(
                            'creer_site' => true,
                            'creer_base' => true,
                            'code' => 'plouf',
                            'url_img_courtes' => true,
                            'creer_user_base' => true,
                            'mail' => 'asso.bachant@laposte.net'
                            )
                    );
            }
            else {
            $GLOBALS['dossier_squelettes']=":mutualisation";
            }
    >?

    j’ai opté pour scriibe, car une base et un utilisateur mysql sont créés pour chaque
    l’idée et de pouvoir démultiplier les sites de l’association et que chacun puiseent y trifouiller comme bon lui semble....

    Répondre à ce message

  • 1

    Ça marche sur quelle version ?

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom