Résumé

- Installez les fichiers de SPIP dans un répertoire ; appelons-le spip/, c’est la racine de votre système : svn co svn://trac.rezo.net/spip/spip/ spip/ ;
-  Faites pointer les URLs à mutualiser vers ce répertoire (VirtualHost) ;
-  Créez un répertoire sites/ à l’intérieur du répertoire racine, dans lequel le serveur peut écrire.
-  Créez une base de données mutu dans MySQL ;
-  Créez le fichier sites/config/mes_options.php avec :

<?php


require _DIR_RACINE.'ecrire/inc/mutualiser . La  mutualisation  facile php';


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


define ('_INSTALL_HOST_DB', 'localhost');
    define ('_INSTALL_USER_DB', 'loginsql');
    define ('_INSTALL_PASS_DB', '123456HDJ');
    define ('_INSTALL_NAME_DB', 'mutu');


demarrer_site($site,
        array(
            'creer_site' => true,
            'table_prefix' => true
        )
    );
?>

____

La mutualisation, qu’est ce ?

Supposons que vous avez plusieurs sites sous SPIP... Vous pouvez bien sûr installer les fichiers de SPIP Spip en plusieurs exemplaires, mais vous perdez ainsi de la place et surtout de la facilité de maintenance.

Mutualiser des sites SPIP Spip , c’est mettre en commun ce qui peut l’être (le moteur de squelette, l’interface privée etc), tout en proposant des données séparées sites différents .

Comment mutualiser ?

Il existe déja une documentation complète ( mais complexe ) sur la [Mutualisation du noyau SPIP->http://www manière de mutualiser SPIP .spip Mais avec Spip 1 .net/fr_article3514.html]. Ce code est en train d’être revu, dans la branche de développement de SPIP 1.9.3, il est désormais possible de manière à simplifier le procédé faire plus simplement .

Voici où nous en sommes, à la révision 9329 :

- Installez les fichiers de SPIP dans un répertoire, comme vous le ferez classiquement ; appelons-le spip/, c’est la racine de votre système.
- -#Installez Spip dans un répertoire , comme vous le ferez classiquement

1. Créez un répertoire sites/ à l’intérieur du répertoire racine principal .

Le principe est simple : à chaque site, qu’on identifiera par une variable $site, correspond à un répertoire sites/$site/ ; ce répertoire contient lui-même les quatre sous-répertoires de données du site :
-  spip/sites/$site/config/ contient les données de connexion connect.php et éventuellement le fichier mes_options.php du site ;
-  spip/sites/$site/IMG/ contient les images et documents associés aux articles de ce site ;
-  spip/sites/$site/tmp/ contient les fichiers cache de tout type ;
-  spip/sites/$site/local/ contient les images calculées (vignettes réduites, formules TeX...).

Comment identifier un site ?

Prenons l’exemple d’un système mutualisé qui sert les pages pour différents noms de domaines, chose.tld et truc.tld.

Il faut, tout d’abord, que http://chose.tld/ et http://truc.tld/ pointent tous deux vers la racine du système : pour cela il faut :

1. que le DNS pointe vers le serveur ;
2. que le serveur soit configuré de manière à servir ces domaines depuis notre répertoire spip/ (directive VirtualHost, commande « Héberger un domaine » d’AlternC, etc.)

Une fois ceci effectué, nous avons donc deux sites, tous deux servis par la même installation de SPIP. Bien évidemment, si on installe le site maintenant, il répondra de la même manière aux deux noms de domaines, il faut donc agir avant de procéder à l’installation du site.

On commence par créer un fichier central de configuration, dans spip/config/mes_options.php, qui contient :

<?php
    require _DIR_RACINE.'ecrire/inc/mutualiser.php';
    demarrer_site($_SERVER['HTTP_HOST']);
?>

Cette configuration est exécutée à chaque hit sur un fichier de SPIP, et définit les répertoires où le script ira chercher les images, la connexion à la base de données etc, comme indiqué plus haut.

En l’occurrence, nous avons décidé que chaque site serait représenté par la valeur de $_SERVER['HTTP_HOST'], c’est-à-dire truc.tld ou chose.tld. Si le site n’est pas installé (le répertoire spip/sites/truc.tld/ n’existe pas), la commande demarrer_site($site) le signale et vous demande de créer ce répertoire ainsi que les quatre sous-répertoires indispensables.

www ou pas ?

Il est possible de décider que l’url http://www.chose.tld/ doit être identifiée avec l’url http://chose.tld/, en d’autres termes qu’il ne s’agit que d’un seul et même site ; il faut dans ce cas être un peu plus subtil :

<?php
    require _DIR_RACINE.'ecrire/inc/mutualiser.php';
    $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
    demarrer_site($site);
?>

Cependant, une autre possibilité est largement préférable : il faut rediriger http://www.chose.tld/ vers http://chose.tld/ (ou l’inverse), en faisant par exemple :

<?php
    require _DIR_RACINE.'ecrire/inc/mutualiser.php';
    $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
    if ($site != $_SERVER['HTTP_HOST']) {
         include_spip('inc/headers');
        redirige_par_entete('http://'.$site.'/');
    }
    demarrer_site($site);
?>

Quoiqu’il en soit, le système de nommage du site est ouvert et peut se baser sur ce que l’on veut ; si on héberge par exemple sur ce système mutualisé tous les sites des sections locales de chose.tld, par exemple antananarivo.chose.tld, capetown.chose.tld, beijing.chose.tld, on fera :

<?php
    require _DIR_RACINE.'ecrire/inc/mutualiser.php';
    if (!preg_match(',^(www\.)?(.*)\.chose.tld$,', $_SERVER['HTTP_HOST'], $r))
        die ("Erreur : ce site n'est pas une chose.tld : ".$_SERVER['HTTP_HOST']);
    demarrer_site($r[2]); // $r[2] correspond au (.*) de l'expression rationnelle
?>

et dans ce cas les répertoires créés seront Le principe est simple  : chaque site ayant l’adresse < code>adresse</code > correspond à un répertoire <code>spip/sites/antanarivo/</code >,

spip/sites/capetown/&lt;/code >,  <code>spip/sites/beijing/&lt;/code >... code > sites/adresse&lt;/code > 


{{{Partager une même base de données ?}}}


Il est bien clair que les sites ne doivent pas mélanger leurs données ; en revanche il est possible (mais pas forcément souhaitable) de n'utiliser qu'une seule et unique base de données pour l'ensemble des sites d'un même système de mutualisation. On séparera alors les différents sites en utilisant des tables dont les noms seront préfixés différemment.


{{Pour utiliser les préfixes de table}}, dans notre exemple ci-dessus, on utilisera <code>antanarivo

comme préfixe pour les tables du site antanarivo, etc ; ainsi dans la base de données (unique), on aura des tables antanarivo_articles pour les articles du site antanarivo, et beijing_articles pour les articles du site beijing.

Pour faire cela, il suffit d’indiquer l’option suivante, dans l’appel à demarrer_site() :

    demarrer_site($site, array('table_prefix' => true)); 

Cette option « rabote » un peu la variable $site de manière à en faire un préfixe valide pour MySQL (10 caractères, lettres ou chiffres, pas de points ni de tiret, commence par une lettre). Le préfixe est enregistré dans la variable globale de SPIP $GLOBALS['table_prefix'].

Attention toutefois l’unicité n’est pas garantie, et si vous avez deux sites pour les sections locales de saint-gravier-la-bruyarde et de saint-gravier-le-feuillu, il risque d’y avoir un choc violent, les deux sites cherchant leurs données dans saintgravi_articles. (Si vous craignez d’être dans ce cas, il vous faudra adopter un algorithme un peu plus subtil.)

Si l’on utilise des bases différentes, on peut aussi changer le préfixe, mais pour le coup ça n’a pas d’importance. C’est lors de la connexion initiale (« installation du site ») qu’on précisera la base à employer, après l’avoir éventuellement créée, depuis SPIP ou dans l’interface AlternC.

Héberger des sites pour d’autres personnes

Dès lors que l’on veut héberger des sites pour d’autres que soi-même, on est confronté au processus d’installation de SPIP qui exige le login, mot de passe de la base de données, et permet ensuite à celle qui installe de choisir sa base parmi la liste des bases disponibles. S’il faut créer une base par utilisateur, ou si on doit prendre le risque de laisser l’installation partir sur les données d’un autre site (suite à une fausse manipe de sélection de la base ou du préfixe), on perd un des avantages de la mutualisation.

Considérons ici le scénario d’une seule base de données partagée par tous les sites : SPIP permet désormais de préciser dans mes_options.php une ou plusieurs des données de connexion à la base :

define ('_INSTALL_HOST_DB', 'localhost');
define ('_INSTALL_USER_DB', 'truc.tld');
define ('_INSTALL_PASS_DB', '1234FGH78');
define ('_INSTALL_NAME_DB', 'touslestructld');

Ces données étant ainsi figées, l’installation de SPIP ne les demande pas à la personne qui installe le site, mais lui signale que la donnée est fournie par l’hébergeur. Cette astuce est aussi bien pratique si on veut installer beaucoup de sites pour soi-même : on peut par exemple définir _INSTALL_HOST_DB, _INSTALL_USER_DB, _INSTALL_PASS_DB, mais laisser libre le nom de la base, pour pouvoir la créer/choisir à chaque installation (mais alors attention à la sécurité de la chose : mal géré, ça peut devenir catastrophique).

Création automatique du site

Les réglages précédents indiquent comment on gère l’association entre une URL, un site et une base de données. Il reste à voir comment créer automatiquement le site, sans avoir à aller par FTP créer des sous-répertoires etc.

Création automatique des sous-répertoires. C’est très simple, pour que le répertoire spip/sites/xxxx/ et ses sous-répertoires soient créés à la volée lors de la première connexion sur le site (au premier hit, une fois le DNS et le VHost/VirtualServer installés), il suffit de l’indiquer dans les options de la fonction demarrer_site() :

demarrer_site($site, array(
     'creer_site' => true
));

La première visite sur le site créera automatiquement les répertoires nécessaires, et il vous suffira d’aller dans ecrire/ pour lancer l’installation.

Attention ici à la sécurité : il faut absolument éviter d’avoir à la fois un domaine pas encore installé, les mots de passe SQL définis et un accès lire à toutes les bases ou tables de votre base mutualisée ; dans un tel cas en effet n’importe qui peut venir prendre le contrôle de n’importe quel site hébergé, ce qui fait mauvais effet...

Le système peut aussi créer la base à la demande (TODO).

Envoyer des mails à la création d’un site (TODO).

Cf. http://thread.gmane.org/gmane.comp.... et http://thread.gmane.org/gmane.comp....