SPIP

#URL_ECRIRE

Committo, Ergo Sum., Pierre KUHN — 2012-12-15T23:55:00Z

La balise #URL_ECRIRE fabrique l'URL d'un script de l'espace privé s'il existe.

Cette balise permet d'écrire des liens vers les scripts ?exec de l'espace privé.

Ainsi, [ ... ] va appeler /ecrire?exec=unscript.

Si le script n'existe pas (c'est-à-dire s'il n'existe pas de fichier du nom indiqué, dans les répertoires exec connus de SPIP et des plugins installés), cette balise ne retourne rien, et conséquemment tout l'extrait de squelette ci-dessus retournera la chaîne vide. C'est très pratique pour ne produire un lien que si le plugin qui y répond est installé.

Il est possible de compléter l'URL par une Query-String, en la donnant en deuxième argument à la balise :

#URL_ECRIRE{formulaires_voir,id_formulaire=#ID_FORMULAIRE}

S'il y a besoin de passer plus d'un paramètre, ou peut aussi faire appel au filtre parametre_url

Sans aucun argument, cette balise retourne l'URL de la page d'accueil de l'espace privé.

Pour des informations sur écrire Étendre SPIP

Pour générer une URL de l'espace public, on utilisera #URL_PAGE

Mutualisation : un SPIP pour plusieurs sites

Committo, Ergo Sum., Matthieu Marcillaud — 2010-07-08T22:30:11Z

Partager les fichiers de SPIP entre plusieurs sites, ce que l'on appelle une mutualisation, permet un gain d'espace disque important, ainsi qu'une possibilité de mise à jour de SPIP simple de l'ensemble des sites en ne mettant à jour que le noyau.

Sommaire

SPIP permet de mutualiser ses fichiers.
(les restaurations peuvent se réaliser d'un SPIP à l'autre comme s'il n'était pas mutualisé).

Le concept...

Les dossiers nécessaires au fonctionnement du noyau SPIP (ecrire, prive, squelettes-dist), et ceux marquant l'activité d'un site (config, IMG, tmp, local) sont clairement identifiables et séparés.
C'est cette séparation qui permet d'avoir plusieurs sites SPIP autonomes pour un même noyau de SPIP.

Cette autonomie repose sur quatre répertoires par site dans lesquels SPIP va écrire les données résultant de l'activité du site. On distingue les données temporaires et permanentes d'une part, et les données accessibles par HTTP et celles qui ne le sont pas d'autre part. Les deux répertoires inaccessibles par HTTP seront protégés par un .htaccess installé automatiquement par SPIP (les administrateurs du serveur peuvent mettre ces répertoires en dehors de l'arborescence servie par HTTP).

Ces quatre répertoires sont distincts et nommés par les constantes PHP suivantes :

define('_NOM_TEMPORAIRES_INACCESSIBLES', "tmp/"); define('_NOM_TEMPORAIRES_ACCESSIBLES', "local/"); define('_NOM_PERMANENTS_INACCESSIBLES', "config/"); define('_NOM_PERMANENTS_ACCESSIBLES', "IMG/");

Dans une installation simple de SPIP, ces répertoires sont créés à la racine du site avec les valeurs par défaut ci-dessus.
La mutualisation des sources de SPIP repose sur l'association de quatre répertoires spécifiques à chaque site, déduits de leurs URL.

Initialisation de la mutualisation

Cette association est effectuée par une fonction,
spip_initialisation. Elle admet quatre arguments indiquant la localisation des quatre répertoires fondamentaux, et construit à partir de ceux-ci les constantes servant au fonctionnement de SPIP.
Dans une installation simple, ces quatre arguments sont les quatre constantes ci-dessus. La fonction spip_initialisation est appelée juste après le chargement de mes_options.php,
et refuse silencieusement de s'exécuter si elle a déjà été appelée.
En conséquence, si dans ce fichier cette
fonction est appliquée sur des arguments différents déduits de l'URL du site, on aura autant d'utilisation des sources de SPIP que d'URL de site.
On peut aussi définir dans ce fichier les constantes servant au fonctionnement de SPIP, ces définitions ayant priorité sur celles qu'essaiera de définir spip_initialisation.

Le code ci-dessous, placé dans le fichier config/mes_options.php prend le nom de domaine et exécute une mutualisation sur les quatre répertoires tmp, local, config et IMG placés dans le dossier sites/nom_du_domaine/.
Auparavant, la définition de quelques constantes permet de centraliser les fichiers de journalisation de tous les sites dans un unique répertoire, log, et non dans sites/nom_du_domaine/tmp/ pour chacun. Cette centralisation n'a rien d'obligatoire mais se révèle utile ; elle peut s'appliquer aussi aux répertoires d'aide et de sauvegarde.

Mutualiser des domaines ou des sous-domaines

Pour mutualiser plusieurs domaines ou sous-domaines, vous devez tous les diriger vers le répertoire physique contenant SPIP. Par exemple, http://example.org/, http://example.net/ et http://sous_domaine.example.net/, pour les mutualiser, doivent tous pointer sur le même répertoire, comme /var/www/spip/.

Ce dossier contient donc SPIP ainsi qu'un fichier config/mes_options.php pour activer la mutualisation. En reprenant l'exemple de code donné au dessus, il faudra alors créer les dossiers sites et log ainsi que sites/example.org, sites/example.net et sites/sous_domaine.example.net avec dans chacun d'eux les répertoires config, local, IMG et tmp accessibles en écriture. Il n'y a rien d'autre à réaliser. En allant sur l'un des sites, SPIP devrait vous proposer son installation.

Si vous souhaitez pouvoir activer des types d'url différents, comme les « url arborescentes » ou les « url propres », il sera nécessaire de créer un fichier d'accès Http, qui est fourni dans la distribution sous le nom de htaccess.txt : il suffit de le renommer en .htaccess pour le mettre en œuvre. Il s'appliquera à tous les sites mutualisés, mais il est possible d'avoir des accès différenciés en configurant astucieusement le serveur (voir plus bas). Dans les deux cas,
tout cela ne fonctionnera que si votre serveur accepte d'exécuter toutes les directives présentes dans ce fichier, notamment celles concernant
la réécriture d'url (« url rewriting »).

Mutualiser les répertoires d'un domaine

Chaque dossier (virtuel) d'un domaine, en analysant correctement l'URL, peut aussi devenir un site SPIP mutualisé. Il faut pour cela que l'URL du dossier soit redirigée de façon transparente vers la racine du SPIP. C'est le rôle du fichier .htaccess modifié. Ainsi http://example.com/premier_site/ et http://example.com/second_site/ peuvent être chacun des sites SPIP mutualisés (et http://example.com/ aussi).

Dans un premier temps, il faut renommer le fichier htaccess.txt en .htaccess et le modifier pour indiquer que les répertoires qui sont virtuels doivent pointer à la racine de SPIP. Pour cela, ajouter dans la partie « Réglages personnalisés » soit le code générique qui traite tous les répertoires virtuels (mais http://example.com/premier_site sans / final renverra une erreur), soit un code indiquant les noms des dossiers (pas d'erreur si aucun / final) :

// code générique RewriteCond %{REQUEST_URI} !^/(config|ecrire|IMG|prive|plugins|plugins-dist|sites|squelettes-dist|squelettes|tmp|lib|local|mutualisation)/(.*) RewriteRule ^[^/]+/(.*) /$1 [QSA,L] // OU code spécifique RewriteRule ^(premier_site|second_site)$ /$1/ [R,L] RewriteRule ^(premier_site|second_site)/(.*) /$2 [QSA,L]

Dans un second temps, il faut créer une mutualisation en analysant dans le fichier config/mes_options.php l'url transmise. Voici un exemple pour avoir les sites mutualisés dans sites/exemple.com, sites/premier_site et sites/second_site :

Préfixe des tables

Les exemples présentés nécessitent autant de bases de données que de sites mutualisés. Cependant, il est possible d'installer tous les sites dans une même base de données, en préfixant les noms de leurs tables d'un préfixe unique.

L'exemple ci-dessous crée un préfixe de 8 caractères : un préfixe avec les 4 premières lettres du site, suivi de 4 autres caractères.

$table_prefix = substr(str_replace('.', '_', $site),0,4) . substr(md5($site),0,4);

Fichier config/mes_options.php

Toute modification du fichier config/mes_options.php du noyau SPIP affectera les options de tous les sites hébergés.

Par exemple, mettre dans ce fichier :
$type_urls = 'propres' ;

donnera par défaut à tous les sites ce type d'URL... Mais chaque site peut le changer dans son propre /sites/repertoire_du_site/config/mes_options.php.

Configurer Apache pour les domaines et sous-domaines

La mutualisation côté serveur, pour ce qui concerne la gestion des sous-domaines ou des domaines reste simple. Il suffit de créer une redirection entre le nom de domaine et le répertoire physique où est stocké SPIP.

Voici un exemple de configuration (minimale) pour un serveur nommé 'exemple.tld' utilisant des sous-domaines. Le fichier de configuration est à créer dans /etc/apache2/sites_availables/exemple.tld, qu'il faut ensuite activer

sudo a2ensite exemple.tld sudo /etc/init.d/apache2 reload

SPIP est installé dans cet exemple dans '/var/www/spip/'.

 ServerName exemple.tld ServerAdmin webmaster@localhost ServerAlias *.exemple.tld DocumentRoot /var/www/spip/  Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all

Si vous voulez en plus avoir des fichiers d'accès différenciés, il suffit d'utiliser la directive AccessFileName à l'intérieur de la directive
VirtualHost, de sorte que le fichier d'accès du site S se nomme par exemple .htaccess-S.

Note sur les sauvegardes et les restaurations

Chaque site copie par défaut ses fichiers de sauvegardes dans le répertoire
/sites/premier_site/tmp/dump (ou /sites/premier_site/tmp/upload/login pour les sauvegardes d'un administrateur restreint).

Les restaurations se font par le même dossier. Le chemin des images est aussi correctement pris en compte .

Les auto-références multilingues de la documentation

Committo, Ergo Sum. — 2009-03-22T22:32:17Z

Les rédacteurs de la documentation doivent impérativement utiliser la notation [{}->artN] pour référencer l'article N de la documentation, et les traducteurs peuvent recopier ce raccourci sans plus avoir à le modifier un jour. En effet, si l'article N n'existe pas dans la langue du texte qui utilise ce raccourci, celui-ci produira l'URL de l'article N (ce qui est le mieux que l'on puisse faire), mais si une traduction existe, ce sera automatiquement l'URL de cette traduction qui sera produite. Plus précisément, ce comportement sera strictement observé lors d'une référence à partir de l'espace privé, tandis que dans l'espace public on ajoute la contrainte supplémentaire que la traduction soit publiée, afin de produire une URL disponible à coup sûr.

Comment est-ce possible ? SPIP interprète une paire d'accolades vides comme un hreflang égal à la langue du texte où figure le raccourci. La surcharge introduite pour ce site consiste simplement à chercher si l'article désigné par le raccourci existe dans la langue indiquée par le hreflang. Si c'est le cas, le raccourci ->artN est remplacé par ->artP, où P est la traduction de N.

Les bases de données en SPIP

Committo, Ergo Sum. — 2008-12-12T21:45:47Z

SPIP peut être vu comme un outil de mise en page dans un format MIME (HTML, RSS, ICS ...) d'extraits de bases de données.
SPIP peut rassembler dans une page des données en provenance de plusieurs bases SQL, accessibles par des serveurs éventuellement différents et distants les uns des autres. SPIP se charge de gérer les différentes connexions et déclarations de tables sans imposer de programmation à ses utilisateurs. Le présent article expose ces manipulations de bases de données.

Sommaire

Installation minimale

Voici d'abord tous les scénarios possibles d'installation de SPIP avec une seule base.

Lors de l'installation de SPIP, celui-ci teste la configuration de PHP et propose, lorsque c'est possible, un choix parmi plusieurs types de serveurs SQL (actuellement MySQL ou SQLite), qui offrent tous les mêmes fonctionnalités. À ce stade, il faut également fournir l'adresse Internet du serveur SQL, un identifiant de connexion à ce serveur et son mot de passe associé. Ces informations sont en général à saisir dans le formulaire d'installation et sont sauvées dans un fichier qui par défaut est config/connect.php. Toutefois, si vous voulez mettre en œuvre la Mutualisation du noyau SPIP, vous pouvez indiquer une ou plusieurs de ces valeurs dans le fichier de configuration mes_options.php. SPIP ne les demandera alors pas, ce qui dispense de les saisir et ne vous oblige pas à les communiquer à ceux qui utiliseront votre installation mutualisée.
Voici les noms des constantes PHP à définir pour cela :

`_INSTALL_SERVER_DB`	type du serveur SQL (Mysql ou PG ; casse indifférente)
`_INSTALL_HOST_DB`	nom Internet du serveur SQL (par exemple : localhost)
`_INSTALL_USER_DB`	un nom d'utilisateur du serveur SQL
`_INSTALL_PASS_DB`	son mot de passe

SPIP se connecte alors au serveur choisi, avec les identifiants de connexion.
En cas de réussite, il teste si l'utilisateur a le droit de créer des bases, ou seulement le droit de voir celles présentes et d'en choisir une, voire n'a le droit que d'utiliser une base homonyme de son nom d'utilisateur. Vous pouvez également fixer d'avance dans le fichier mes_options.php le nom de la base de données à utiliser, en définissant la constante PHP :

_INSTALL_NAME_DB nom de la base

SPIP poursuit alors l'installation en créant ses tables SQL (ou, en cas de réinstallation, en vérifiant que celles présentes sont utilisables). Ces tables commencent toutes par un préfixe de table (qui vaut par défaut spip_) et peut être indiqué dans mes_options.php de deux manières :

la variable globale	`$table_prefix`
la constante	`_INSTALL_TABLE_PREFIX`

Ce préfixe de table est ce qui permet d'écrire des boucles abrégées dans les squelettes, comme alors que le nom SQL de la table est en fait spip_articles.


SPIP demande ensuite de créer le premier utilisateur du site en fournissant un nom et un mot de passe (sans rapport avec ceux du serveur SQL) ou en proposant de déléguer le service d'authentification à un serveur LDAP. Après cette déclaration, la procédure minimale d'installation est terminée, et la page suivante est la page habituelle d'entrée dans l'espace de rédaction, qui demande les identifiants venant d'être saisis.

`Compléments d'installation`


Voici à présent comment indiquer à SPIP plusieurs bases à exploiter, sous le même serveur ou sous des serveurs différents, et même sur des machines différentes.
Une fois le site installé, choisir le sous-menu maintenance du site dans le menu configuration en haut de l'espace privé. Ce menu fournit une page à trois onglets ; cliquer sur celui de droite, nommé déclarer une autre base.

On accède alors à un formulaire quasiment identique au formulaire d'installation : il propose d'indiquer un type de serveur SQL, son adresse Internet, un nom d'utilisateur et son mot de passe. En cas de connexion réussie, SPIP demandera de fournir le nom d'une base, en listant celles présentes s'il en a la possibilité. Si elle existe bien, il créera un fichier de connexion supplémentaire, qui par défaut se trouve dans le répertoire config et porte le nom de la base de données indiquée.
Cela fait, SPIP revient à nouveau à ce formulaire, et liste les fichiers de connexion présents, autrement dit les bases accessibles. SPIP propose donc de déclarer encore une base supplémentaire : il n'y a pas de limitation au nombre de bases déclarables.
L'intérêt de ces déclarations est de pouvoir appliquer la notation des squelettes de mise en pages à ces bases supplémentaires. S'il existe un fichier de connexion nommé B.php, permettant d'interroger une base possédant une table nommée T, alors le squelette #TOTAL_BOUCLE donnera le nombre de lignes de cette table. De plus, SPIP demande au serveur SQL de lui décrire cette table, ce qui lui permet de connaître ses champs et, éventuellement, sa clé primaire. Si la boucle T a une clé primaire nommée id et un champ nommé nom, alors le squelette : #NOM donnera le champ nom de l'unique ligne ayant l'id donné par le contexte.
Enfin, il est possible d'appliquer un squelette en demandant que toutes ses boucles utilisent une autre base que celle par défaut, en ajoutant dans l'URL de la page le paramètre connect indiquant le nom de la base. Par exemple http://monsite?connect=autre_site appliquera le squelette sommaire standard du site monsite à la base indiquée par le fichier de connexion config/autre_site.php dans le répertoire d'installation de mon_site.
Il est recommandé de respecter la casse du nom du fichier de connexion, lorsqu'on l'utilise dans une boucle ou comme paramètre de connect : aucune conversion majuscules / minuscules n'est effectuée par SPIP (mais certains systèmes de fichiers le font).
Remarque : L'accès à des bases supplémentaires est exclusivement en lecture ; en particulier, si une base est par exemple un forum (administré par SPIP ou non) il reste impossible de poster dans ce forum autrement qu'à partir de son site d'origine. La levée de cette restriction est à l'étude.

`Installations croisées`


Les extraits de squelette ci-dessus reposent donc sur l'existence d'un fichier de connexion nommé B.php.

Un point important est que le fichier de connexion principal et ceux des bases supplémentaires ont le même format, ce qui permet en particulier à un site SPIP d'utiliser directement le fichier de connexion d'un autre site SPIP pour exploiter ses tables. Une manière de procéder est de copier le fichier connect.php du site B sous le nom B.php dans le répertoire config du site A.
Une manière plus astucieuse, dans le cas de sites partageant une même installation de SPIP, est d'avoir un seul répertoire config pour tous les sites, et d'y nommer le fichier de connexion du site A non pas connect.php mais A.php, de même pour le site B etc. De la sorte, dès qu'un site est installé sous SPIP, il est connu comme base supplémentaire de tous les autres sites partageant cette installation de SPIP, et il verra tous les sites utilisant le même répertoire config que lui comme autant de bases supplémentaires. Pour obtenir cet optimum dans les déclarations implicites, il faut définir soigneusement les constantes _DIR_CONFIG et _FILE_CONNECT_INS. 

On trouvera plus bas un exemple de mutualisation offrant cette fonctionnalité et quelques autres.
Pour un site installé sur un serveur SQL éloigné, la copie de son fichier de connexion sur le site local peut suffire en théorie. Toutefois beaucoup d'hébergeurs refusent que leurs serveurs SQL soient interrogés par des machines en dehors de leur réseau local. Il faut aussi penser que bien souvent le « nom » indiqué pour le serveur SQL à l'installation est localhost, qui est une adresse relative au serveur HTTP, alors qu'ici il y a nécessité d'une adresse absolue. En bref, SPIP peut opérer dans une telle architecture, mais un minimum de connaissances, voire d'autorisation d'intervention, sur la topographie des sous-réseaux en jeu est pratiquement indispensable.

`Les bases supplémentaires sous SPIP`


Lorsqu'un fichier de connexion est celui d'un autre site sous SPIP (que ce soit une copie ou l'original accessible par installations croisées), il contient l'indication que ce site est sous SPIP (la globale spip_connect_version y est affectée). Dans ce cas, les squelettes du site principal vont s'appliquer avec un comportement spécial :
- les boucles avec nom abrégé seront interprétées comme abrégées aussi dans la base supplémentaire ; autrement dit,  (ou  avec une URL comportant connect=B.) référencera la table spip_articles dans la base B, plus précisément la table prefixearticles où prefixe est celui utilisé par le site B (ce préfixe est indiqué dans le fichier de connexion) ;

- à l'intérieur d'une boucle, les balises #URL_ (voir Utiliser des URLs personnalisées) utiliseront le type d'URL du site principal, et non du site distant, et l'URL produite référencera le site principal par connect=site_distant ; cette stratégie permet de naviguer dans la base du site distant sans cesser d'utiliser les squelettes du site principal, autrement dit de tester l'apparence que donne ce jeu de squelettes et son type d'URL sur le site distant sans modifier l'installation de celui-ci ou travailler sur une copie.
- Les raccourcis SPIP des balises #URL qui peuvent figurer dans les champs de la base de données distante sont eux aussi interprétés de cette manière : [->art3681] référencera bien l'article 3681 de la base distante, mais à travers une URL qui fournira la mise en page par les squelettes du site principal.
Ce mode de fonctionnement permet donc de présenter d'autres bases SPIP sans même avoir à écrire des squelettes de mises en page, puisque les noms des tables dans ceux-ci sont les mêmes que ceux du site distant. En revanche, une base qui n'est pas sous SPIP a besoin de squelettes de mises en page nommant explicitement les tables de cette autre base et ses champs.

Pour répondre à ce besoin, les administrateurs du site bénéficient d'un traitement spécial : lorsqu'ils donnent à leur navigateur l'URL de leur site suivi de ?page=table:nom_de_la_table où nom_de_la_table est le nom d'une table de la base (exemple : ?page=table:articles), SPIP va automatiquement construire un squelette spécifique à cette table, permettant d'en examiner le contenu avec une grande ergonomie. Le squelette produit est affichable à travers le lien squelette en bas de page. Il est possible alors de le copier à la souris (cliquer en haut de colonne pour cacher la numérotation des lignes) et de l'améliorer en le travaillant sous un éditeur approprié.
À noter qu'avec cette production automatique, SPIP pourrait, à la limite, fonctionner sans aucun squelette prédéfini.

`Sauvegardes et Fusions`


Avec le sous-menu maintenance du site, SPIP donne accès à deux outils de sauvegarde et restauration de la base de données locale (voir Sauvegarder vos données). Il est possible d'installer une sauvegarde issue d'un vieux site, dans une installation de SPIP de numéro de version supérieur.
Le formulaire de sauvegarde propose de limiter la sauvegarde à une rubrique donnée. Le fichier produit contiendra les articles, sites, brèves et sous rubriques contenu dans la rubrique indiquée, ainsi que les mots-clés et groupes de mots-clés utilisés par toutes ces données. Le nom de la sauvegarde sera par défaut le nom de la rubrique, mais cela peut être changé. La création des fichiers de sauvegarde peut être si longue que le serveur HTTP peut vous déconnecter pour cause d'inactivité apparente. 

Recharger simplement la page : SPIP retrouvera à quel endroit il en était et poursuivra son travail. Le grand nombre de fichiers que vous pourrez temporairement apercevoir dans un sous-répertoire du répertoire tmp est normal, car lié à l'anticipation de cette situation de reprise après déconnexion.
Symétriquement, le formulaire de restauration propose à présent deux fonctionnalités. La première est l'habituel remplacement de la base courante par la base sauvegardée. La deuxième consiste à considérer le fichier de sauvegarde comme une base incomplète venant s'ajouter à la base déjà installée. Comme il peut y avoir conflit entre la base installée et la base incomplète en ce qui concerne la numérotation de leurs tables (d'articles, de brèves etc), SPIP commence par renuméroter les éléments de la base incomplète en leur affectant des numéros immédiatement supérieurs aux maxima de la base installée. Dans une deuxième passe, SPIP importe effectivement les éléments renumérotés, mais lors de la première passe, il a comparé les éléments à importer avec ceux de la base installée et a ignoré les doublons définis par les règles suivantes :
- s'il existe dans la base installée un groupe de mots-clés de même nom qu'un groupe de mots-clés à importer, ce groupe est ignoré ;
- si un mot-clé dont le groupe de mot-clés n'a pas été importé possède un homonyme dans un groupe de mot-clés portant le même nom que son groupe d'origine, ce mot-clé est ignoré ;
- s'il existe dans la base installée une rubrique de secteur portant même nom qu'une rubrique de secteur à importer, cette rubrique est ignorée ;
- si une sous-rubrique dont la rubrique parente n'a pas été importée possède un homonyme de même parenté, cette sous-rubrique est ignorée ; il en est de même pour les articles, les brèves et les sites référencés ;
- s'il existe dans la base installée un document portant même nom qu'un document à importer et qu'ils ont même taille, ce document est ignoré.
Dit de manière plus synthétique, l'opération de fusion est l'union de deux bases, le contenu de la base installée ayant priorité sur la base importée en ce qui concerne les doublons (par exemple, pour deux secteurs de même nom, les champs texte et descriptif de celui déjà installé seront conservés et les autres seront ignorés).
En ce qui concerne les documents joints, ceux-ci seront importés en tant que documents distants, ce qui dispense de recenser et copier la partie du répertoire IMG/ concernée par la sauvegarde partielle. On peut ensuite utiliser, sur chaque document, le bouton de copie locale pour s'affranchir du site d'origine. Si celui-ci a déjà disparu ou possède des restrictions d'accès non contournables par le site récepteur, il faudra installer le répertoire IMG/ originel à une URL accessible, et la donner dans la dernière case de saisie du formulaire d'importation.
On notera la possibilité de rabattre les statuts de valeur publié à la valeur proposé, ce qui permet de garder une politique de publication au cas par cas, malgré cette importation massive.

`Un exemple complet`


L'installation mutualisée de SPIP ci-dessous permet d'avoir un seul répertoire de configuration (_DIR_CONNECT) et un seul de sauvegardes (_DIR_DUMP).

Chaque site peut ainsi donner des aperçus de la base de chacun des autres, et utiliser leurs sauvegardes pour les fusionner avec sa propre base. 

N'est utilisé aussi qu'un seul répertoire pour le cache de l'aide en ligne (_DIR_AIDE) car SPIP l'importe au coup par coup à partir du serveur spipnet, et un seul répertoire pour les Document Type Definitions que article 3541 va chercher sur le site du W3C et autres (_DIR_XML).

Les fichiers de droits et de journalisation sont également rassemblés dans seulement deux répertoires (_DIR_CHMOD et _DIR_LOG).

Seront donc créés à la racine config/connect, config/chmod, tmp/log, tmp/dump, tmp/xml et tmp/aide. Le premier contiendra A.php pour la connexion à la base A, B.php etc.
if ( preg_match(',/([a-zA-Z0-9_-]*)[/?],',$_SERVER['REQUEST_URI'],$r)) { if (is_dir($e = _DIR_RACINE . 'Ajouts/' . $r[1]. '/')) { $cookie_prefix = $table_prefix = $r[1]; define('_SPIP_PATH', _DIR_RACINE. 'Ajouts/' . $table_prefix . '/dist/:' . _DIR_RACINE .'Ajouts/' . $table_prefix . '/:' . _DIR_RACINE .'dist/:' . _DIR_RACINE .'dist/javascript/:' . _DIR_RESTREINT); $pi = $e . _NOM_PERMANENTS_INACCESSIBLES; $pa = $e . _NOM_PERMANENTS_ACCESSIBLES; $ti = $e . _NOM_TEMPORAIRES_INACCESSIBLES; $ta = $e . _NOM_TEMPORAIRES_ACCESSIBLES; $pig = _DIR_RACINE . _NOM_PERMANENTS_INACCESSIBLES; $tig = _DIR_RACINE . _NOM_TEMPORAIRES_INACCESSIBLES; define('_DIR_DUMP', $tig . 'dump/'); define('_DIR_AIDE', $tig . 'aide/'); define('_DIR_CACHE_XML', $tig . "xml/"); define('_DIR_LOG', $tig . 'log/'); define('_DIR_CONNECT', $pig . 'connect/'); define('_DIR_CHMOD', $pig . 'chmod/'); define('_FILE_CONNECT_INS', $table_prefix); define('_FILE_CHMOD_INS', $table_prefix); define('_FILE_LOG_SUFFIX', '_' . $table_prefix . '.log'); $GLOBALS['test_dirs'] = array($pa, $ta, $ti, $pig, $tig, _DIR_DUMP, _DIR_LOG, _DIR_CONNECT, _DIR_CHMOD); spip_initialisation($pi, $pa, $ti, $ta); } )



L'interface de SPIP avec SQL
Committo, Ergo Sum. — 2008-12-12T21:45:43Z

Sommaire
 Architecture générale
 Fonctions disponibles
 Réalisation des portages
Cet article comporte trois parties. Les deux premières sont destinées aux développeurs désireux d'écrire des extensions de SPIP ; elles présentent l'architecture générale, puis les fonctions disponibles. La troisième détaille l'implémentation et est destinée aux contributeurs de SPIP, désireux de le porter sur d'autres implémentations de SQL ou d'améliorer les portages existants. Dans tout l'article, on parlera de serveur SQL pour désigner une implémentation de SQL utilisée par SPIP, bien qu'à proprement parler certaines implémentations ne sont pas des serveurs.
Architecture générale
Dans un premier temps, on peut considérer que l'interface de SPIP aux implémentations de SQL se réduit à l'unique fonction suivante, définie dans le fichier ecrire/base/abstract_sql.php :
sql_serveur($ins_sql, $serveur='', $continue=false) 
Cette fonction commence, si elle ne l'a pas déjà fait auparavant, par se connecter au serveur spécifié en deuxième argument.

Cet argument est souvent omis, ce qui désigne alors l'implémentation SQL choisie à l'installation, et mémorisé par SPIP dans un fichier de connexion (voir Les bases de données en SPIP).

Sinon, l'argument doit indiquer explicitement le nom du fichier de connexion à utiliser, l'extension .php étant omise. Le résultat retourné est une autre fonction, réalisant le type d'action demandée par la chaîne passée en premier argument (par exemple select ou fetch) sur la base SQL indiquée par le fichier de connexion. 

Le troisième argument indique ce qu'il faut faire lorsqu'une telle fonction ne peut être retournée.

S'il est absent ou égal à false, une erreur fatale sera déclenchée. 

Autrement, deux autres situations sont distinguées.

Si la connexion indiquée est inconnue ou inopérante, la valeur false sera retournée.

Autrement, sera retournée une structure de données décrivant la connexion (elle sera décrite dans la dernière partie), ce qui permet d'une part de vérifier qu'une fonction existe sans risquer l'erreur fatale, et d'autre part d'obtenir plusieurs informations avant utilisation.
Cette vision minimaliste de l'interface permet de tout faire, mais avec une syntaxe assez opaque. Si par exemple $db est le nom d'une base dans le serveur principal, on ne le sélectionnera pas
$f = sql_serveur('selectdb'); $f($db); 
Pour clarifier l'écriture, il existe un jeu de fonctions enchaînant les deux instructions ci-dessus pour les cas les plus fréquents. Par exemple, il existe
sql_selectdb($nom, $serveur='') 
Ce qui permet de réécrire plus simplement l'opération précédente :
sql_selectdb($db) 
De manière générale, l'interface de SPIP aux serveurs SQL est un jeu de fonctions dont le nom est sql_f et dont le dernier argument, optionnel, est le nom du serveur. Elles appellent sql_serveur pour obtenir une fonction f qu'elles appliquent sur leurs arguments, y compris le nom du serveur.

Toutes les fonctions dont le nom est ainsi construit sont réservées à l'interface de SPIP aux serveurs SQL.
Dans une vision orientée objet, ce jeu de fonctions représente les méthodes de l'objet sql, mais on écrit sql_f à la place de sql->f, et il n'est pas nécessaire d'instancier une classe. La présence du nom du serveur dans tous les appels permet de simuler les opérations impliquant l'objet moi-même.
Ce jeu de fonctions dispense donc la plupart du temps d'utiliser sql_serveur. Signalons également la fonction (présente dans SPIP de longue date) :
spip_connect($serveur='')
qui simplement ouvre la connexion au serveur, et est donc équivalente à
sql_serveur('', $serveur, true)
et qui retourne false si le serveur est indisponible, sinon la structure de données décrivant les possibilités du serveur.
Fonctions disponibles
Les fonctions de l'interface SQL peuvent se classer en plusieurs groupes, pour lesquels on donnera à chaque fois un tableau présentant leurs arguments. Pour les exemples on se reportera au code de SPIP.
Un premier groupe de fonctions concernent la lecture des tables SQL.

Les fonctions incontournables sont :
- sql_select dont les arguments sont les clauses SQL habituelles de cette instruction, et dont le résultat est une ressource Select ;
- sql_fetch, utilisée presque toujours dans une boucle, qui permet de récupérer les lignes successives d'une ressource Select ; son résultat est un tableau indexé par le nom des champs ;
- sql_free qui signale au serveur de libérer une ressource.
D'autres fonctions offrent des compositions fréquentes de ces opérations :
- sql_fetsel de mêmes arguments que sql_select, qui applique celle-ci sur ses arguments puis sql_fetch sur la ressource retournée ; pratique pour les requêtes dont le résultat ne comporte qu'une ligne ;
- sql_getfetsel de mêmes arguments que sql_select, qui applique celle-ci sur ses arguments puis sql_fetch sur la ressource retournée, et enfin extrait du tableau retourné le champ dont le nom est donné comme premier argument (la liste des champs n'en comporte donc qu'un) ; pratique pour les requêtes dont le résultat ne comporte qu'une ligne d'un seul champ ;
- sql_allfetsel de mêmes arguments que sql_select, qui applique celle-ci sur ses arguments puis sql_fetch sur la ressource retournée tant que celui-ci retourne un tableau non vide ; sql_allfetsel retourne pour finir le tableau de tous les tableaux retournés par sql_fetch (attention à ne pas saturer la mémoire avec cette fonction) ;
- sql_countsel de mêmes arguments que sql_select moins le premier, qui applique celle-ci sur COUNT(*) et ses autres arguments et retourne le nombre calculé ; pratique pour connaître le nombre de lignes que retournerait la requête Select ainsi décrite.
- sql_count qui retourne le nombre de lignes d'une ressource Select, comme si on avait ajouté COUNT(*) dans la requête ;
- sql_get_select utilise les mêmes arguments que sql_select, mais retourne le code SQL de la requête, sans l'exécuter. Cette fonction peut-être utile pour les besoins de certains plugins ou pour créer facilement des vues SQL.
Les quatre premières appellent pour finir sql_free, et sont donc à préférer autant que possible au trio select-fetch-free dont on oublie facilement le dernier membre.
Le tableau ci-dessous précise le contenu et l'ordre des arguments attendus par ces fonctions.



Fonction
Arguments

sql_select
liste des champs : chaîne ou tableau
liste des tables : chaîne ou tableau
 clause Where : chaîne ou tableau
 clause Groupby : chaîne avec virgule séparatrice ou tableau
 clause Orderby : chaîne avec virgule séparatrice ou tableau
 clause Limit : un ou deux entiers séparés par des virgules
clause Having : chaîne ou tableau
serveur

sql_fetch
ressource
serveur

sql_free
ressource
serveur

sql_count
ressource
serveur

sql_countsel
liste des tables : chaîne ou tableau
 clause Where : chaîne ou tableau
 clause Groupby : chaîne ou tableau
 clause Orderby : chaîne avec virgule séparatrice ou tableau
 clause Limit : un ou deux entiers séparés par des virgules
clause Having : chaîne ou tableau
serveur

sql_fetsel
liste des champs : chaîne ou tableau
liste des tables : chaîne ou tableau
 clause Where : chaîne ou tableau
 clause Groupby : chaîne avec virgule séparatrice ou tableau
 clause Orderby : chaîne avec virgule séparatrice ou tableau
 clause Limit : un ou deux entiers séparés par des virgules
clause Having : chaîne ou tableau
serveur

sql_allfetsel
liste des champs : chaîne ou tableau
liste des tables : chaîne ou tableau
 clause Where : chaîne ou tableau
 clause Groupby : chaîne avec virgule séparatrice ou tableau
 clause Orderby : chaîne avec virgule séparatrice ou tableau
 clause Limit : un ou deux entiers séparés par des virgules
clause Having : chaîne ou tableau
serveur

sql_getfetsel
nom d'un champ : chaîne
liste des tables : chaîne ou tableau
 clause Where : chaîne ou tableau
 clause Groupby : chaîne ou tableau
 clause Orderby : chaîne avec virgule séparatrice ou tableau
 clause Limit : un ou deux entiers séparés par des virgules
clause Having : chaîne ou tableau
serveur

sql_get_select
liste des champs : chaîne ou tableau
liste des tables : chaîne ou tableau
 clause Where : chaîne ou tableau
 clause Groupby : chaîne avec virgule séparatrice ou tableau
 clause Orderby : chaîne avec virgule séparatrice ou tableau
 clause Limit : un ou deux entiers séparés par des virgules
clause Having : chaîne ou tableau
serveur


Dans les fonctions ci-dessus, si la clause Select est fournie sous forme de tableau, ses éléments seront concaténés, séparés par des virgules.

En cas de tableau pour les clauses Where et Having, les éléments doivent être des chaînes (des sous-tableaux en notation préfixée sont également pris en charge, mais réservés au compilateur). Ces chaînes seront réunies en une grande conjonction (i.e, elles seront concaténées avec AND comme séparateur).
La clause From est une chaîne (le cas du tableau est réservé au compilateur de SPIP).

Attention : s'il est nécessaire de référencer les tables dans les autres clauses, il faut en définir des alias dans ce paramètre et les utiliser systématiquement. Ainsi, on écrira :
sql_countsel('spip_articles AS a, spip_rubriques AS r', "a.id_secteur=r.id_rubrique AND r.titre='monsecteur') 
ou
sql_countsel('spip_articles AS a JOIN spip_rubriques AS r ON a.id_secteur=r.id_rubrique", "r.titre='monsecteur'") 
alors que l'écriture suivante ne sera pas comprise :
sql_countsel('spip_articles, spip_rubriques', "spip_articles.id_rubrique=spip_rubriques.id_secteur AND spip_rubriques.titre='monsecteur'") 
Un deuxième groupe de fonctions est constitué par celles modifiant le contenu des tables. Ces fonctions sont délicates à définir car la syntaxe des valeurs à introduire dans les tables change d'un serveur SQL à un autre (notamment les dates). Pour cette raison, ces fonctions doivent disposer de la description de la table à modifier, afin de connaître le type des valeurs attendues par le serveur SQL. SPIP retrouve automatiquement ces informations (données au moment de la création de la table) mais il est possible de fournir une description arbitraire (avant-dernier argument de ces fonctions, optionnel et d'ailleurs rarement utile).
SPIP fournit donc une fonction d'insertion, sql_insertq, et une fonction de mise à jour, sql_updateq, qui prennent un tableau champ=>valeur et s'occupent de citer les valeurs en fonction du type (avec la fonction sql_quote spécifiée ci-dessous).
Est également disponible sql_insertq_multi permettant de faire des insertions de plusieurs entrées en prenant un tableau de tableau champ=>valeur.
Pour les mises à jour où les nouvelles valeurs dépendent des anciennes (comme dans cpt=cpt+1), utiliser sql_update où les valeurs seront prises littérallement, mais il faudra interdire soigneusement les possibilités d'attaque par injection de code.
Il existe également sql_replace, fonction effectuant une mise à jour sur une ligne correspondant à une clé primaire, ou insérant les valeurs si cette ligne n'existe pas 

ainsi qu'une fonction sql_replace_multi pour des mises à jour ou insertions multiples.

Enfin, sql_delete efface d'une table les lignes répondant à une clause Where.



Fonction
Arguments

sql_updateq
table
tableau champ=>valeur à citer
 clause Where
 description
serveur

sql_update
table
tableau champ=>valeur
 clause Where
 description
serveur

sql_insertq
table
tableau champ=>valeur à citer
 description
serveur

sql_insertq_multi
table
tableau de tableau champ=>valeur à citer
 description
serveur

sql_replace
table
tableau champ=>valeur à citer
 description
serveur

sql_replace_multi
table
tableau de tableau champ=>valeur à citer
 description
serveur

sql_delete
table
 clause Where
serveur


Un groupe un peu à part est formé de fonctions traitant spécifiquement des opérandes. : elles ne se connectent pas au serveur, mais retournent des chaînes dépendant de celui-ci :
- sql_quote prend une chaîne ou un nombre, retourne un nombre si l'argument était un nombre ou une chaîne représentant un entier, sinon retourne la chaîne initiale entourée d'apostrophes et avec les apostrophes protégées selon la syntaxe propre au serveur (un \ devant pour certains, une deuxième apostrophe pour d'autres) ;
- sql_hex prend une chaîne de chiffres hexadécimaux et retourne sa représentation dans le serveur SQL visé ;
- sql_in construit un appel à l'opérande IN, en traitant les éventuelles valeurs hexadécimales y figurant ;
- sql_test_int prédicat retournant Vrai si le type SQL fourni désigne un entier ;
- sql_test_date prédicat retournant Vrai si le type SQL fourni désigne une date ;
- sql_multi applique une expression SQL sur champ contenant un bloc multi (voir Réaliser un site multilingue) pour y prendre la partie correspondant à la langue indiquée ; l'intérêt d'effectuer cette opération au niveau SQL est essentiellement de demander simultanément un tri sur cette colonne.



Fonction
Arguments

sql_quote
valeur
serveur

sql_hex
valeur
serveur

sql_in
colonne
 valeurs
 vrai si négation souhaitée
serveur

sql_multi
colonne
 langue
serveur

sql_test_date
type
serveur

sql_test_int
type
serveur


Un groupe important est constitué par les fonctions manipulant les déclarations de bases et de tables. Pour des raisons historiques, cette première version de l'interface reprend quasi littéralement la syntaxe de MySQL3 et devra certainement être revue, en particulier pour y faire apparaître la déclaration des jointures. Les fonctions sql_create, sql_alter, sql_showtable et sql_drop_table permettent de créer, modifier, voir et supprimer une table.
Les fonctions sql_create_view, sql_drop_view permettent de créer ou supprimer une vue.
 Les fonctions sql_listdbs, sql_showbase et sql_selectdb permettent de voir les bases accessibles, de voir leur contenu et d'en sélectionner une. À noter que tous les hébergeurs n'autorisent pas forcément de telles actions ; SPIP essaiera de le deviner, en notant ses essais dans le fichier spip.log.



Fonction
Arguments

sql_create
nom de la table
 tableau nom de colonne => type SQL et valeur par défaut
 tableau nom d'index => colonne(s)
 vrai si auto-incrément
 vrai si temporaire
serveur

sql_alter
requête MYSQL Alter
serveur

sql_showtable
RegExp
 vrai si table déclarée par SPIP
serveur

sql_drop_table
nom de la table
 vrai s'il faut insérer la condition existe
serveur

sql_create_view
nom de la vue
requête de sélection de champs (créé par exemple avec sql_get_select)
serveur

sql_drop_view
nom de la vue
 vrai s'il faut insérer la condition existe
serveur

sql_listdbs


sql_selectdb
nom de la base
serveur

sql_showbase
RegExp
serveur


Deux fonctions permettent de régler le codage des caractères lors des communications avec le serveur :
- sql_set_charset, demande d'utiliser le codage indiqué ;
- sql_get_charset, demande si un codage de nom donné est disponible sur le serveur.



Fonction
Arguments

sql_get_charset
RegExp
serveur

sql_set_charset
codage
serveur


Un dernier groupe de fonctions offre quelques outils de gestion des requêtes et des tables ; on se reportera à leurs homonymes dans la documentation des serveurs SQL.
Signalons toutefois que sql_explain est utilisée implicitement par le débusqueur de SPIP, accessible par les boutons d'administration de l'espace public, lorsqu'on lui demande le plan de calcul d'une boucle (ou de tout un squelette).



Fonction
Arguments

sql_optimize
requête
serveur

sql_repair
table
serveur

sql_explain
requête
serveur

sql_error
requête
serveur

sql_errno


sql_version



Hors groupe, la fonction générale sql_query, nom qu'aurait dû porter l'historique spip_query ; leur utilisation est de toute façon à éviter.
Réalisation des portages
Cette section est destinée à ceux souhaitant porter SPIP sur d'autres serveurs SQL, ou ayant besoin d'informations plus techniques, notamment sur la gestion des versions de l'interface. 

Les fonctions du fichier ecrire/base/abstract_sql.php étudiées ci-dessus se contentent d'offrir une interface homogène aux différents serveurs, mais ne procèdent elles-mêmes à aucun calcul. 

C'est dans le fichier ecrire/base/connect_sql.php que se situe le travail effectif.
La fonction essentielle est spip_connect qui ouvre la connexion au serveur SQL indiqué par son argument (ou, s'il est omis, le serveur principal) en repérant les connexions déjà faites. Cette ouverture consiste à inclure un fichier de connexion créé lors de l'installation de SPIP par les scripts présents dans le répertoire install. Un fichier de connexion se réduit pour l'essentiel à appliquer la fonction spip_connect_db aux valeurs fournies lors de l'installation.
La fonction spip_connect_db reçoit en particulier comme argument le type du serveur SQL. Ce type doit être le nom d'un fichier présent dans le répertoire req.

Ce fichier est chargé et doit définir toutes les fonctions d'interfaces définies à la section précédente, plus la fonction req_type_dist qui sera immédiatement appliquée sur les mêmes arguments que spip_connect_db, type excepté. C'est cette fonction qui doit établir effectivement la connexion.
Porter SPIP sur d'autres serveurs SQL consiste donc à définir ce jeu de fonctions et à le placer dans le répertoire req.
Le gestionnaire de versions d'interface repose sur le deuxième argument de spip_connect qui indique la version, la version courante étant prise par défaut.

Toutes les fonctions de l'interface sont définies dans le fichier abstract_sql, se nomment sql_X et sont les seules à se nommer ainsi. 

Elles se connectent toutes en appelant une variante de spip_connect dont le premier argument est le numéro de version de l'interface. Au cas où le fichier abstract_sql nécessiterait une révision, il sera renommé abstract_sql_N, et le Sed suivant lui sera appliqué (N désigne le numéro de version) :
s/\(sql_[A-Za-z_0-9 ]*\)/\1_N/ 
En appliquant également ce script aux extensions de SPIP fondées sur cette version, on leur permettra d'en appeler ses fonctions, qui seront chargées sans collision de noms, le Sed ayant préfixé le nom des anciennes avec leur numéro de version. Il faudra juste rajouter une instruction include portant sur le fichier abstract_sql_N. 

Du côté du portage, il faudra renommer pareillement les fichiers du répertoire 

req, et écrire les nouvelles versions.
La coexistence de plusieurs versions de l'interface pendant l'exécution de SPIP repose sur la structure décrivant le serveur. Celle-ci est en fait un tableau, contenant :
- link, ressource indiquant la connexion ;

- db, nom de la base de données ;

- prefixe, nom du préfixe de table ;

- ldap, nom de l'éventuel fichier décrivant le serveur LDAP.
Les autres entrées sont les numéros de versions disponibles, et leur valeur est le tableau des fonctions implémentant cette version de l'interface.
Les autres fonctions du fichier connect_sqlconcernent essentiellement la gestion des versions et le traitement de quelques cas particuliers de déclarations des tables standards de SPIP.


Mutualisation du noyau SPIP
Committo, Ergo Sum., Matthieu Marcillaud — 2007-02-22T21:04:45Z
La mutualisation du noyau de SPIP est possible. Il s'agit de pouvoir gérer plusieurs sites SPIP sur un seul serveur ou hébergement en n'utilisant qu'une seule fois les fichiers du noyau de SPIP.
Cela permet un gain d'espace disque important, ainsi qu'une possibilité de mise à jour de SPIP simple de l'ensemble des sites en ne mettant à jour que le noyau.
		
Sommaire
 Le concept...
 Créer les bons répertoires
 Des redirections bien faites !
 Mutualiser selon l'URL grâce à mes_options.php
 Configurer apache pour les domaines et sous-domaines
 Note sur les sauvegardes et les restaurations
Cet article explique la procédure pour SPIP 1.9.2, sur des serveurs Apache [1] autorisant la réécriture d'url (url_rewriting). Pour les versions ultérieures de SPIP, voir plutôt l'article Ferme à SPIP.
Il y a plusieurs méthodes pour arriver aux mêmes résultats, selon que l'on souhaite configurer directement la mutualisation depuis un hébergement ou depuis un serveur.
Le concept...
Les dossiers nécessaires au fonctionnement du noyau SPIP (ecrire, plugins-dist, prive, squelettes-dist, ...), et ceux marquant l'activité d'un site (config, IMG, tmp, local) sont clairement identifiables et séparés. C'est cette séparation qui permet d'avoir plusieurs sites SPIP autonomes pour un même noyau de SPIP.
Cette autonomie repose sur l'existence d'un quatuor de répertoires par site, dans lesquels Spip va écrire les données résultant de l'activité du site. Ces répertoires sont au nombre de quatre, car on distingue les données temporaires et permanentes d'une part, et les données accessibles par http et celles qui ne le sont pas d'autre part, d'où quatre types de données. Les deux répertoires inaccessibles par http seront protégées par un .htaccess installé automatiquement par SPIP (les administrateurs du serveur pourront même mettre ces répertoires en dehors de l'arborescence servie par http).
Ces quatre répertoires sont distincts et nommés par les constantes PHP suivantes :
define('_NOM_TEMPORAIRES_INACCESSIBLES', "tmp/"); define('_NOM_TEMPORAIRES_ACCESSIBLES', "local/"); define('_NOM_PERMANENTS_INACCESSIBLES', "config/"); define('_NOM_PERMANENTS_ACCESSIBLES', "IMG/"); 
Dans une installation de Spip non mutualisée, ces répertoires sont créés à la racine du site, lors de l'application de la fonction spip_initialisation sur les quatre valeurs ci-dessus. Pour obtenir la mutualisation des sources de SPIP,

il suffit de savoir associer une URL spécifique à son quatuor de répertoires spécifiques, en appelant la fonction spip_initialisation sur quatre autres valeurs, déduites de l'URL.
Créer les bons répertoires
Pour démarrer la mutualisation, il faut tout d'abord partir d'un site fonctionnel. Pour les exemples, nous partirons d'un site appelé par l'url http://example.org/ stocké physiquement dans /home/toto/public_html/.
Il faut créer un répertoire (par exemple nommé 'sites') qui va contenir les répertoires des sites mutualisés, à la racine de la distribution (au même niveau que /ecrire).
- mutualisation d'un répertoire :

Si l'on souhaite que les adresses http://example.org/premier_site/ et http://example.org/deuxieme_site/ appellent chacun un site spip, il faut créer alors les sous-répertoires /premier_site et /deuxieme_site dans le répertoire /sites, puis dans chacun d'eux créer les répertoires /config, /IMG, /tmp, /local. Ces quatre répertoires doivent être accessibles en écriture. Il sera possible par la suite d'ajouter un répertoire /squelettes aussi, à côté de ces répertoires.
- mutualisation sous-domaine et domaine (quelques idées) :

Si l'on souhaite que l'adresse http://toto.example.org/, http://exemple.tld/ et http://utilisateur.example.com/ appellent chacun un site spip, on peut envisager de créer dans /sites les répertoires /toto, /exemple.tld, et /example.com/utilisateur
Remarque : Toutes les url doivent pointer à la racine de la distribution SPIP, c'est-à-dire dans /home/toto/public_html/. C'est le rôle que vont remplir soit un fichier .htaccess soit la configuration du serveur Apache expliqués plus loin.
Des redirections bien faites !
Pour que SPIP reconnaisse qu'un site est mutualisé, il faut que le script spip.php (appelé par index.php) soit executé. Celui-ci cherchera, grâce à un code ajouté dans /config/mes_options.php si l'URL appelée correspond à un site mutualisé ou non. Pour cela, il faut qu'une adresse http://example.org/premier_site/ ou http://example.org/deuxieme_site/ soit redirigée vers http://example.org/ pour executer alors index.php...
C'est le rôle attribué au fichier .htaccess (ou directement dans la configuration du serveur Apache)
Il faut copier et renommer le fichier htaccess.txt à la racine de la distribution en .htaccess, puis le modifier :
Pour autoriser la réécriture d'URL (rien ne change normalement) :

RewriteEngine On
Si la distribution SPIP est dans un sous-répertoire, modifier rewritebase. Ici, le site est à la racine donc :

RewriteBase /
Enfin, dans réglages personnalisés, ajouter le code suivant pour que les répertoires /premier_site , /deuxieme_site et /troisieme_site soient traités depuis la racine de la distribution :

#Mutualisation RewriteRule ^(premier_site|deuxieme_site|troisieme_site)$ /$1/ [R,L] RewriteRule ^(premier_site|deuxieme_site|troisieme_site)/(.*) /$2 [QSA,L]
Le premier rewriterule redirige les adresses http://example.org/premier_site vers http://example.org/premier_site{{/. Le deuxième redirige tout ce qu'il y a derrière /premier_site/ à la racine, par exemple : http://example.org/premier_site/article112 est redirigé vers http://example.org/article112. (Cependant, cette redirection est transparente, le nom de l'url ne change pas, il est toujours http://example.org/premier_site/article112, même et surtout pour php !)
Et si SPIP est dans un sous répertoire ?
Dans ce cas là, les fichiers de spip se trouvent dans /home/toto/public_html/spip/ , SPIP est appelé par http://example.org/spip/, les sites mutualisés par http://example.org/spip/premier_site/ ou http://example.org/spip/deuxieme_site/.
Il faut alors mettre dans le .htaccess :
RewriteEngine On RewriteBase /spip/ #Mutualisation RewriteRule ^(premier_site|deuxieme_site|troisieme_site)$ /spip/$1/ [R,L] RewriteRule ^(premier_site|deuxieme_site|troisieme_site)/(.*) /spip/$2 [QSA,L] 
Et pour rediriger tous les répertoires comme des sites mutualisés ?
Il vous est possible à la place des rewriterules ci-dessus 

d'utiliser un code générique, utilisable quelque-soit le nom du 

répertoire du site mutualisé :
- à la racine
RewriteCond %{REQUEST_URI} !^/(config|squelettes-dist|ecrire|IMG|oo|plugins|sites|squelettes|tmp|local)/(.*) RewriteRule ^[^/]+/(.*) /$1 [QSA,L] 
- ou dans un dossier /spip :
RewriteCond %{REQUEST_URI} !^/spip/(config|squelettes-dist|ecrire|IMG|oo|plugins|sites|squelettes|tmp|local)/(.*) RewriteRule ^[^/]+/(.*) /spip/$1 [QSA,L] 
Et pour les domaines et sous domaines ?
Par un heureux hasard, il n'y a rien à faire ici puisqu'ils pointent normalement déjà vers la racine de la distribution SPIP...
Mutualiser selon l'URL grâce à mes_options.php
C'est le fichier /config/mes_options.php à la racine de la distribution qui va réaliser la majeure partie du travail : il doit chercher si une URL est à mutualiser ou non, et initialiser SPIP en fonction.
De nombreux cas peuvent se présenter, entre les répertoires, les domaines et sous domaines. PHP peut utiliser deux variables pour tester les URLs qui ont appelé le script : 

$_SERVER['REQUEST_URI']; // contient tout ce qu'il y a derrière le nom de domaine : /premier_site/article112 par exemple... $_SERVER['SERVER_NAME']; // contient le nom du domaine et sous domaine : utilisateur.example.org par exemple
Ce sont ces deux variables qui vont être comparées à une expression régulière pour extraire le nom du répertoire qui contient la mutualisation.
Un moyen simple de mutualiser tous les répertoires est de copier le code suivant :
 
La ligne preg_match récupère le nom d'un dossier dans l'arborescence de l'URL, par exemple 'premier_site' dans http://example.org/premier_site/ ... Puis le script tente une mutualisation si le répertoire /sites/premier_site/ existe.
Si SPIP est dans un répertoire /spip, il faut modifier la première ligne par :

if (preg_match(',/spip/([a-zA-Z0-9_-]+)/?,', $_SERVER['REQUEST_URI'], $r)) {
Il faut dire dire à SPIP quel est le préfixe de table de base de données utilisé, ce que fait $cookie_prefix = $table_prefix = $r[1];

Cette ligne va créer des tables MySQL avec des préfixes ayant le nom du répertoire contenant le site : mon_site_article à la place de spip_article par exemple. Cela permet d'héberger tous les sites sur une seule et même base de données. Vous pouvez garder le préfixe par défaut (spip), mais il faut penser à avoir plusieurs bases de données différentes pour chaque site. 

Pour cela, mettre à la place :
$cookie_prefix = $r[1]; $table_prefix='spip'; 
La fonction spip_initialisation admet quatre paramètres qui sont l'adresse de chacun des répertoires nécessaires au fonctionnement du site mutualisé.
$GLOBALS['dossier_squelettes'] = $e.'squelettes'; définit l'emplacement du dossier squelettes du site mutualisé.
Enfin les dernières lignes chargent un éventuel sites/premier_site/config/mes_options.php.
Information :
Toute modification du fichier config/mes_options.php du noyau SPIP affectera les options de tous les sites hébergés.
Par exemple, mettre dans ce fichier :

$type_urls = 'propres' ;
Donnera par défaut à tous les sites ce type d'url... Mais chaque site peut le changer dans son propre /sites/mon_site/config/mes_options.php.
Configurer apache pour les domaines et sous-domaines
La mutualisation côté serveur, pour ce qui concerne la gestion des sous-domaines ou des domaines reste simple, mais nécessite de créer quelques redirections d'URL dans la configuration du serveur Apache pour tenir compte de ces sites.
Voici un exemple de configuration pour un serveur nommé 'exemple.tld' (ici un SPIP mutualisé) utilisant des sous-domaines (SPIP appelé par http://utilisateur.example.org/spip/).
Le noyau SPIP est dans '/home/toto/public_html/spip/'.
Il faut alors créer les répertoires /sites/exemple.tld/ , /sites/exemple.tld/utilisteur/.
Le fichier de configuration se situe dans Apache 2/linux dans /etc/apache2/sites_availables/default (vous pouvez aussi créer un nouveau fichier dans le dossier sites_availables et l'activer).
# SERVEUR exemple.tld # SPIP par sous domaine...  ServerName exemple.tld ServerAlias *.exemple.tld # Redirection vers le SPIP noyau DocumentRoot "/home/toto/public_html"  AllowOverride All Order allow,deny Allow from all  # Seule l'adresse http://utilisateur.exemple.tld/spip/* doit être redirigée # (utilisateur.exemple.tld/spip/* -> /home/toto/public_html/*) RewriteCond %{SERVER_NAME} (www\.)?([^.]+)\.example\.net$ RewriteRule ^/spip/(.*) /home/toto/public_html/spip/$1 [QSA,L] # (utilisateur.exemple.tld/* -> /home/toto/public_html/sites/exemple.tld/utilisateur/*) RewriteCond %{SERVER_NAME} (www\.)?([^.]+)\.example\.net$ RewriteRule (.*) /home/toto/public_html/sites/exemple.tld/%1/$1 [QSA,L]  
Il est par contre nécessaire de tester ces mutualisations possibles dans /config/mes_options.php :
 
Note sur les sauvegardes et les restaurations
Chaque site copie ses fichiers de sauvegardes dans le répertoire

/sites/premier_site/tmp/dump (ou /sites/premier_site/tmp/upload/login pour les sauvegardes d'un administrateur restreint).

Les restaurations se font par le même dossier.
Attention :
A l'heure actuelle, SPIP enregistre dans la base de données, pour ce qui concerne le dossier /IMG des sites mutualisés une adresse sites/premier_site/IMG/* au lieu de IMG/* comme pour un site SPIP seul.
Une restauration ne fonctionnera donc que si elle s'effectue dans le site qui a créé la sauvegarde.
Une astuce pour restaurer le site ailleurs consiste à éditer le fichier dump.xml et à remplacer toutes les occurrences (à l'exception de celles des déclarations dir_img et dir_logo dans l'ouverture de la balise spip) :

- sites/premier_site/IMG/
 par (SPIP seul) : IMG/
 ou (SPIP mutualisé) : sites/mon_nouveau_site/IMG/
Inversement, pour passer un SPIP seul dans un répertoire mutualisé, il faut remplacer toutes les occurrences de :

- IMG/

- par : sites/mon_site/IMG/
		
		
[1] Pour information : ces procédures ont été testées avec Apache 2.0.55 et PHP 5.1.2 sur serveur Ubuntu Dapper Drake ainsi que sur PHP 5.1.6 sur serveur Ubuntu Edgy Eft

Fonction	Arguments
sql_select	liste des champs : chaîne ou tableau liste des tables : chaîne ou tableau clause Where : chaîne ou tableau clause Groupby : chaîne avec virgule séparatrice ou tableau clause Orderby : chaîne avec virgule séparatrice ou tableau clause Limit : un ou deux entiers séparés par des virgules clause Having : chaîne ou tableau serveur
sql_fetch	ressource serveur
sql_free	ressource serveur
sql_count	ressource serveur
sql_countsel	liste des tables : chaîne ou tableau clause Where : chaîne ou tableau clause Groupby : chaîne ou tableau clause Orderby : chaîne avec virgule séparatrice ou tableau clause Limit : un ou deux entiers séparés par des virgules clause Having : chaîne ou tableau serveur
sql_fetsel	liste des champs : chaîne ou tableau liste des tables : chaîne ou tableau clause Where : chaîne ou tableau clause Groupby : chaîne avec virgule séparatrice ou tableau clause Orderby : chaîne avec virgule séparatrice ou tableau clause Limit : un ou deux entiers séparés par des virgules clause Having : chaîne ou tableau serveur
sql_allfetsel	liste des champs : chaîne ou tableau liste des tables : chaîne ou tableau clause Where : chaîne ou tableau clause Groupby : chaîne avec virgule séparatrice ou tableau clause Orderby : chaîne avec virgule séparatrice ou tableau clause Limit : un ou deux entiers séparés par des virgules clause Having : chaîne ou tableau serveur
sql_getfetsel	nom d'un champ : chaîne liste des tables : chaîne ou tableau clause Where : chaîne ou tableau clause Groupby : chaîne ou tableau clause Orderby : chaîne avec virgule séparatrice ou tableau clause Limit : un ou deux entiers séparés par des virgules clause Having : chaîne ou tableau serveur
sql_get_select	liste des champs : chaîne ou tableau liste des tables : chaîne ou tableau clause Where : chaîne ou tableau clause Groupby : chaîne avec virgule séparatrice ou tableau clause Orderby : chaîne avec virgule séparatrice ou tableau clause Limit : un ou deux entiers séparés par des virgules clause Having : chaîne ou tableau serveur

Fonction	Arguments
sql_updateq	table tableau champ=>valeur à citer clause Where description serveur
sql_update	table tableau champ=>valeur clause Where description serveur
sql_insertq	table tableau champ=>valeur à citer description serveur
sql_insertq_multi	table tableau de tableau champ=>valeur à citer description serveur
sql_replace	table tableau champ=>valeur à citer description serveur
sql_replace_multi	table tableau de tableau champ=>valeur à citer description serveur
sql_delete	table clause Where serveur

Fonction	Arguments
sql_quote	valeur serveur
sql_hex	valeur serveur
sql_in	colonne valeurs vrai si négation souhaitée serveur
sql_multi	colonne langue serveur
sql_test_date	type serveur
sql_test_int	type serveur

Fonction	Arguments
sql_create	nom de la table tableau nom de colonne => type SQL et valeur par défaut tableau nom d'index => colonne(s) vrai si auto-incrément vrai si temporaire serveur
sql_alter	requête MYSQL Alter serveur
sql_showtable	RegExp vrai si table déclarée par SPIP serveur
sql_drop_table	nom de la table vrai s'il faut insérer la condition existe serveur
sql_create_view	nom de la vue requête de sélection de champs (créé par exemple avec `sql_get_select`) serveur
sql_drop_view	nom de la vue vrai s'il faut insérer la condition existe serveur
sql_listdbs
sql_selectdb	nom de la base serveur
sql_showbase	RegExp serveur

Fonction	Arguments
sql_get_charset	RegExp serveur
sql_set_charset	codage serveur

Fonction	Arguments
sql_optimize	requête serveur
sql_repair	table serveur
sql_explain	requête serveur
sql_error	requête serveur
sql_errno
sql_version