Les bases de dades a SPIP

Instal·lació mínima

Heu aquí en primer lloc tots els escenaris possibles d’instal·lació d’SPIP amb una única base.

Durant la instal·lació d’SPIP, aquest testeja la configuració de PHP i proposa, quan és possible, una elecció entre diversos tipus de servidors SQL (actualment MySQL, PostgreSQL o SQLite), que ofereixen tots les mateixes funcionalitats. En aquest estadi, fa falta també proporcionar l’adreça Internet del servidor SQL, un identificador de connexió a aquest servidor i la contrasenya associada. Aquestes informacions s’han d’introduir generalment al formulari d’instal·lació. No obstant, si voleu aplicar el Compartir el nucli SPIP, podeu indicar un o diversos d’aquests valors al fitxer de configuració mes_options.php. SPIP no els demanarà llavors, cosa que dispensa d’introduir-los i no us obliga a comunicar-los a aquells que utilitzaran la vostra instal·lació mutualitzada. Heus aquí els noms de constants PHP a definir per això:

SPIP es connecta llavors al servidor escollit, amb els identificadors de connexió. En cas d’èxit, prova si l’usuari té el dret de crear bases, o només el dret de veure les que se li presenten i escollir-ne una, veure només té el dret d’utilitzar una base homònima del seu nom d’usuari. Podeu també fixar anticipadament al fitxer mes_options.php el nom de la base de dades a fer servir, definint la constant PHP:

SPIP prossegueix llavors la instal·lació creant les seves taules SQL (o, en cas de reinstal·lació, verificant que les presentades són utilitzables). Aquestes taules comencen totes per un préfix de taula (que val per defecte spip_) i pot ser indicat a mes_options.php de dues maneres:

Aquest prefix de taula és el que permet escriure bucles abreujats als esquelets, com <BOUCLE1(ARTICLES)....

mentre que el nom SQL de la taula és de fet spip_articles.

SPIP sol·licita a continuacuí crear el primer usuari del lloc proporcionant un nom i una contrasenya (sans relació amb els del servidor SQL) o proposant delegar el servei d’autenticació a un servidor LDAP. Després d’aquesta declaració, el procediment mínim d’instal·lació s’ha acabat, i la pàgina següent és l’habitual pàgina d’entrada a l’espai de redacció, que demana els identificadors que acaben de ser entrats. Aquests han estat preservats en un fitxer que, per defecte, és config/connect.php.

Complements d’instal·lació

Heus aquí ara com indicar a SPIP diverses bases a utilitzar, sota el mateix servidor o sota servidors diferents, i també en màquines diferents.

Un cop intal·lat el lloc, escollir el submenú manteniment del lloc que es troba en el menú configuració al capdamunt de l’espai privat. Aquest menú subministra una pàgina amb tres pestanyes; cliqueu damunt del de la dreta, anomenat declarar una altra base. S’accedeix llabors a un formulari gairebé idèntic al formulari d’instal·lació: proposa indicar un tipus de servidor SQL, la seva adreça Internet, un nom d’usuari i la seva contrasenya. En cas de connexió reeixida, SPIP demanarà subministrar el nom d’una base, llistant aquelles que són presents si en té la possibilitat. Si existeix bé, crearà un fitxer de connexió suplementari, que per defecte es troba al directori config i porta el nom de la base de dades indicada.

Fet això, SPIP torna novament cap a aquest formulari, i llista els fitxers de connexió presents, dit d’una alta manera les bases accessibles. SPIP proposa per tant declarar encara una base suplementària: no hi ha limitació en el número de bases declarades.

L’interès d’aquestes declaracions és poder aplicar la notació dels esquelets de compaginació a aquestes bases suplementàries. Si existeix un fitxer de connexió anomenat B.php, que permeti interrogar una base que posseeixi una taula anomenada T, llavors l’esquelet

<BOUCLE1(B:T)></BOUCLE1>#TOTAL_BOUCLE<//B1>

donarà el número de línies d’aquesta taula. A més, SPIP demana al servidor SQL que li descrigui aquesta taula, cosa que li permet conèixer els seus camps i, eventualment, la seva clau primària. Si el bucle T té una clau primària anomenada id i un camp anomenat nom, llavors l’esquelet:

<BOUCLE1(B:T){id}>#NOM</BOUCLE1>

donarà el camp nom de lla única línia que té l’id donat pel context.

Finalment, es possible aplicar un esquelet demanant que tots els seus bucles utilitzin una altra base que la que existeix per defecte, afegint a l’URL de la pàgina el paràmetre connect indicant el nom de la base. Per exemple http://monsite?connect=autre_site aplicarà l’esquelet sommaire estàndard del lloc monsite a la base indicada pel fitxer de connexió config/autre_site.php en el directori d’instal·lació de mon_site.

Es recomana respectar la caixa del nom del fitxer de connexió, quan s’utilitza a dins d’un bucle o com a paràmetre de connect: SPIP no efectua cap conversió majúscules / minúscules (però alguns sistemes de fitxers ho fan).

Nota: L’accés a bases de dades suplementàries és només de lectura; en particular, si una base és, per exemple, un fòrum (administrat per SPIP o no) resulta impossible posar un post en aquest fòrum a no ser que sigui a partir del seu lloc d’origen. L’aixecament d’aquesta restricció es troba en estudi.

Instal·lacions creuades

Els extractes d’esquelet de més amunt reposen, per tant, en l’existència d’un fitxer de connexió anomenat B.php. Un punt important és que el fitxer de connexió principal i els de les bases suplementàries tenen el mateix format, el que permet en particular a un lloc SPIP utilitzar directament el fitxer de connexió d’’un altre lloc SPIP per explotar les seves taules. Une manera de procedir és copiant el fitxer connect.php del lloc B amb el nom B.php a dins del directori config del lloc A.

Una manera més enginyosa, en el cas dels llocs que comparteixen una mateixa instal·lació d’SPIP, és tenir un únic directori config per tots els llocs, i d’anomenar-hi el fitxer de connexió del lloc A no com a connect.php sinó com A.php, de la mateixa manera pel lloc B etc. D’aquesta manera, des que un lloc està instal·lat sota SPIP, és conegut com a base suplementària de tots els altres llocs que comparteixen aquesta instal·lació d’SPIP, i veurà tots els altres llocs utilitzant el mateix directori config que ell com tantes bases suplementàries. Per obtenir aquesta optimització en les declaracions implícites, és necessari definir curosament les constants _DIR_CONFIG i _FILE_CONNECT_INS. Trobarem més avall un exemple de mutualització que ofereix aquesta funcionalitat i algunes altres.

Per un lloc instal·lat en un servidor SQL allunyat, la còpia del seu fitxer de connexió al lloc local pot ser suficient en teoria. No obstant, molts hostatjadors refusen que els seus servidors SQL siguin interrogats per màquines que es trobin fora de la seva xarxa local. També fa falta pensar que sovint el «nom» indicat pel servidor SQL en el moment de l’instal·lació és localhost, que és una adreça relativa al servidor HTTP, mentre que aquí ha sigut necessari una adreça absoluta. En breu, En resum, SPIP pot operar en una arquitectura com aquesta, però un mínim de coneixements, veure autorització d’intervenció, sobre la topografia de sub-xarxes en joc és pràcticament indispensable.

Les bases suplementàries sota SPIP

Quan un fitxer de connexió és el d’un altre lloc sota SPIP (sigui una còpia o l’original accessible per instal·lacions creuades), conté la indicació que aquest lloc és sota SPIP (la global spip_connect_version hi està afectada). En aquest cas, els esquelets del lloc principal s’aplicaran amb un comportament especial:

-  els bucles amb nom abreujat seran interpretats com abreujats també a la base suplementari; dit d’una altra manera, <BOUCLE1(B:ARTICLES)... (o <BOUCLE1(ARTICLES)... amb un URL que comporti connect=B.) referenciarà la taula spip_articles a la base B, més concretament la taula prefixearticles o prefixe és la utilitzada pel lloc B (aquest prefix es troba indicat en el fitxer de connexió);

-  a l’interior d’un bucle, les etiquetes #URL_ (veure Utilitzar URLs personalitzats) utilitzaran el $type_urls del lloc principal, i no el del lloc distant, i l’URL produïda referenciarà el lloc principal però afegint la variable d’URL connect=site_distant; aquesta estratègia permet, per tant, navegar a la bas del lloc distant sense deixar d’utilitzar els esquelets del lloc principal, dit d’una altra manera, provar l’aparença que dóna aquest joc d’esquelets i el seu $type_urls a la base distant sense modificar-ne la instal·lació d’aquest o havent de treballar en una còpia.

-  Les dreceres SPIP de les etiquetes #URL que poden figurar en els camps de la base de dades distant són elles també interpretades d’aquesta manera: [->art3681] referenciarà bé l’article 3681 de la base distant, però per mitjà d’un URL que proporcionarà la compaginació per part dels esquelets del lloc principal.

Aquesta manera de funcionar permet, per tant, presentar altres bases SPIP sense haver d’escriure esquelets de compaginació, ja que els noms de les taules a dins d’aquests són els mateixos que els del lloc distant. Per contra, una base que no estigui sota SPIP necessitarà esquelets de compaginació que anomenin explícitament les taules d’aquesta altre base i els seus camps. Per tal de respondre a aquesta necessitat, els adminsitradors del lloc es beneficien d’un tractament especial: quan donen al seu navegador l’URL del seu lloc seguit de ?page=table:taula o taula és el nom d’una taula de la base, SPIP construirà automàticament un esquelet específic per aquesta taula, permetent examinar-ne el contingut amb una gran ergonomia. L’esquelet produït és visible a través de l’enllaç esquelet al capdavall de la pàgina. Llavors és possible copiar-lo amb el ratolí (clicar al capdamunt de la columna per amagar la numeració de línies) i millorar-lo tot treballant amb un editor apropiat.

A tenir en compte que amb aquesta producció automàtica, SPIP podria, anant al límit, funcionar sense cap esquelet definit prèviament.

Salvaguardes i Fusions

Amb el submenú manteniment del lloc, SPIP dóna accés des de sempre a dues eines de salvaguarda i restauració de la base de dades local (veure Fer una còpia de seguretat de les vostres dades). A partir d’SPIP 2.0, es possible instal·lar una salvaguarda resultant d’un lloc antic, en una instal·lació SPIP de número de versió superior; no obstant, aquest cas exigeix un espai de memòria que no sempre es té disponible, per tant sempre s’aconsella provar d’actualitzar el lloc original, després fer-ne la salvaguarda, i finalment fer-la rellegir per lloc nou.

D’altra banda, fins a la versió 1.8, una salvaguarda era total, i la restauració també. Després d’alguns assajos fonamentats en l’estatus d’administrador restringit, que s’han manifestat finalment incòmodes, SPIP 2.0 ofereix una nova funcionalitat més harmoniosa de salvaguarda parcial i de restauració per fusió.

El formulari de salvaguarda proposa limitar la salvaguarda a una secció determinada. El fitxer produït contindrà els articles, llocs, breus i subseccions continguts a dins de la secció indicada, així com les paraules clau i grups de paraules clau per totes aquestes dades. El nom de la salvaguarda serà, per defecte, el nom de la secció, però això es pot canviar. La creació de fitxers de salvaguarda pot ser tan llarg que el servidor HTTP us pot desconnectar com a conseqüència d’inactivitat aparent. Simplement tornar a carregar la pàgina: SPIP tornarà a trobar a quin indret estava i continuarà el seu treball. El gran nombre de fitxers que podreu temporalment veure en un subdirectori del directori tmp és normal, ja que va lligat a l’anticipació d’aquesta situació de represa després de la desconnexió.

Simètricament, el formulari de restauració proposa actualment dues funcionalitats. La primera, és l’habitual substitució de la base actual per la base salvaguardada. La segona, consisteix en considerar el fitxer de salvaguarda com una base incompleta que s’acaba d’afegir a la base ja instal·lada. Com que hi pot haver conflicte entre la base instal·lada i la base incompleta en allò que fa referència a la numeració de les seves pàgines (d’articles, de breus etc), SPIP comença per tornar a enumerar els elements de la base incompleta donant-los-hi números immediatament superior als màxims de la base instal·lada. En un segon pas, SPIP importa efectivament els elements tornats a enumerar, però després de la primera passada, compara els elements que s’han d’importar amb els de la base instal·lada i ignora els duplicats definits segons les següents regles:

-  si existeix a la base isntal·lada un grup de paraules clau amb el mateix nom que un grup de paraules clau que s’han d’importar, aquest grup s’ignora;

-  si una paraula clau de la que el grup de paraules clau no s’ha importat posseeix un homònim a dins d’un grup de paraules clau que porten el mateix nom que seu grup d’origen, aquest molt clau és ignorat;

-  si existeix a dins de la base instal·lada una secció del sector que porta el mateix nom que una secció del sector a importar, aquesta secció s’ignora;

-  si una subsecció, la secció parenta de la qual no s’han importat, posseeix un homònim del mateix parentiu, aquesta subsecció s’ignora; passa el mateix pel que fa referència als articles, les breus i els llocs referenciats;

-  si existeix a la base instal·lada un document que porti el mateix nom que un document a importar i que tenen la mateixa mida, aquest document s’ignora.

Dit de manera més sintètica, l’operació de fusió és la unió de dues bases, tenint prioritat el contingut de la base instal·lada sobre la base importada en tot allò que fa referència als duplicats (per exemple, per dos sectors que tinguin el mateix nom, els camps text i descripció del que ja està instal·lat es conservaran mentre que els altres seran ignorats).

En allò que fa referència als documents adjunts, aquests seran importats com a documents distants, cosa que dispensa inventariar i copiar la part de directori IMG/ afectat per la salvaguarda parcial. A continuació es pot utilitzar, a cada document, el botó de còpia local per alliberar-se del lloc d’origen. Si aquest ja ha desaparegut o posseeix restriccions d’accés no esquivables pel lloc receptor, serà necessari instal·lar aquest directori IMG/ original a un URL accessible, i marcar la última casella d’introducció del formulari d’importació.

Veurem també la possibilitat de canviar l’estat del valor publicat al valor proposat, cosa que permet mantenir una política de publicació cas per cas, malgrat aquesta importació massiva.

Un exemple complet

La instal·lació mutualitzada d’SPIP de més avall permet tenir un sol directori de configuració (_DIR_CONNECT) i un únic de salvaguardes (_DIR_DUMP). Cada lloc també pot donar idees sobre la bas de cadascun dels altres, i utilitzar les seves salvaguardes per fusionar-les amb la seva pròpia base. Només s’utilitza un únic directori per la memòria cau de l’ajuda en línia (_DIR_AIDE) ja que SPIP l’importe un rere l’altre a partir d’un servidor spipnet, i un únic directori pels Document Type Definitions que El validador XML integrat va a buscar al lloc del W3C i altres (_DIR_XML).

Els fitxers de drets i de registre es reuneixen igualment en dos directoris (_DIR_CHMOD i _DIR_LOG).

Per tant, seran creats a l’arrel config/connect, config/chmod, tmp/log, tmp/dump, tmp/xml i tmp/aide. El primer contindrà A.php per a la connexió a 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);
	}
)