SPIP 2.0

SPIP et la publication Web

SPIP est un système de création et de gestion de sites Web muni d’une interface induisant des structures éditoriales fiables, c’est-à-dire pérennes et évolutives [1]. Après son installation par la seule saisie de cinq formulaires Web, il est immédiatement prêt à l’emploi, et permet de faire vivre, seul ou avec une équipe de rédacteurs, un site Web doté des meilleures technologies du moment.

Pour SPIP 2.0, l’interface et l’ergonomie ont été enrichies, les normes XHTML et CSS sont mieux respectées, les interactions avec le système ont été accélérées, notamment par l’utilisation systématique d’AJAX [2]. L’ajout de documents de divers types a été unifié, tout en en permettant une utilisation diversifiée. Ces « lissages » progressifs font que les nouveaux utilisateurs bénéficient d’une interface éprouvée, et les anciens préservent leurs (bonnes) habitudes.

-  Jeux d’URLs symboliques

De nouvelles URLs dites propres permettent d’avoir plusieurs noms d’URL associés à un même objet, donc en particulier de modifier le titre d’un article, ce qui créera la nouvelle URL sans invalider la précédente. En outre, un client HTTP demandant celle-ci sera définitivement redirigé vers la nouvelle.

Ces URLs sont à présent gérées dans une table SQL séparée dont elles sont la clé primaire, ce qui accélère leur emploi. La compatibilité avec les anciennes URLs propres est assurée lors de la mise à jour du site.

Ces nouvelles URLs sont la finalisation du travail pionnier effectué par feu Toggg (http://web.archive.org/web/20070309220121/toggg.com/spip/spip.php?article19 et http://web.archive.org/web/20070309220112/toggg.com/spip/spip.php?article18) à la mémoire de qui cette nouvelle version de SPIP est dédiée (http://contrib.spip.net/Adieu-l-ami).

Un nouveau jeu d’URLs, nommé arbo, a également été introduit, offrant une notation arborescente, comme : http://www.monsite.com/secteur/rubrique1/rubrique2/article

Enfin, un simple clic dans un tableau affiché par les pages d’administration permet à présent de choisir le jeu d’URLs. L’ancienne méthode utilisant la variable globale PHP $type_urls fonctionne toujours, mais il est conseillé d’évacuer cette variable de votre fichier mes_options.php, afin de voir apparaître ce tableau de configuration. Si vous avez un jeu d’URLs personnel dans le répertoire urls de votre SPIP_PATH, il apparaîtra automatiquement dans ce tableau.

-  Incrustation dans les textes de média divers

Les modèles img et emb permettant d’incruster un document dans le corps d’un texte ont été totalement repensés. Ils s’appuient à présent sur la nomenclature officielle des types MIME, en utilisant des filtres homonymes de ceux-ci. Cette architecture permet de régler très finement l’incrustation d’un document de tout type ; elle est décrite dans article 3715 qui complète l’article Utiliser les modèles écrit lors de la sortie de SPIP 1.9.1.

Les rédacteurs peuvent ainsi incruster un plus grand nombre de types de documents qu’auparavant. C’est ainsi que SPIP présente automatiquement en HTML le contenu d’un fichier CSV issu d’un tableur. De même, un fichier txt sera ainsi incrusté après transcodage des chevrons et placement dans une balise pre afin d’apparaître verbatim. Enfin, pour un document HTML, ses feuilles de styles seront automatiquement importées, ce qui permet en particulier de facilement transformer un site statique en un site sous SPIP.

-  Envoi de documents dans les forums

Une nouvelle option permet d’autoriser les visiteurs a poster des documents dans les forums ; évidemment ce n’est pas activé par défaut.

L’option se règle en listant les extensions de fichier acceptées, par exemple « gif,png,jpg,mp3 », le signe * indiquant que tout type de documents est accepté, hormis ceux présentant des trous de sécurité potentiels.

-  Nombreuses fonctionnalités nouvelles autour des pétitions

Beaucoup de nouveautés décrites dans Les pétitions sous SPIP : recherche et tris multiples des signataires, pagination, flux RSS, statistiques journalières et mensuelles, interface pour tableur, pétitions multilingues.

-  Gestion des éditions concurrentes

L’espace privé de SPIP gère les conflits d’édition concurrente des articles, rubriques, brèves, mots-clés, auteurs et sites.

Le scénario est le suivant : supposons que Alice et Bob ouvrent en même temps le même article en édition ; ensuite chacun renvoie ses modifications, d’abord Alice, puis Bob.

Les situations sont diverses :

• Alice a modifié le titre, Bob le texte : on accepte les deux modifications, le titre de Bob (inchangé) n’écrase pas le titre d’Alice ;
• Alice modifie le titre, Bob lui aussi :
  • soit ils ont mis le même titre : pas de problème ;
  • soit le titre diffère : on prévient Bob, on lui montre le titre qu’il vient d’envoyer, celui qui est stocké dans la base, la différence entre les deux, et un formulaire pour copier/coller ses modifications. Le titre envoyé n’est pas enregistré dans la base.

Ces éléments sont traités champ par champ indépendamment : ainsi s’il y a conflit sur le titre mais pas sur le chapeau, celui-ci est enregistré, et le message d’erreur ne porte que sur le titre.

-  Faciliter l’utilisation des plugins

— Installations manuelle et/ou automatique

Les plugins s’installent dans un dossier /plugins. En créant un sous-dossier /plugins/auto, on active l’installation automatique de plugins.

Il est possible d’ajouter, via l’installation automatique :

• des plugins individuels, en indiquant l’URL d’un fichier Zip,
• des listes de plugins répertoriés dans un flux RSS.

— Trouver des plugins

Trois espaces permettent aux utilisateurs de trouver des plugins selon différentes orientations (développeurs, contributif, référencement) :

• tous les plugins développés sur la Zone peuvent apparaître, à l’initiative de leurs auteurs, dans le répertoire http://files.spip.org/spip-zone/ ;
• SPIP-Contrib évolue pour améliorer la recherche de plugins ;
• lancé à l’occasion de cette nouvelle mouture de SPIP, le site Plugins.spip propose un référencement plus fin, par thème, par compatibilité de version SPIP, par langues...

Les sites Plugins.spip et SPIP-contrib proposent des flux RSS directement utilisables pour l’installation automatique de plugins compatibles avec SPIP 2.0.

-  Accès à plusieurs bases et serveurs, fusion partielle et squelettes automatiques

SPIP est à présent disponible non seulement à travers un serveur MySQL mais aussi à travers un serveur PostGreSQL et à travers les extensions SQLite 2 et 3 de PHP. Le choix est proposé en début d’installation puis mémorisé dans le fichier de connexion. A noter que le format des sauvegardes est commun à toutes les versions, de sorte qu’il est possible de revenir sur le choix initial en restaurant une sauvegarde après réinstallation de SPIP sous un autre serveur SQL.

Cette nouvelle portabilité de SPIP a permis de stabiliser une fonctionnalité jusqu’à présent lacunaire, savoir l’utilisation des squelettes sur plusieurs bases SQL à la fois.

Un formulaire comparable à celui d’installation, accessible dans le menu maintenance du site, permet de déclarer ses identifiants de connexion à une autre base, et produit un fichier de connexion semblable à celui du site principal, suffisant pour utiliser cette base. Dans le cas d’une base créée par un autre site sous SPIP, cette déclaration peut se réduire à un simple copie de son fichier de connexion.

Cette déclaration faite, on peut appliquer les squelettes du site appelant sur les tables d’un autre site, simplement en rajoutant dans l’URL du site appelant un paramètre supplémentaire, connect, avec comme valeur le nom de son fichier de connexion (sans l’extension .php). On peut aussi mêler dans un même squelette des boucles sur des bases différentes, SPIP ouvrant autant de connexions et passant de l’une à l’autre quand nécessaire. À noter que ces bases peuvent être gérées par d’autres implémentations SQL que celle du site principal, SPIP jouant donc un rôle d’agrégateur d’extraits de plusieurs bases.

Pour permettre d’explorer rapidement les tables d’une base, un mécanisme de création automatique d’un squelette se déclenche lorsque la valeur du paramètre d’URL page est de la forme table:la table.

Ce vertébreur visualise le contenu de la table selon plusieurs modes de navigation, et permet de sauvegarder le squelette créé.

Il est ainsi facile de développer un utilitaire de gestion de bases de données avec SPIP, donc éventuellement multi-serveurs.

Pour des raisons de confidentialité, ce mécanisme n’est accessible qu’au webmestre principal mais peut être plus ouvert en surchargeant la fonction autoriser_webmestre.

Autre fonctionnalité stabilisée à l’occasion du portage multi-serveurs : la sauvegarde d’une partie seulement de la base, et sa fusion ultérieure avec la base d’un autre site.

Une présentation synthétique des fonctionnalités sur les bases SQL sont décrites dans un article complet : Les bases de données en SPIP. Il propose en particulier un nommage des fichiers de connexion tel que toutes les bases des sites installés se connaissent les une les autres sans aucune déclaration supplémentaire.

-  Mutualisation des sources

La Mutualisation du noyau SPIP, proposée depuis SPIP 1.9, s’applique à présent quels que soient les répertoires de données de SPIP, la limitation sur le chemin du répertoire IMG ayant été levée.

La mutualisation est recommandée aux webmestres administrant plusieurs sites, afin de leur faciliter leur tâches de maintenance. Elle leur assurera aussi un maximum de confort s’ils veulent profiter du multi-bases, décrit ailleurs dans cet article.

Nous invitons également tous les hébergeurs à investiguer cette fonctionnalité, car ils pourront ainsi considérablement économiser de la place disque et diminuer globalement le nombre de chargements des multiples copies de SPIP pouvant exister sur leurs serveurs. Plusieurs extensions réalisant automatiquement de telles configurations ont été développées, voir la rubrique Mutualisation de SPIP-Contrib. Dans cette configuration, SPIP agit comme une ferme à blog ou comme un serveur de CMS.

SPIP et le design Web

-  Squelettes fondés sur des CSS LayoutGala

SPIP fournit à la fois des squelettes standards structurés qui utilisent les méthodes modernes et des outils destinés aux webmestres (le langage des boucles, balises et critères et filtres) qui leur permettent de personnaliser progressivement leur site en dépassant l’utilisation des squelettes « clés en main ».

Les squelettes livrés en standard, la « dist », s’appuient désormais sur la structure HTML des modèles « Layout Gala », qui permettent de modifier la disposition des différents blocs en modifiant quelques lignes de CSS :

<div id="page">
	<div id="entete">Entête</div>
	<div id="conteneur">
		<div id="contenu">Contenu</div>
	</div>
	<div id="navigation">Navigation</div>
	<div id="extra">Extra</div>
	<div id="pied">Pied de page</div>
</div>

Le code HTML des squelettes intègre par défaut les Microformats.

Les squelettes respectent le XHTML 1.0 strict, ainsi que les scripts de l’espace privé. Toutefois le Doctype déclaré est le XHTML transitionnal, afin de ne pas contraindre les rédacteurs à l’apprentissage d’une norme difficile et assez critiquable (voir le premier paragraphe de l’article sur Le validateur XML intégré).

La gestion des raccourcis a évolué et de nouvelles variables permettent de les personnaliser. (Cf. : http://archives.rezo.net/spip-core....)

-  Personnalisation des balises insérées par SPIP pour l’italique et le gras :

$GLOBALS['debut_italique'] = '<i>' ;
$GLOBALS['fin_italique'] = '</i>'  ;
$GLOBALS['debut_gras'] = '<strong>' ;
$GLOBALS['fin_gras'] = '</strong>' ;

-  Paragraphes : tous les textes sont désormais paragraphés par SPIP de façon identique et cohérente. Pour retrouver le fonctionnement antérieur, il suffit de régler la variable de personnalisation $toujours_paragrapher à false :

$GLOBALS['toujours_paragrapher'] = false;

-  Suppression des class="spip" sur les p, i, strong et li. La variable de personnalisation pour les remettre est (attention, notez l’espace initial !) :

$GLOBALS['class_spip'] = 'class="spip';

Remarquez que, dans les notes, <p class="spip_note"> est conservé si <p class="spip"> est conservé (pour compatibilité ascendante), sinon il disparaît aussi.

On peut intervenir plus finement, par exemple, pour enlever le class="spip" des paragraphes mais pas des italiques :

$GLOBALS['class_spip'] = '';
$GLOBALS['debut_italique'] = '<i class="spip">';
$GLOBALS['debut_gras'] = '<strong class="spip">';

Par ailleurs, si on veut vraiment enlever le class="spip" des autres raccourcis (ul, ol, tables, hr, h3 et blockquote générés par les raccourcis), on peut faire :

$GLOBALS['class_spip_plus'] = '';

-  Poésie : le code créé par le raccourcis SPIP <poesie> devient : <blockquote class="spip_poesie">

-  Date de première publication : signalons enfin ici une autre variable de personnalisation, bien qu’elle ne concerne pas les styles. Par défaut, l’année de la date de publication reste libre. Pour forcer l’affichage d’un menu déroulant à partir d’une certaine année (comme pour la date de mise en ligne), on peut personnaliser la variable $debut_date_publication, par exemple :

$GLOBALS['debut_date_publication'] = 1997;

-  Nouveautés dans les filtres

— image_typo fonctionne (de manière expérimentale) avec l’arabe (et sans doute l’hébreu). La présence de caractères arabes et hébreux est détectée automatiquement, ce qui déclenche alors un certain nombre d’automatismes destinés à inverser l’ordre des lettres (de droite à gauche) et à gérer le système complexe de ligatures de l’arabe.

— Trois nouveaux filtres de manipulation des couleurs apparaissent : couleur_saturation, couleur_web et couleur_4096.

Le filtre couleur_saturation admet une valeur entre 0 et 1 indiquant la saturation de la couleur :

• 0 : blanc
• 1 : couleur complètement saturée (attention : la couleur totalement saturée n’est pas le noir).

Ce filtre est très pratique pour fabriquer un camaïeu de couleurs, là où les fonctions couleur_eclaircir et couleur_foncer manquent de précision et, surtout, affadissent les couleurs (en ne jouant pas sur la saturation, mais sur la luminosité).

Le filtre couleur_web retourne un arrondi de la couleur dans une gamme de 256 couleurs. Le but n’est pas réellement de réaliser un affichage pour écran en 256 couleurs (de tels écrans existent-ils encore ?), mais plus généralement de limiter le nombre de couleurs possibles appliquées à un filtre graphique (par exemple colorer une image typographique ou changer une feuille de style) et ainsi éviter d’obtenir potentiellement 16 millions de variantes d’un tel fichier.

Le filtre couleur_4096 retourne un arrondi de la couleur dans une gamme de 4096 couleurs.

— Enfin, le filtre couleur_extreme admet maintenant une variable optionnelle, entre 0 et 1 (par défaut : 0.5), pour régler le seuil de luminosité à partir duquel on bascule en noir ou en blanc.

Au passage, les fonctions de conversion entre RGB, HSL et HSV sont intégrées dans les sources (à usage interne des fonctions de manipulation des couleurs). Le passage en HSL est d’ailleurs utilisé désormais dans couleur_extreme, ce qui fait que le basculement noir-blanc se fait sur une base « visuelle », et pas seulement sur la moyenne des composantes.

— Le filtre graphique image_aplatir accepte désormais un quatrième paramètre, permettant de conserver la transparence (notamment pour la conversion vers le format GIF).

— Le nouveau filtre graphique image_format permet de forcer le passage d’un format à un autre, en conservant la transparence dans le cas du PNG et du GIF. Il s’agit d’un raccourci (simplifié, donc) de la fonction image_aplatir.

Attention, dans le cas d’une conversion du PNG avec transparence vers le GIF, cette fonction ne permet pas de choisir la couleur vers laquelle on réalise la transformation des points semi-transparents ; dans une telle situation, c’est donc image_aplatir qui devra être utilisée.

— Les filtres de traitement d’image ont été enrichis d’un mécanisme automatisé de collecte et nettoyage des images temporaires. Ainsi lors de la succession de plusieurs filtres dans une même expression, seule l’image finale est conservée, ce qui permet de réduire l’espace disque consommé.

— Le nouveau filtre compacte_head compacte les différents fichiers Javascript et CSS appelés depuis une squelette, dans deux fichiers uniques de taille réduite, ce qui permet d’accélérer le chargement des pages visitées (on n’appelle plus ainsi plusieurs fichiers Javascript mais un seul, et ce fichier est plus léger). Si l’on utilise (comme c’est le cas du squelette de la dist) une inclusion inc-head.html réunissant les appels Javascript et CSS, cette fonction sera automatiquement activée grâce à un réglage dans la page de configuration de SPIP.

-  Nouveaux mode d’inclusions, notamment en AJAX

La balise #INCLURE interprète l’argument {env} comme la transmission de tout l’environnement au squelette inclus. Cette notation fonctionne aussi avec <INCLURE ...>. Si d’autres arguments sont présents, les valeurs qu’ils indiquent pour leurs variables seront prioritaires sur l’environnement inclus :

 <INCLURE{fond=gribouille/rubrique}{env}{lang=en}>

incluera gribouille/rubrique en lui passant les {id_rubrique} et {debut_pages} du contexte incluant (de l’URL, autrement dit), mais en forçant la langue anglaise même si l’URL comporte ?lang=XX.

L’argument {ajax} ajouté a une balise #INCLURE ou a <INCLURE ...> permet d’ajaxer automatiquement tous les liens de classe ajax et tous les liens contenus dans une classe pagination. Pour plus de détail, se reporter à `ajax` pour les `inclure`

Signalons que la balise INCLURE admet un slash final optionnel, afin de se rapprocher de la syntaxe XML.

Autre cas d’inclusion, les balises dites dynamiques, dont le nom commence par #FORMULAIRE_ car elles produisent des formulaires. Ces formulaires de l’espace public, et même d’une partie de l’espace privé, ont été réécrits à l’aide d’un nouvelle méthode, CVT (charger, vérifier, traiter). Elle permet de créer de nouveaux formulaires en écrivant seulement des squelettes, SPIP se chargeant de repérer les formulaires mal remplis, et sinon d’insérer des enregistrements dans la base de données.

Ainsi, prive/contenu/ contient les squelettes de rendu des objets éditoriaux, et prive/editer/ les squelette d’édition correspondants, qui font appels à la série des #FORMULAIRE_EDITER_... situés dans prive/formulaires. Il devient possible de personnaliser ces pages en fonction des numeros de rubrique avec un suffixe -xx.html comme pour tout autre squelette.

Ces nouvelles possibilités sont détaillées dans Formulaires CVT par l’exemple et Les formulaires CVT de SPIP.

-  Nouveautés dans les balises

— Les balises commençant par URL_ sont traitées génériquement, ce qui généralise celles disponibles auparavant. Si la balise n’a pas d’argument, comme dans URL_type, le compilateur de SPIP produit un appel à la fonction generer_url_entite appliqué sur $id_type (qui doit être défini dans le contexte), et sur type. On retrouve ainsi les habituels URL_ARTICLE, URL_RUBRIQUE etc, fondés sur les fonctions generer_url_article, generer_url_rubrique etc qui sont à présent obsolètes car manquant de généralité. Si la balise a un argument, c’est sur lui et non sur $id_type que sera appliquée generer_url_entite. Toute cette famille de balises tient compte d’un éventuel accès à plusieurs bases SPIP (voir ci-dessus). Cette fonctionnalité de navigation à distance permet en particulier de tester un nouveau jeu de squelettes sur un site en production sans modifier son installation.

— La balise #EXPOSE (voir Exposer un article dans une liste) étend son mode d’application. Elle prend la clé primaire de la boucle immédiatement englobante (ou de celle explicitement désignée si l’on emploie la syntaxe #nom:EXPOSE à présent autorisée ici) et compare sa valeur courante à chaque itération avec la valeur du paramètre homonyme dans l’URL d’appel. Elle affiche alors son premier argument si ces deux valeurs sont égales, le deuxième argument sinon. Cette comparaison s’étend à la hiérarchie de la clé considérée, c’est-à-dire que dans une boucle RUBRIQUES on comparera la clé primaire de cette boucle avec le numéro de rubrique de l’article considéré, et dans une boucle GROUPES_MOTS, on comparera sa clé primaire avec le numéro du mot considéré.

— Une nouvelle balise, #FILTRE insérée dans un squelette permet d’appliquer un filtre à l’intégralité de la page générée. Ainsi, en insérant le code suivant dans un squelette :

#FILTRE{compacte_head}

l’intégralité de la page générée par ce squelette sera passée au filtre compacte_head.

— Pour modifier les points de suite de la balise #INTRODUCTION, on peut désormais faire simplement, dans mes_fonctions.php (ou mes_options) :

define('_INTRODUCTION_SUITE', ' (...)');

ou

define('_INTRODUCTION_SUITE', '');

— Appelé implicitement par cette balise, le filtre couper peut être appelé indépendamment et accepte un paramètre supplémentaire qui indique quelle chaîne de caractères sera insérée à la fin du texte coupé :

[(#TITRE|couper{10,'...'})]

— Une nouvelle balise, #SESSION, permet d’accéder aux informations liées à l’internaute identifié (id_auteur, et autres informations liées) et de différencier automatiquement le cache en fonction du visiteur.

-  Nouveautés dans les critères

Il est désormais possible de provoquer une jointure entre deux tables SQL en écrivant directement la notation TABLE.NOM dans un critère. La jointure sera possible si la table indiquée a un champ homonyme d’un champ de la table principale de la boucle, la clé primaire étant prioritaire. En cas de critère sans opérateur explicite {TABLE.NOM} , la valeur implicite prise est la valeur de NOM dans le contexte courant (en particulier, au premier niveau, dans l’URL). Voici par exemple une boucle qui cherche les signatures des pétitions associées aux traductions d’un même article :

<BOUCLE_signatures(SIGNATURES){articles.id_trad}  />

La table SQL signatures ayant en commun avec la table articles le champ id_article, donner la valeur du champ id_trad dans l’URL va provoquer la sélection dans la table signatures de toutes celles associées à un article ayant cette valeur de id_trad dans la table articles.

Cette fonctionnalité est disponible également avec des critères conditionnels. Voici par exemple une boucle qui liste les signatures soit d’une pétition d’un article donné (id_article présent dans le contexte), soit des pétitions associées aux traductions d’un même article (si c’est id_trad qui est présent) :

<BOUCLE_signatures(SIGNATURES){id_article?} {articles.id_trad ?}  />

Cette nouvelle fonctionnalité rend obsolètes certains critères (commetitre_mot par exemple), mais ils sont conservés par souci de compatibilité.

Un autre changement important dans les critères concerne la recherche. Auparavant SPIP se servait d’une table SQL supplémentaire pour effectuer l’indexation des éléments du site à leur création. Les opérateurs de recherche des serveurs SQL actuels sont suffisamment rapides pour se dispenser de ce pré-traitement coûteux en place, et le critère recherche se fonde donc à présent sur eux. Il admet de plus à présent un argument optionnel indiquant la chaîne à rechercher. En son absence, c’est toujours la variable d’URL recherche qui est utilisée ; il y a donc équivalence entre <BOUCLE_t(ARTICLES){recherche}> et <BOUCLE_t(ARTICLES){recherche #ENV{recherche}}>.

L’intérêt de cette extension est multiple :

• chercher une chaîne donnée par le contexte interne au squelette comme dans

  <BOUCLE_m(MOTS){id_mot}>
  	<BOUCLE_r(ARTICLES){recherche #TITRE}>
  	...
  	</BOUCLE_r>
  </BOUCLE_m>
  

• transmettre la chaîne à chercher à un squelette inclus, comme dans <INCLURE{fond=x}{recherche=NNN}>
• utilisation dans un modèle pour sélectionner des objets dont les champs contiennent la chaîne comme dans <modele1|recherche=spip>

Dans le cas d’une utilisation conditionnelle de ce critère, on veillera à éviter des espaces entre le point d’interrogation et la valeur indiquée :

{recherche ?#ENV{rech}} et non {recherche ? #ENV{rech}} sauf si on veut effectivement une espace avant la chaîne recherchée.

-  Avec Salvatore, my plugin spricht разных språk

Salvatore est laid, rustre, bossu, un peu fou, et il parle toutes les langues (mais si, voyons !).

Salvatore est notre nouvel outil qui permet de développer un plugin multilingue, en synchronisant automatiquement son fichier de langue sur SPIP-Zone avec l’espace de traduction (qui réunit tous les traducteurs de SPIP). Consulter et participer à sa documentation.

-  Validation XML

Le validateur XML intégré s’enrichit d’une nouvelle fonctionnalité : si son argument est un répertoire, et non une URL, il s’applique sur tous les fichiers de ce répertoire dont l’extension est égale à la valeur du paramètre d’URL ext. En son absence, l’extension .php est prise, et si aucun fichier .php n’existe, il considérera tous les fichiers .html, vus comme des squelettes. Les arguments attendus par ces squelettes sont générés automatiquement, après analyse de leur contenu. Une telle analyse n’est pas possible pour les scripts, PHP étant typé dynamiquement, mais l’architecture générale de SPIP, notamment l’absence d’utilisation de l’instruction exit, permet au validateur un test en aveugle déjà très informatif.

L’influence de XML sur SPIP se fait aussi sentir dans une petite innovation syntaxique. Les boucles sans corps disposent à présent d’une notation abrégée, inspirée de la notation XML.

Par exemple, la boucle suivante :

<BOUCLE_message(FORUMS){id_article}>
</BOUCLE_message>
#TOTAL_BOUCLE messages
</B_message>

peut désormais s’écrire :

<BOUCLE_message(FORUMS){id_article} />
#TOTAL_BOUCLE messages
<//B_message>

SPIP et le développement Web

Cette section décrit les outils de développements utilisés par l’équipe SPIP, outils que les développeurs tiers doivent maîtriser pour fournir des extensions portables.

De nombreux sites Web, par l’interaction qu’ils proposent aux visiteurs, sont en eux-mêmes des applications en ligne. De nombreux développements de la branche 2 sont désormais destinés à aborder la création de sites Web 2.0 : gestion de sessions d’utilisateurs, collaborations sur le site public, meilleure gestion des événements datés...

-  Le serveur SQL virtuel

La nouvelle version de SPIP a nécessité un long travail de réécriture des requêtes SQL afin de le rendre portable. Ces portages reposent sur une interface de programmation qu’il suffit d’utiliser pour qu’une extension de SPIP soit elle-même portable. Elle fournit également une gestion des problèmes de sécurité de type attaque par injection de code.

Cette interface ne repose pas sur des bibliothèques pré-existantes, car leur niveau d’abstraction est insuffisant pour résoudre tous les problèmes posés, mais sur un jeu d’une trentaine de fonctions virtuelles déduites par abstraction du code antérieur de SPIP. Sa généralité lui permet même de servir à l’intégration de bases SQL hétérogènes, indépendamment des autres services rendus par SPIP.

L’interface inclut un gestionnaire de ses propres versions, qui permettra d’exécuter simultanément des extensions de SPIP utilisant différentes versions de cette interface au cas où celle-ci devrait évoluer.

Cette réécriture complète profite également à MySQL puisque les constructions SQL les plus coûteuses ont été éliminées. Ainsi, la cohérence de la base est assurée incrémentalement et non plus par un balayage complet périodiquement. Le verrouillage global du serveur a été systématiquement remplacé par des contraintes SQL refusant automatiquement une écriture concurrente à celle en cours.

Certains index ont été redéfinis pour améliorer leur efficacité. Enfin, le compilateur analyse plus finement la nécessité des jointures, le code SQL produit étant plus souvent proche de l’optimalité sur ce point.

Ces améliorations sont visibles notamment à l’aide d’un profileur SQL disponible à présent dans le débusqueur de SPIP.

La procédure de mise à jour a été elle aussi réécrite et totalement repensée. Elle gère à présent sans faillir des bases dont le volume important exigeait auparavant des outils spécifiques du serveur SQL.

Ce nouvel aspect de SPIP est décrit dans un article spécifique : L’interface de SPIP avec SQL.

-  De nouveaux pipelines, appelés beaucoup plus largement

Le nombre de pipeline s’enrichit a près de 50, ainsi que leur nombre d’appels avec plus de 180 points d’entrée.

En particulier

• les pipelines pre_edition et post_edition sont appelés systématiquement avant et après enregistrement en base de donnée d’un objet éditorial, que ce soit lors de la création, lors de la modification, ou lors de du changement de statut ;
• le pipeline recuperer_fond permet d’agir sur le résultat de tout squelette inclus au moment de son évaluation ;
• les pipeline pre_boucle et post_boucle permettent de modifier le comportement d’une boucle sans surcharge.

Cette extension des pipeline permet aux plugins d’agir encore plus sur le comportement de SPIP avec toujours moins de risque d’incompatibilité entre eux.

-  Bibliothèques externes

SPIP fait comme phpMyAdmin pour se connecter à mysql : si l’extension n’a pas été chargée, il utilise un chargement dynamique dl('mysql.so'), après avoir soigneusement vérifié qu’il y était autorisé. Ca permet d’installer sur des serveurs configurés de cette manière-là (ubuntu par exemple).

Une fonction SPIP permet de demander un chargement dynamique : charger_php_extension('mysql').

À vous de jouer !

Ces évolutions de SPIP permettent désormais de développer, outre des sites internet usuels, des applications type intranet et toutes sortes d’applications en ligne, mêlant sessions d’utilisateurs, AJAX, pages personnalisées ou interfaces interactives évoluées.