SPIP

Charte d'accueil de SPIP

L'équipe de SPIP — 2018-11-05T14:56:44Z

Sommaire

SPIP c'est quoi ?

SPIP est un logiciel libre qui permet de créer des sites internet. Il est placé sous la licence GNU GPL3.
SPIP est développé et maintenu par sa communauté, avec tendresse.

La communauté

La communauté SPIP est un collectif informel, constitué par les personnes contribuant au projet au sens large, comme par exemple, et de façon non limitative, au logiciel, aux plugins, aux traductions, aux productions graphiques, comme aux échanges dans les différents espaces de la galaxie, ou à l'animation du groupe. Indépendante de toute association, fondation ou entreprise, la communauté SPIP s'organise autour de la mutualisation de toutes ces contributions.

On appelle "galaxie SPIP" l'ensemble des lieux officiels maintenus par la communauté. Il peut s'agir de sites de documentation, de listes de discussion par email, de forum, d'outils pour le code source… Ces lieux sont listés dans un bandeau commun en haut de page des sites, "la boussole".

On appelle "équipe de maintenance", le groupe des personnes qui maintiennent le code et sortent les nouvelles version du noyau du logiciel SPIP, ainsi que sur les plugins et squelettes qui sont fournis par défaut. Les nouvelles personnes sont intégrées par co-optation au fil du temps.

Une liste des membres de cette équipe peut être trouvée dans le groupe maintenance sur discuter.

Il existe également une équipe dédiée à la sécurité, c'est celle-ci qu'il faut joindre pour signaler un problème lié à la sécurité à l'adresse securite@spip.net.

Il existe d'autres équipes par thématique : on trouvera la liste de ces équipes sur le Discourse de SPIP.

Toute personne inscrite sur un site de la galaxie ou sur une liste de diffusion SPIP est considérée participante à la communauté. Elle peut y trouver de l'aide, des réponses à ses questions et elle peut apporter de l'aide à d'autres utilisateurs et utilisatrices. Elle peut aussi participer à maintenir et faire évoluer SPIP, l'un des sites de sa galaxie, ou l'un de ses plugins.

Buts et valeurs

Rappelons que SPIP est un logiciel libre, et chaque personne peut l'utiliser et le modifier à sa convenance. Cependant, toute participation doit se faire dans le respect des buts et valeurs promus par le projet initial du minirézo, et notamment :

promouvoir et défendre la liberté d'expression de toutes et tous sur Internet ;
une défiance vis-à-vis de l'argent (lire cette page pour des précisions) ;
le respect de l'identité de chaque personne.

Contribuer à SPIP implique donc de :

veiller à ce que le langage soit inclusif (Abréviations inclusives : oui, mais comment ?) ;
adopter un comportement ouvert et accueillant, empathique, non-sexiste, non-raciste ;
accorder une priorité aux besoins associatifs et collectifs sur les besoins marchands ;
s'efforcer d'internationaliser ses contributions.

Refus du démarchage

Il est interdit d'utiliser les ressources fournies par la communauté pour effectuer un démarchage commercial non sollicité. Cela s'applique quel que soit le moyen utilisé : dans les forums, en message privé, ou en utilisant les informations de contact fournies par les gens dans les différents lieux de la galaxie SPIP.

Bien évidemment, cela ne s'applique pas lorsque l'on répond à des personnes qui cherchent explicitement des prestataires, comme cela arrive parfois.

Inscription dans le mouvement Contributor Covenant

Pour suivre ces idées et faire exister le projet dans un mouvement plus large, la communauté SPIP s'inscrit dans la ligne du code de conduite Contributor Covenant : https://www.contributor-covenant.org/fr/version/1/4/code-of-conduct

Fonctionnement coopératif et gestion des conflits

Ce code de conduite (Contributor Covenant) pose des principes pour prévenir et aider à régler les problèmes de communication qui pourraient se présenter entre différents membres de la communauté.

Malgré tout, en cas de conflit inter-personnel, une commission d'arbitrage peut être saisie au cas par cas, qui statue en toute conscience en se basant sur les critères définis ci-dessus, et dispose de toute latitude.

Droit d'auteur

En accord avec le droit français, toute contribution partagée dans la communauté, de quelque nature qu'elle soit, reste en tant que telle la propriété de la personne qui l'a conçue, mais se fond dans l'« œuvre collective » qu'est le projet SPIP.

Toutes les contributions hébergées par la communauté sont « libres » au sens de GNU (licences GPL, LGPL, FDL sans sections invariantes, Art Libre, Creative Commons), de manière à s'intégrer dans le projet global SPIP. En particulier, si la contribution porte sur l'adaptation d'une œuvre antérieure, il convient de s'assurer des conditions de licence de ladite œuvre.

... Bienvenue dans SPIP !

La boucle CONDITION

L'équipe de SPIP — 2017-06-05T11:33:20Z

Sommaire

Voir aussi

Associée au critère {si ...}, la boucle CONDITION permet de créer des tests.

Elle est utile quand la syntaxe à crochets n'est pas utilisable, par exemple quand d'autres boucles doivent être imbriquées dans les résultats d'un test.

Exemple :

 {5}}> vrai     faux

Voir aussi

Le critère si ...

SPIP 3.1

L'équipe de SPIP, tofulm — 2016-01-09T09:21:09Z

SPIP 3.1 est une version améliorée de SPIP 3.0, qui comprend une mise à jour des bibliothèques JavaScript embarquées, un nouvel habillage graphique pour l'espace privé et les pages publiques ainsi que de nombreuses améliorations. Sa maintenance active s'arrête le 30 juin 2019. À compter de cette date, seule les correctifs liés à la sécurité lui seront apportés.

Sommaire

Cette version sort trois ans après SPIP 3.0 et offre essentiellement aux développeurs :

une mise à jour des bibliothèques JavaScript qui accompagnent le cœur de SPIP et les plugins fournis, avec notamment jQuery et jQuery UI ;
une actualisation du thème graphique de l'espace public. Ce thème intègre la base CSS Tiny Typo ; Lire Présentation de la dist
une actualisation légère du thème graphique de l'espace privé ;
des nouveautés et de nombreux bugs corrigés.

SPIP 3.1 : des nouveautés

Les rédacteurs et administrateurs pourront trouver utile :

un bouton supplémentaire sur les barres d'outils d'édition qui permet d'éditer le texte en plein écran, avec sa prévisualisation directe sur le côté ;
le lecteur multimédia HTML5 http://mediaelementjs.com fourni en standard pour lire directement vidéos et sons ;
l'ajout d'une vidéo calcule, ses dimensions et sa durée (intégration partielle du plugin getID3 dans le plugin médias) ;
les forums de discussion dans l'espace privé peuvent se greffer sur n'importe quel objet éditorial via un formulaire de configuration ;
les statistiques peuvent être affichées soit sous forme de graphique, soit sous forme de tableau ;
la page plan de l'espace privé est améliorée et permet de déplacer des éléments par glisser/déposer ;
une nouvelle option dans les préférences personnelles des webmestres pour afficher ou non le menu « Développement » ;
des améliorations de l'ergonomie du multilinguisme par secteur.

SPIP 3.1 : l'écriture des squelettes est facilitée

Critères

le critère {age} est modifié, code simplifié et débogué pour certaines durées ;
le critère {tri} accepte un 3e argument avec le nom commençant par 'session' et indiquant que le sens et l'élément trié doivent être sauvés dans la session de l'utilisateur ;
le critère {branche} accepte un second argument pour préciser la ou les rubriques à parcourir.

Balises

la balise #MODELE accepte le paramètre env transmettant l'environnement complet ;
la balise #INCLURE transmet l'éventuel paramètre connect présent dans l'URL, tout comme le fait déjà l'inclusion

Filtres

le nouveau filtre |setenv

Logos et images

filtre_inactif au lieu de no_image_filtrer ;
la classe .spip_logo sur les documents à la place de .spip_logos (.spip_logos supporté encore quelques temps) ;
l'action d'édition des logos a évolué :
- la hauteur ou largeur maximale des logos peuvent être définies seules ;
- si un logo ou une image téléversée dépasse la taille maximale autorisée, et que les miniatures sont autorisées, on réduit le logo ou l'image transmise à la taille maximale plutôt que renvoyer une erreur ;
si un document dépasse la taille exploitable par le serveur, une erreur est affichée sans poser de problème ajax.

Plugins

meilleure ergonomie de l'interface de gestion des plugins ;
nouvelles balises dans le paquet.xml ;
- script pour ajouter un script JavaScript dans le header public ou privé ;
- style pour ajouter un fichier CSS ;
- genie pour exécuter une tache cron simplement ;
- procure pour indiquer qu'un plugin procure des fonctionnalités.

SPIP 3.1 : sous le capot

Certaines modifications mineures du core peuvent intéresser les hébergeurs ou webmestres de sites SPIP :

les sessions anonymes de SPIP utilisent maintenant les sessions PHP ;
le cache des vignettes d'images est stocké dans 256 sous-répertoires (#3277), ce qui peut améliorer les performances sur les disques NAS ;
lors de l'utilisation d'une base MySQL, les fonctions PHP mysqli_* sont utilisées à la place des fonctions mysql_*. Il faut donc que les fonctions mysqli soient présentes sur le serveur hébergeant le site (elles sont actives par défaut dans PHP depuis la version 5.0) ;
les tables MySQL utilisent maintenant MyISAM par défaut (les versions récentes de MySQL s'installaient en INNODB) ;
la gestion du cache a été améliorée en reprenant la méthode filecache du plugin mémoization ;
les révisions des objets éditoriaux ne sont plus stockées de façon compressée afin d'éviter des problèmes lors de la restauration de sauvegardes de la base de données ;
intégration des fonctions d'import/export de fichiers CSV du plugin SPIP-Bonux ;
API objet_inserer() plus consistante avec le second paramètre $set ;
API de rôles sur les liens : aux liens entre objets peuvent être associés des rôles.

SPIP 3.1 : un code source plus beau

Un gros travail sur la présentation du code source a été effectué :

adoption des normes de codage PSR2 personnalisées ;
annotation de nombreuses fonctions PHP au format phpDoc [1] qui permet de générer automatiquement une documentation technique du code source ;
nombreuses « notices » PHP corrigées.

SPIP 3.1 : les performances web coté client

Dans une optique de performance, la méthode getScript de la bibliothèque JavaScript jQuery est surchargée pour utiliser le cache navigateur. En effet, par défaut, jQuery ne met pas en cache ces éléments. Il est par conséquent conseillé dans un squelette SPIP, utilisant jQuery.getScript(...), d'appliquer le filtre timestamp au fichier demandé, de sorte qu'une modification du fichier source entraîne une actualisation du cache navigateur.

Exemple :

jQuery.getScript('[(#CHEMIN{prive/javascript/ui/widget.js}|timestamp)]', function(){ ... });

Un header Link est envoyé dans les en-têtes HTTP pour annoncer la feuille de style compressée pour qu'elle soit chargée plus rapidement par le navigateur.

Bibliothèque jQL dans le plugin Compresseur

Il est également possible d'activer via la constante _JS_ASYNC_LOAD un chargement asynchrone du JavaScript compressé de l'espace public par l'intermédiaire de la bibliothèque jQL intégrée au compresseur. Il faut que les scripts « inline » soient compatibles.

Mettre à jour un site existant vers SPIP 3.1

Vérifier la compatibilité de ses plugins

Avant le lancer la mise à jour par les méthodes habituelles (FTP, Spip loader, Subversion), il est conseillé de mettre à jour ses plugins.
Le plugin suivant permet aussi de vérifier si les plugins de votre site sont bien compatibles avec SPIP 3.1
http://contrib.spip.net/Verifier-ses-plugins-pour-le-passage-a-SPIP-3-1

Passer un plugin SPIP 3.0 vers SPIP 3.1

À ce sujet, consulter l'article de spip-contrib.

Au sommaire :

Bibliothèques JavaScript jQuery et jQuery UI
Formulaires CVT
Jointures
Manipulation des logos
Balise #FICHIER
Une fois testé et approuvé...

Évolution des bibliothèques JavaScript

La mise-à-jour des bibliothèques JavaScript intégrées à SPIP 3.1 peut dans certains cas nécessiter une mise-à-jour des squelettes ou plugins lors d'une migration depuis SPIP 3.0. Particulièrement, pour les mises-à-jour de jQuery et jQuery UI.
Vous pouvez regarder les conseils de mise-à-jour de ces bibliothèques respectives :

jQuery est mis à jour de 1.7.2 à 1.11.3 . Voir jquery 1.8, jQuery 1.9, jquery 1.9 guide de mise-à-jour, jQuery 1.10, jQuery 1.11 ;
jQuery UI est mis à jour de 1.8.21 à 1.11.4. Voir les guides de migration. Notez également que les emplacement des fichiers JavaScript et CSS dans jQuery UI comme dans le plugin SPIP jQuery UI ont changé. Les inclusions de ces scripts dans les squelettes devront donc probablement être réécrites.

[1] texte de documentation précédent le code source d'une fonction, dans un format précis

Structure générale de SPIP

L'équipe de SPIP — 2010-08-13T11:59:41Z

Sommaire

SPIP est un CMS unique en son genre.

Au-delà de son fonctionnement qu'on peut qualifier de « data driven », à savoir « piloté par les données » (les fameuses BOUCLES), il a toujours fourni en première ligne les moyens de « customiser », adapter son fonctionnement et sa présentation au goût et aux besoins propres du site.

C'était d'abord la possibilité de fournir ses propres squelettes (templates), d'adjoindre des fragments de php spécifiques et de surcharger les fonctions de base du « core » (les function xxx_dist() que nous verrons plus loin).

Les plugins permettent d'ouvrir SPIP à des fonctionnalités supplémentaires sans alourdir son noyau (le « core »). La tendance actuelle est même d'alléger ce core en transférant les fonctionnalités optionnelles dans des plugins.

Les répertoires qui le constituent permettent de bien séparer les éléments selon leur durée de vie, le fait qu'il soient modifiables et leur appartenance à ce qui est propre ou spécifique au site ou au code de base. Un des autres objectifs visés ici est la possibilité de mutualiser le noyau : que plusieurs sites puissent partager une base de code commune.

Étudions d'abord cette nouvelle organisation des répertoires, de ce qui appartient à SPIP à ce qui est propre au site, de ce qui reste constant à ce qui bouge.

Dossiers livrés avec SPIP

racine du site

La racine a été complètement vidée et ne contient pratiquement plus que index.php qui redirige sur spip.php, c'est maintenant l'unique point d'entrée de la partie publique du site.

SPIP est fourni avec un fichier htaccess.txt qu'on pourra renommer en
.htaccess pour l'url rewriting essentiellement.

ecrire/

Ce dossier contient l'ensemble des fichiers interprétables côté serveur (PHP et MySQL) et ce, aussi bien pour l'affichage public (sous-dossier public/) que pour l'affichage privé.

Le nom de ce dossier est historique, c'était auparavant là où on trouvait le code permettant de modifier le contenu du site. Paradoxalement, c'est un dossier maintenant immuable, on n'écrira plus jamais dedans. Dans une installation normale, il ne contient que les scripts livrés par la distribution et il est quasi impératif de ne pas y faire de modification.

Son script index.php est le point d'entrée de ecrire/, la partie privée du site.

prive/

Interface de la partie privée de SPIP

squelettes-dist/

Il contient tous les fichiers livrés au client (HTML, Javascript, feuilles de style, images de différents formats) ainsi que les patrons de mise en page nommés squelettes. Ces squelettes sont interprétés côté serveur afin d'envoyer au client un texte purement MIME (la plupart du temps du HTML, mais aussi du RSS, du SVG... voire du JS).

Ce sont les modèles standards livrés avec SPIP, ils ne doivent eux aussi pas être modifiés mais remplacés en les copiant dans squelettes/

vendor/

Bibliothèques PHP.

Dossiers permanents

config/

Ce dossier, créé à l'installation, contient le script de connexion à la base de données : connect.php et le script fixant le mode des fichiers créés par le serveur : chmod.php.

C'est aussi ici qu'on place les options universelles du site, dans un fichier (à créer) : mes_options.php [1]

IMG/

Il contient tous les documents originaux (taille réelle) du site. Il est subdivisé en sous-dossiers par types de documents.
À l'installation, il ne contient que des documents de test pour la fabrication des images.

squelettes/

C'est ici qu'on dispose tous les fichiers : scripts, images, formulaires... propres au site en suivant la même structure que ecrire/ ou dist/. Par exemple, pour redéfinir le sommaire du site, on y copie/adapte le fichier sommaire.html du répertoire dist/.

On met là notamment, le script mes_fonctions.php (à créer) qui est chargé à chaque recalcul de page. À noter qu'il est possible de faire un xxx_fonctions.php qui sera chargé (en plus du mes_fonctions.php) uniquement lorsque la page xxx sera demandée (par exemple : sommaire_fonctions.php).

À l'installation, ce dossier n'existe pas, il faut le créer.

plugins/

Ce dossier reçoit les sous-dossiers de chaque plugin. Par exemple, le plugin crayons est placé dans plugins/crayons/.

Dossiers temporaires

local/

Il contient tous les fichier (re-)calculables à partir des documents et données du site.

Il s'agit essentiellement des caches d'images réduites. On y trouve aussi les caches calculés par certains plugins comme « coloration_code ».

Les fichiers de ce cache sont accessibles depuis le web.

Ce dossier peut être vidé, cela ne coûtera que son recalcul.

tmp/

Ici sont stockés tous les fichiers temporaires comme les caches de squelettes, les sessions, les logs etc.

Il contient aussi le sous-répertoire dump/ où sont archivées les sauvegardes de la base de données.

Contrairement à local/, les fichiers de ce cache ne sont pas accessibles depuis le web.

Ce dossier peut être vidé à tout moment.

Voir aussi : Étendre SPIP

[1] Lire : Le fichier mes_options.php

SPIP 2.1

L'équipe de SPIP — 2010-04-09T21:59:37Z

C'est avec un certain plaisir que l'équipe de SPIP vous annonce la sortie de SPIP 2.1

Sommaire

Ce millésime 2010 s'annonce comme une cuvée exceptionnelle. Il a été fortement testé et dispose d'un jeu plus étendu de tests unitaires, qui permettent de coder de façon plus sure. Cette version 2.1 est un premier pas vers la modularisation des fonctionnalités de SPIP, et voit à ce titre l'apparition d'un répertoire « extensions ». Les plugins présents dans ce répertoire sont activés dès l'installation de SPIP et non désactivables, ce qui ouvre la voie à des distributions spécifiques de SPIP.

Principales améliorations apportées par la version 2.1

— plus rapide :

meilleure gestion des accès disque
cache sur les chemins calculés
améliorations et extension du serveur SQL virtuel

— plus sécurisée :

sha256 sur les mots de passe et actions
vérification du fonctionnement des .htaccess
détection automatique des mises à jour de SPIP

— plus belle :

intégration (comme extension) du plugin « porte-plume » qui améliore grandement l'édition des champs texte et offre une prévisualisation en cours d'édition
interface graphique par défaut plus légère et élégante
possibilité de définir des thèmes graphiques (comme par exemple avec le plugin « themes_interface_privee »)
meilleure gestion de la taille des champs texte (agrandissement conditionnel)
gestion (configurable et désactivable) de la transparence PNG24 sous MSIE6 sur le site public
retour des liens « modifier cet article » et « proposer cet article » lors de l'édition des articles
nouvelle interface de gestion des plugins
remodelage des procédures de sauvegarde/restauration
possibilité de créer des URL accentuées en définissant _TRANSLITTERER_URL à « false » (attention à la configuration du serveur)

— plus à jour :

compatibilité PHP 5.3
intégration de la bibliothèque jQuery 1.4.2
intégration de la bibliothèque pclzip 2.8.2

— plus svelte :

premières mises en extensions de fonctionnalités du core : compresseur (js, css, html), porte-plume (barre d'outils), filtres images et couleurs (traitement d'image), safehtml (sécurisation des forums et pétitions), support pour vieux navigateurs
gestion d'un nouveau répertoire (extensions/) pour y placer ces plugins actifs dès l'installation et non désactivables

— plus extensible :

apparition de nouveaux points d'entrée pour les plugins
remodelage de la gestion des plugins (et répertoire spécifique pour leur gestion : ecrire/plugins)
les plugins peuvent être installés dans un ou des répertoire(s) supplémentaires si définis par la constante _DIR_PLUGINS_SUPPL (facilte leur usage en cas de mutualisation)
possibilité d'étendre l'aide en ligne pour y intégrer des sections personnalisées et gestion automatique de ses traductions

— plus structurée :

mise en oeuvre d'une API d'authentification
amélioration de l'interface LDAP
refonte de l'API de notification
homogénéisation des balises #LOGO_ : les paramètres sont désormais passés entre accolades et disparition des « doubles pipes » (#LOGO_xxx||filtre (écriture obsolète mais toutefois encore fonctionnelle)
apparition de nouvelles balises et fonctions : #BOUTON_ACTION, |balise_img, |couleur_luminance (similaire à |couleur_saturation, mais agissant sur l'intensité lumineuse de la couleur)
possibilité pour les balises dynamiques (de type #FORMULAIRE_) de manipuler à l'exécution des valeurs qui ne sont connues que durant la compilation

— plus facile à débugger :

amélioration du débuggueur désormais capable d'indiquer la ligne fautive dans un squelette
le débuggueur informe désormais sur l'endroit précis de l'éventuelle mauvaise utilisation des balises dynamiques
API du débuggueur plus fonctionnelle (possibilités d'appel et de personnalisations accrues)
amélioration du mode inclure (?var_mode=inclure) affichant les différentes inclusions (intégration avec le plugin Skeleditor permettant de surcharger et d'éditer facilement en ligne des squelettes)
possibilité de surcharger la fonction spip_log()

— plus geek :

le compilateur offre une meilleure séparation entre le phraseur et l'arbre d'abstraction, permettant de créer de nouvelles syntaxes (pour les courageux)
réapparition d'un décompilateur complet et paramétrable offrant la possibilité de créer et d'expérimenter de nouvelles syntaxes

Incompatibilités connues

Comme toute nouvelle version majeure, cette 2.1 s'accompagne de quelques
incompatibilités heureusement aisément corrigeables :

Dans les boucles, le nom des tables SQL extérieures à SPIP doit être passé dans sa graphie réelle et non plus en majuscules :
en lieu et place de en lieu et place de
Le filtre |reduire_image disparaît définitivement (il était déjà obsolète, remplacé par |image_reduire)
Ajouter include_spip("inc/filtres_images"); dans les scripts php faisant appel à des fonctions utilisant les filtres graphiques
S'inspirer des nouveaux fichiers de ecrire/url/ pour écrire des scripts de personnalisation d'URL
Le pipeline creer_chaine_url disparait, remplacé par des pipelines spécifiques : propres_creer_chaine_url, arbo_creer_chaine_url, ...
Toute accolade ouvrante collée à une balise est désormais considérée comme fournissant des arguments à cette balise exemple : dans une feuille de style : .rub_#ID_RUBRIQUE{font-size:1.2em;} ne fonctionnera pas il faut soit séparer l'accolade : .rub_#ID_RUBRIQUE {font-size:1.2em;} soit utiliser la notation complète pour la balise : .rub_[(#ID_RUBRIQUE)]{font-size:1.2em;}
Les appels jQuery du type $("input[@name=prenom]"), déjà obsolètes avec jQuery 1.3, ne fonctionnent plus avec la version 1.4.2 de jQuery, utilisée par SPIP 2.1 ; il faut désormais écrire : $("input[name=prenom]")
L'écriture #SET{variable,} n'est plus acceptée (définir une variable comme vide) et doit être remplacée par #SET{variable, ''}
Pour les plugins, la déclaration vide dans le fichier plugin.xml n'est plus acceptée
Pour utiliser une fonction spécifique d'un plugin seulement si ce plugin est activé (et sinon ne rien faire) il faut désormais écrire : [(#BALISE|appliquer_filtre{fonction_specifique})] en lieu et place de [(#BALISE|fonction_specifique)] qui génèrera une erreur.
Pour les balises #LOGO_xxx [1], les faux filtres |fichier et |lien sont remplacés respectivement par l'écriture #LOGO_xxx** et #LOGO_xxx*. Les faux filtres de positionnement (|top, |left, |right, |center et |bottom) et les balises |#URL_yyy en position de filtre sont à présent à écrire comme argument de la balise. L'écriture [(#LOGO_xxx|left)] est donc remplacée par #LOGO_xxx{left} et l'écriture [(#LOGO_xxx|#URL_yyy)] est remplacée par #LOGO_xxx{#URL_yyy}.
Il est fortement recommandé d'utiliser #INSERT_HEAD pour que les extensions puissent fournir leur feuille de style et code javascript spécifique.


		
		
[1] voir le détail des changements



SPIP 2.0
L'équipe de SPIP — 2008-12-12T22:45:39Z

		
Sommaire
 SPIP et la publication Web
 SPIP et le design Web
 SPIP et le développement Web
 À vous de jouer !
SPIP passe en version 2.0, sept ans après le lancement de la version 1.0, huit ans après la version d'uZine,
et presque deux ans après la précédente version.
La branche 1 de SPIP était un système de publication intégré, c'est-à-dire fondé sur un schéma unique de base de données,
prêt à l'emploi. Ses fontionnalités, en particulier son système de squelettes de mise en pages, ont suscité de nouveaux besoins pour lesquels il n'était pas prévu au départ. Le nouveau compilateur de squelettes de SPIP 1.8 avait augmenté leur expressivité, que beaucoup de contributions ont alors utilisée pour présenter toute sorte d'informations imprévues : catalogues, informations géographiques, série d'événements... SPIP 1.9 avait introduit différents méthodes d'extensions, surcharges, point d'entrées, greffons (les plugins). Le succès des sites de contributions à SPIP fut au rendez-vous, et plusieurs contributeurs sont venus renforcer l'équipe des développeurs. Mais seuls les programmeurs avaient accès à ces nouveautés dont l'interface de programmation devait gagner en maturité.
La branche 2 de SPIP se présente donc à la fois comme le système de publication intégré (compatible avec les versions précédentes), et comme une plate-forme de développement multi-serveurs SQL pour qui veut aller plus loin. Cette plate-forme propose elle-même deux niveaux d'expertise, permettant de conserver la progressivité de la courbe d'apprentissage de SPIP tout en augmentant le nombre de services rendus.
 Le premier niveau, déjà présent dans les versions de SPIP antérieures, s'adresse à ceux qui veulent innover graphiquement, sans avoir à programmer en
SQL, PHP et JavaScript. Connaissant HTML et CSS et prêts à apprendre le système de squelettes SPIP, ils peuvent mettre en page de manière innovante des informations issues de bases de données éventuellement hétérogènes.
 Le deuxième niveau s'adresse aux programmeurs, qui pourront écrire des extensions portables sur différents serveurs SQL, à l'aide d'une interface de programmation fondée sur un serveur virtuel SQL. Cette interface peut même être utilisée indépendamment de la base de données installée par SPIP.
Compte tenu de l'abondance des nouveautés, la description de cette nouvelle version de SPIP s'articule en trois thèmes, renvoyant parfois à des articles dédiés :
 SPIP et la publication Web,
 URLs symboliques gérant leur historique et permettant la notation arborescente ;
 incrustation dans les textes de média divers ;
 forums permettant l'inclusion de documents ;
 nombreuses fonctionnalités nouvelles autour des pétitions ;
 gestion des éditions concurrentes ;
 installation automatique de plugins ;
 accès simultané à plusieurs serveurs (MySQL PostGres, SQLite2 et 3), fusion d'extraits de bases, squelettes automatiques ;
 mutualisation facilitée, notamment pour les hébergeurs ;
 SPIP et le design Web
 squelettes fondés sur des CSS LayoutGala ;
 nouveaux filtres ;
 nouveaux modes d'inclusion, notamment de formulaires en AJAX ;
 nouveautés dans les balises, notamment celle gérant URL et clé primaire ;
 nouveautés dans les critères, notamment pour les jointures et le moteur de recherche ;
 gestion automatique des chaînes de langues à traduire ;
 validateur XML intégré applicable sur un ensemble de pages ;
 SPIP et la programmation Web
 serveur SQL virtuel s'appuyant directement sur les couches basses de PHP ;
 nouveaux pipelines ;
 déclarations de bibliothèques externes.
Signalons enfin qu'à partir de cette version, SPIP est distribué sous la licence GNU/GPL 3. Cette licence, qui succède à la licence GNU/GPL 2 vieille de 15 ans, prend mieux en compte le droit d'auteur dans d'autres pays que les Etats-Unis, ainsi que l'évolution de la pratique du logiciel libre.
Explications complètes et argumentaire par la Free
Software Foundation et Richard Stallman :

— la licence

— la licence en français (traduction non officielle)

— Pourquoi mettre à jour vers la GPLv3
Comme toujours, merci à celles et ceux qui ont contribué de près ou de loin à cette nouvelle version. Merci d'abord aux traducteurs, en particulier aux nouveaux venus qui permettent à SPIP d'être désormais disponible en indonésien, en birman, en khmer (cambodgien), en asturien et en suédois.
Merci à celles et ceux qui ont suivi la version en développement presque au jour le jour, merci pour leur patience face à l'immensité du chantier mis en œuvre et les fausses pistes que nous leur avons parfois infligées, merci pour leur confiance malgré les difficultés que nous rencontrions.
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 :
 Entête
  Contenu
 
 Navigation
 Extra
 Pied de page
 
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 article 3541).
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'] = '' ; $GLOBALS['fin_italique'] = '' ; $GLOBALS['debut_gras'] = '' ; $GLOBALS['fin_gras'] = '' ; 
- 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, 
 est conservé si 
 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'] = ''; $GLOBALS['debut_gras'] = ''; 

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  devient :

- 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 . Si d'autres arguments sont présents, les valeurs qu'ils indiquent pour leurs variables seront prioritaires sur l'environnement inclus :
  
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  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 :
 
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) :
 
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
 et
.
L'intérêt de cette extension est multiple :
 chercher une chaîne donnée par le contexte interne au squelette comme dans
  ...   
 transmettre la chaîne à chercher à un squelette inclus, comme dans
 utilisation dans un modèle pour sélectionner des objets dont les champs contiennent la chaîne comme dans 
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
article 3541 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 :
  #TOTAL_BOUCLE messages  
peut désormais s'écrire :
 #TOTAL_BOUCLE messages  
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.

		
		
[1] Concevoir et maintenir la structure éditoriale d'un site enrichi régulièrement n'a rien d'une évidence ; cela demande une expérience certaine. Une structure éditoriale mal conçue finit par disqualifier un site, car les mises à jour deviennent de plus en plus pénibles. La logique de publication de SPIP a tendance à induire des structures éditoriales telles que le site restera bien organisé, même avec des dizaines de milliers d'articles.

[2] AJAX : ensemble de fonctions Javascript permettant de manipuler la structure de la page HTML, de charger des éléments de page individuellement les uns des autres et de créer facilement des animations visuelles dans les pages HTML.



Étendre SPIP
L'équipe de SPIP — 2007-05-20T10:16:55Z
Si vous voulez étendre SPIP et en particulier y contribuer, les points importants à retenir sont les suivants : c'est un outil déjà utilisé par des milliers de personnes, qui a un passé et un avenir, et qui est un travail collectif.
Étant donné la longue histoire de SPIP et la multiplicité des contributeurs et contributrices, on peut rencontrer des styles de programmation variés dans le code. Certaines règles assurent néanmoins la cohérence de l'ensemble.
		
Sommaire
 Organisation des sources
 Règles de programmation
 Règles de codage
 Voir aussi
Organisation des sources
Il est possible de modifier le comportement de SPIP sans altérer ses sources, grâce au chemin d'accès défini par la constante SPIP_PATH. Toute extension de SPIP doit opérer ainsi afin qu'un test d'intégration soit débrayable par simple redéfinition du chemin d'accès, la distribution de SPIP étant en lecture seule.
Si vous êtes convaincu qu'un certain comportement ne peut être obtenu ainsi, écrire sur l'espace de discussion.
Les contributions à SPIP sont à décrire par un article sur Spip-Contrib et leur contenu est à déposer soit en tant que pièces jointes à cet article, soit, ce qui est mieux, sur le serveur git communautaire.
Pour étendre SPIP ainsi, il faut bien comprendre l'organisation de ces répertoires et le rôle de ses fichiers. La racine d'une distribution de SPIP comporte essentiellement :
- un fichier spip.php, alias index.php, gérant la compatibilité avec les anciennes versions, chargeant le fichier d'initialisation ecrire/inc_version.php et passant immédiatement la main au script principal ecrire/public.php ;
- un répertoire ecrire comportant exclusivement des fichiers interprétables côté serveur (PHP et SQL) ;
- un ou plusieurs (selon les versions) répertoires comportant des fichiers interprétables côté client (HTML, Javascript, feuilles de style, images de différents formats) ainsi que les patrons de mise en page nommés squelettes. Ces squelettes sont interprétés des deux côtés : il s'agit de fichiers composés d'un format MIME complété de quelques directives SPIP, directives traitées côté serveur afin d'envoyer au client un texte purement MIME (la plupart du temps du HTML, mais aussi du RSS, du SVG, du ICS etc).
- deux répertoires vides à l'installation (localet tmp), qui contiendront les données, temporaires ou permanentes, nécessaires à la vie du site.
Rôles des répertoire prive et squelettes-dist et leurs sous-répertoires
Ils contiennent les fichiers déterminant la présentation de SPIP, pour l'espace privé et l'espace public respectivement. Ils contiennent beaucoup de sous-répertoires dont voici les significations :

répertoire rôle


/
contient les squelettes. Leur nom se termine par .html pour des raisons historiques mais cela ne préjuge pas de leur contenu. Il sufit de donner un tel nom, privé de cette extension, au paramètre page de l'URL d'un site sous SPIP pour déclencher l'utilisation de ce squelette.

Ce répertoire contient également les feuilles de styles (d'extension .css) définissant l'habillage par défaut

formulaires/
contient la partie html des balises dynamiques, squelettes de formulaires dont le code PHP figure dans le répertoire ecrire/balise

images/
images de l'espace privé

javascript/
librairies javascript (jQuery, barre typographique, ...)

modeles/
squelettes appelables avec la balise #MODELE ou avec les raccourics 

polices/
polices utilisables pour les images typographiques

vignettes/
vignettes standards pour les types de documents pouvant être associés à un article


Rôles du répertoire ecrire et ses sous-répertoires
Le répertoire ecrire comporte plusieurs sous-répertoires composés de fichiers PHP définissant des fonctions et procédant éventuellement, mais rarement, à une initialisation lors de leur chargement (ces exceptions sont appelées à disparaître). Les fichiers situés au niveau du répertoire principal sont les plus importants à comprendre pour contribuer à SPIP, il s'agit de inc_version.php, public.php et index.php.
Le fichier ecrire/inc_version.php initialise les constantes et les variables globales nécessaires au fonctionnement de SPIP, notamment celles assurant sa portabilité sur les différentes plates-formes. Assez tôt lors de son chargement, il inclut le fichier inc/utils.php, où figurent les fonctions indispensables à SPIP, un fichier hors distribution nommé mes_options.php permettant de moduler cette initialisation sans avoir à modifier le fichier inc_version.php. En particulier, il est possible dans ce fichier personnel d'invoquer la fonction spip_initialisation pour définir les répertoires de données et disposer ainsi de plusieurs sites sous SPIP utilisant une seule distribution (l'appel standard de cette fonction, plus loin dans inc_version.php, sera automatiquement neutralisé). Une autre fonction indispensable à SPIP est find_in_path, exploitant le chemin d'accès, ainsi que include_spip qui repose sur find_in_path, et charger_fonction qui repose sur include_spip. Tous les fichiers de SPIP sont chargés par ces deux dernières fonctions.
Le fichier ecrire/public.php, appelé par spip.php, a pour rôle essentiel de délivrer les pages de l'espace public, commandées lorsque la requête HTTP comporte (après réécriture éventuelle) le paramètre page. Ce script applique alors le squelette ayant pour nom la valeur de ce paramètre. Il envoie les en-têtes HTTP et le contenu obtenus, gère leurs éventuelles erreurs et lance les tâches de fond à l'aide de la fonction cron. Contribuer à l'espace public de SPIP consiste donc simplement à fournir de nouveaux squelettes, avec éventuellement leurs feuilles de style et leurs images.
L'autre rôle de ecrire/public.php concerne le cas où la requête HTTP comporte l'argument action. Il applique alors la fonction charger_fonction à la valeur v de ce paramètre action. Cette application a pour effet de charger le fichier homonyme du répertoire action, dont la fonction principale action_v_dist est alors invoquée. Ces scripts effectuent essentiellement des écritures (en base ou sur fichier) et ne retournent en général pas de résultat, échappant ainsi à la problématique de la mise en page.
Le fichier index.php est le fichier central d'accès aux formulaires de l'espace privé. Il authentifie l'internaute, initialise ses données personnelles et applique la fonction charger_fonction à la valeur v du paramètre exec. Cette application a pour effet de charger le fichier homonyme du répertoire exec, dont la fonction principale exec_v_dist est alors invoquée. Celle-ci a la charge de délivrer l'intégralité du flux de sortie, y compris les en-têtes HTTP. Il est donc possible d'étendre Spip simplement en rajoutant un fichier PHP dans un sous répertoire nommé exec d'un répertoire figurant dans SPIP_PATH.
Le répertoire exec contient exclusivement les fichiers définissant les fonctions directement invocables par le paramètre d'URL exec. Le code PHP de ces fichiers ne doit jamais accéder en écriture à la base de données (les exceptions à cette règle sont en voie de disparition). A l'inverse, il y accède abondamment en lecture afin de vérifier les droits du demandeur et déterminer les données à visualiser. Si l'on veut voir SPIP sous l'archétype Modèle-Vue-Controleur, les fichiers de exec remplissent le rôle de Controleur. Si l'on veut voir SPIP sous l'archétype (Print(Eval(Read))) de Lisp, c'est la partie Read. À terme, ce répertoire devrait devenir un répertoire de squelettes. Il est demandé aux nouvelles contributions de Spip de penser à cet objectif lors de leur rédactions.
Le répertoire action, dont il a déjà été question, contient essentiellement les scripts accédant en écriture à la base de données. Si l'on veut voir SPIP sous l'archétype Modèle-Vue-Controleur, les fichiers de action remplissent le rôle de Modèle. Si l'on veut voir SPIP sous l'archétype (Print(Eval(Read))) de Lisp, c'est la partie Eval. Là encore, contribuer à SPIP consiste à écrire de tels scripts et à les invoquer par des formulaires construits avec la fonction generer_action_auteur assurant la sécurisation de l'accès à ces scripts, qui à l'inverse invoqueront la fonction securiser_action pour vérifier les droits du demandeur. Cette architecture permet de calculer ces droits seulement à la construction des formulaires appelant les scripts d'accès en écriture : plutot que de recalculer tous les droits, ces scripts vérifieront simplement que la clé figurant dans les arguments est la même que celle qu'ils recalculent à partir des autres arguments, de l'identité du demandeur et d'une valeur aléatoire renouvellée périodiquement. Ces scripts ne retournent en général pas de résultat, il n'y a donc là aussi ni code HTML, ni appel à la fonction echo (les exceptions sont appelées à disparaître). En revanche, ils sont souvent appelés avec un paramètre HTTP nommé redirect, demandant une redirection qui sera alors automatiquement opérée par public.php, qui envoie un statut HTTP 204 en l'absence de ce paramètre. Dans le cas des formulaires construits avec la fonction ajax_action_auteur, cette redirection conduit au script homonyme dans le répertoire exec. Ce deuxième script se réduit le plus souvent à charger le fichier homonyme dans le répertoire inc, d'appeler sa fonction principale dont le résultat est retourné au client par l'intermédiaire de la fonction ajax_retour. Il est ainsi très facile d'étendre SPIP en mode AJAX en utilisant cette infrastructure.
Le répertoire inc, le plus volumineux, contient essentiellement les fonctions construisant les pages de l'espace privé renvoyées au client, ces fonctions devant être à terme les filtres utilisés par les fichiers de exec quand ils seront des squelettes. Si l'on veut voir SPIP sous l'archétype Modèle-Vue-Controleur, les fichiers de inc remplissent le rôle de Vue. Si l'on veut voir SPIP sous l'archétype (Print(Eval(Read))) de Lisp, c'est la partie Print. Toutefois ce répertoire contient également beaucoup de fonctions relevant plutot du Controle et devra donc être réorganisé. La plupart des fichiers de inc sont chargés par l'intermédiaire de charger_fonction, et ce sera le cas de tous à terme. Aucune des fonctions de ce répertoire n'est censée utiliser echo. Les contributions à SPIP sont appelées à respecter ces règles dès à présent.
Le répertoire install contient exclusivement les fonctions nécessaires à l'installation de SPIP. Chaque étape peut-être surchargée ou complétée par d'autres, la fonction principale de exec/install.php utilisant ce répertoire selon le même principe que ecrire/index.php avec le répertoire exec.
Le répertoire urls contient des fichiers définissant chacun le même jeu de fonctions de réécriture d'URL. Il s'agit des fonctions calculant, à partir d'un index numérique dans une table de la base de données, un signet plus facile à lire et écrire que l'appel du script PHP effectivement opéré par le serveur HTTP pour cet index et cette table. Là encore, il suffit de rajouter un fichier dans ce répertoire pour obtenir un nouveau jeu, dont le nom sera présenté dans le panneau de configuration de l'espace privé gérant les types d'urls.
Le répertoire lang contient exclusivement des fichiers de données, tableaux indiquant la traduction, pour toutes les langues connues de SPIP, de tous les arguments que la fonction _T, définie dans inc/utils.php, est susceptible de recevoir. Les fichiers sont chargés exclusivement par les fonctions de inc/lang.php. Traduire les fichiers de référence *fr* en donnant un nom conventionnel aux fichiers obtenus suffit à déclarer une nouvelle langue à SPIP.
Le répertoire charset contient lui aussi exclusivement des fichiers de données, tableaux permettant de passer d'un codage de caractères à un autre (utf, iso, ascii, entités html etc). Ils sont lus exclusivement par les fonctions de inc/charsets.php. Il suffit là encore de rajouter un fichier pour disposer d'un nouveau codage, mais SPIP propose tous ceux couramment utilisés, aussi un telle intervention est rarissime.
Le répertoire base contient les fonctions d'interfaces entre PHP et les serveurs SQL que SPIP peut appeler. En particulier, le fichier générique abstract_sql.php contient les fonctions qu'il faut utiliser pour dialoguer avec les serveurs SQL, les fonctions de base de PHP pour cela ne devant pas être utilisées directement par souci de portabilité. Ne doit évidemment figurer aucun code MIME dans ce répertoire.
Le répertoire req contient les portages effectifs du serveur SQL virtuel de SPIP vers les serveurs réels (MySQL, PG) et assimilés (SQLite).
Le répertoire balise contient les fichiers PHP associés aux balises dynamiques de SPIP. Leur nom est homonyme du squelette de squelettes-dist/formulaires. Compléter l'espace public de SPIP par un formulaire F consiste à créer un fichier F.html dans son SPIP_PATH et un fichier F.php dans un sous-répertoire balise de son SPIP_PATH. Le rôle de ce fichier PHP est de réceptionner les saisies demandées par ce formulaire, et éventuellement de ré-afficher celui-ci pour complément en cas de saisies invalides. C'est sans doute le type de contribution à l'espace public la plus difficile à réaliser, car la mécanique sous-jacente exige deux passes d'exécution de PHP dont il faut bien comprendre les rôles respectifs. Avant que ce mécanisme n'existe, la stratégie de développement de formulaire consistait à écrire des squelettes comportant des instructions PHP. Il est toujours possible de le faire, mais le résultat sera peu efficace car jamais mis en cache ; et il ne dispense pas de comprendre les deux passes de PHP intrinsèques au phénomène.
Le répertoire public contient le compilateur des squelettes. C'est une partie du code assez compliquée, mais qui bénéficie d'une interface de programmation qui rend ce compilateur totalement extensible sans exiger d'en comprendre tous les détails.
Le répertoire lib est destiné à contenir des sous-répertoires de bibliothèques développées en dehors de SPIP mais dont il peut avoir besoin.
Dernier point : la plupart des fichiers de SPIP sont utilisés via charger_fonction qui charge un fichier et appelle sa fonction homonyme censée y être définie. Il s'ensuit que le nom d'un fichier PHP doit être composé exclusivement de caractères acceptables pour un nom de fonction PHP : on évitera donc le signe moins, le point etc.
Règles de programmation
SPIP a démarré à l'époque où PHP transformait automatiquement en variables globales les paramètres HTTP. Ce style de programmation suicidaire a été abandonné par PHP4. SPIP a suivi une évolution parallèle, mais décalée dans le temps. Bien que le code actuel ne suive donc pas toujours les règles qui vont suivre, il est demandé aux contributions à venir de les respecter dès à présent, sans attendre que SPIP cesse d'y déroger ici ou là. On pourra lire attentivement le fichier ecrire/articles.php, le plus proche des spécifications qui suivent.
- Privilégier l'écriture par fonctions. La philosophie du logiciel libre est d'être utilisé dans un maximum de contextes différents, en conséquence le code doit être écrit dans une optique de réutilisation en dehors de son contexte initial de développement. L'écriture par fonctions ne référençant aucune variable globale et n'effectuant aucun appel à echo ou print garantit un chargement silencieux et un appel sans effets secondaires indésirables.
- Éviter au maximum l'utilisation de variables globales. Elles sont responsables de nombreuses failles de sécurité et d'impossibilités de réutilisation du code. Les alternatives à leur usage sont :
 la constante, qui a l'avantage de signaler au lecteur que cette valeur ne changera pas pendant toute la durée du script ;
 la variable statique, qui a l'avantage de signaler au lecteur qu'il s'agit de valeur à longue durée de vie mais n'intéressant que la fonction qui la déclare.
- Écrire du code ne produisant aucune erreur ni avertissement en mode error_reporting(E_ALL). Cela facilite la mise au point en cas de variable involontairement indéfinie. Si l'on a vraiment besoin d'exécuter du code en dehors de ce mode, utiliser l'artifice @ en le limitant au maximum à la portion de code problématique, et prévoir un message d'erreur dans le journal, en utilisant la fonction spip_log.
- Commenter le contexte, pas le texte. Il ne sert à rien de paraphraser le nom de ses variables et fonctions, ni les fonctions PHP décrites dans son manuel : les commentaires comme boucle sur le tableau de valeurs devant un foreach ne font que grossir inutilement les fichiers. En revanche, il est souhaitable d'indiquer le type des arguments (PHP étant un langage dynamiquement typé, il se devine difficilement) et leur propriété supposée à l'entrée de la fonction (par exemple : non nul). Quand un bug difficile est corrigé ou anticipé, dire pourquoi le code initial était incorrect pour éviter qu'une réécriture ultérieure ne le réintroduise en croyant optimiser. Enfin, SPIP étant développé en français, éviter les termes absents des dictionnaires de cette langue afin de faciliter la compréhension à ceux dont ce n'est pas la langue maternelle.
- Nommer rationnellement les fonctions et variables. L'organisation du code de SPIP est plutôt fondée sur le découpage en répertoires dédiés que sur des règles de nommage strictes, mais on évitera néanmoins les incohérences comme le multi-linguisme à l'intérieur d'un nom. Les fonctions d'un même fichier tenderont à avoir un préfixe ou un suffixe commun, inspiré du nom du fichier.
- Tester sur un maximum de configurations. N'oubliez pas que SPIP doit fonctionner sur toute plate-forme, tant côté client que côté serveur. Il y a nécessairement plusieurs navigateurs sur votre machine, tester votre code sur au moins deux d'entre eux. Dans la mesure du possible, essayez également plusieurs hébergeurs. Lorsque une plate-forme force une écriture étrange, la mentionner explicitement, en précisant sa version et la date de l'essai.

Règles de codage
Se référer à la rubrique Conventions
Voir aussi
Sur programmer.spip.net
 la rubrique Étendre SPIP
Et le site sur la documentation du code de SPIP


SPIP 1.9.2
L'équipe de SPIP — 2007-02-22T20:44:45Z

		Les nouveautés marquantes de cette version sont :
 des filtres d'images plus nombreux, et optimisés ;
 de nouvelles fonctionnalités de sauvegarde et restauration ;
 un système de cache plus réactif ;
 l'introduction de la librairie javascript jQuery ;
 un nouveau schéma d'organisation des répertoires ;
 un validateur XML extensible ;
 une interface de programmation (API) pour la gestion des autorisations et des modifications ;
 des statistiques de fréquentation plus précises, attention, la brusque réduction des visites après l'upgrade est donc normale, un retour à des chiffres plus objectifs a été préféré.
27 Janvier 2008 : voir SPIP 1.9.2d
		
Sommaire
 Espace privé
 Espace public
 Version de correction 1.9.2a
 Version de correction 1.9.2b
 Version de correction 1.9.2c
 Version de correction 1.9.2d
 Version de Correction 1.9.2e
 Version de Correction 1.9.2f
 Version de Correction 1.9.2g
Plusieurs nouveautés concernent l'interface de programmation (API) de SPIP, c'est-à-dire la liste des fonctions mises à la disposition des programmeurs (notamment pour les plugins).
Cette nouvelle version s'apprécie donc aussi pour les nouveaux plugins qu'elle permet d'utiliser
(voir, entre autres, le plugin « crayons », qui permet d'éditer les articles directement sur le site public ; le plugin
de validation XHTML automatique, etc.)
Pour la migration d'un site existant vers cette nouvelle version stable, il est important de noter les points suivants :
 réorganisation des répertoires, et notamment déplacement de CACHE et de ecrire/data vers tmp/ ; des vignettes d'image vers local/ ; et des fichiers de configuration (mes_options.php, connect.php) vers config/ ;
 le répertoire ecrire/ ne contient donc plus que des scripts, et peut être partagé entre plusieurs sites (voir l'article sur la mutualisation) ;
 si vous utilisez les filtres d'image (et notamment image_reduire) un bug a obligé à rompre la compatibilité dans les noms des vignettes. SPIP devra donc recréer toutes les vignettes. Vous pouvez supprimer les vignettes présentes dans le répertoire IMG/
Voici une liste plus détaillée des nouveautés :
Espace privé
 conformité XHTML 1.0 Transitional de l'espace privé (et même strict, hormis quelques attributs Transitional sans équivalents exacts en Strict) ;
 de nouvelles icônes de documents ;
 statistiques téléchargeables au format CSV
 des statistiques plus correctes (un bug tendait à surestimer largement le nombre total de visites sur le site)
 génération automatique de vignettes (sous GD2) :
 détection de la taille maximale d'image manipulable, pour anticiper une erreur lorsque les images téléchargées sont trop grandes. Les grosses images sont conservées telles quelles ;
 cette détection est réalisée par un calcul unique (un peu gourmand) dans la page Configuration>Fonctions Avancées. Visuellement, une jauge affiche en vert le nombre maximal de pixels utilisés (en millions de pixels)
 téléchargement de documents/images :
 possible de télécharger un document dès la création de l'article ;
 le téléchargement ne fait pas perdre les modifications en cours dans l'édition du texte
 sauvegarde :
 sauvegarde facilitée : authentification supprimée, possibilité de choisir le nom de la sauvegarde afin d'en conserver plusieurs
 sauvegarde de la configuration du site et des plugins (à l'exception de ceux qui sont liés à la configuration du serveur)
 restauration fiable des anciennes versions ou créées par phpmyadmin (au format XML)
 restauration avec fusion au lieu d'écrasement, avec importation des logos ;
 restauration accélérée et corrigée sur son traitement des entités HTML.
Espace public
 Généralités
 validateur XHTML interne embarqué permettant de valider les pages produites par les squelettes (bouton Analyse XML)
 indenteur XHTML activable pour produire du code indenté
 la colonne d'ajout de documents est utilisable dans les squelettes [(#ID_ARTICLE|afficher_documents_colonne)]
 {critères}
 {fusion} : permet de regrouper les résultats d'une boucle SPIP selon les valeurs distinctes d'un champ (GROUP BY de sql)
 le critère {par}, dans son mode dynamique ({par #ENV{truc}}) tolère désormais truc=hasard
 critère {like} expérimental
 #BALISES
 #ARRAY{cle1,valeur1,cle2,valeur2...} permet de créer une variable tableau (utile pour affecter un tableau dans un #SET et/ou pour utilisation dans un critère IN dynamique)
 #EDIT{xxx} dans la class d'un élément entourant la balise #XXX permet de la rendre éditable à l'aide du plugin crayons (voir la documentation sur spip-contrib)
 #TOTAL_UNIQUE permet de ressortir le nombre d'éléments différents obtenus avec le filtre |unique
 #PIPELINE{nom_du_pipeline} permet, dans un squelette, d'afficher le flux d'un pipeline donné, issu d'un ou plusieurs plugins.
 #URL_ACTION_AUTEUR{action} affiche l'adresse de l'action « action » avec le nécessaire pour vérifier les autorisations du visiteur connecté. Cette balise accepte deux paramètres supplémentaires et facultatifs : une liste d'arguments et une adresse de redirection éventuelle.

 |filtres
 |concat{valeur1,valeur2,..} permet de concaténer plusieurs chaînes.
 |compacte permettent de réduire la taille d'une css ou d'un javascript en supprimant tous les commentaires. Le filtre prend en entrée le nom du fichier, et produit un nouveau fichier dont il renvoie le nom 
Il accepte un paramètre optionnel, le type du fichier lorsqu'il ne peut être déduit de l'extension comme ...|compacte{js}
 |date_822 : pour certains feeds RSS 2.0 (notamment photocast), il est nécessaire d'insérer la date au format RFC 822 ()
 |paragrapher pour toujours mettre des paragraphes HTML autour du texte (et pas seulement si ça contient au moins deux paragraphes).
 |url_absolue_css passe toutes les URL relatives d'une css en URL absolue (a utiliser avant compacte par exemple)

 améliorations : |direction_css conserve les images de background et se propage dans les @import
 Remaniement et homogénéisation des filtres images
 Tous les filtres image_xx respectent les attributs présents en entrée.
Ils modifient éventuellement :

- l'attribut src (par définition)...

- les attributs style, width et height si la taille change

- l'attribut class pour mettre ou enlever l'attribut format_png selon que l'image de sortie est au format png ou non
 Les filtres image suivants ont été ajoutés :

- |image_imagick{fonction_php_imagick, variables,...} permet d'appliquer n'importe quelle fonction de la librairie php_imagick : des filtres inédits jusqu'à présent dans SPIP ; il y en a de très impressionnants ; mais cela ne fonctionne que sur les images sans transparence alpha

- |image_recadre{largeur,hauteur,position} pour recadrer une image (le crop de Photoshop) avec les combinaisons de left/center/right et top/center/bottom pour la position (ex 'left center')

- |image_renforcement fait exactement le contraire de image_flou. A utiliser notamment sur les vignettes de prévisualisation, qui deviennent carrément plus belles.

- |image_select{largeur_min,hauteur_min,largeur_max,hauteur_max} permet de cibler les images qui subiront les filtres images à suivre. Utile pour faire par exemple [(#TEXTE|image_select{50,50}|image_masque{...})] dans deformer les icones de documents ou puces ...
Réorganisation des répertoires

 suppression de ecrire/data, plus de droit d'écriture dans ecrire nécessaire (connect.php passe dans config/ )
 tmp/ comporte tout ce qui est temporaire et non accessible par le navigateur (inclus cache/)
 local/ comporte tout ce qui est temporaire et accessible par le navigateur (inclus les vignettes d'image)
 IMG/ comporte ce qui est permanent et accessible par le navigateur
 config/ comporte ce qui est permanent et non accessible par le navigateur
API (interface de programmation, destinée aux développeurs)
 jQuery 1.1 inclus dans SPIP, chargé dans l'espace privé par defaut, et dans l'espace public si le squelette dispose de #INSERT_HEAD ; cette librairie javascript est documentée en français sur le site www.jquery.info
 Poursuite de la réorganisation du code pour séparer l'affichage des opérations sur la base de données, et pour faciliter la surcharge
 autoriser('voir'...) partout dans l'espace privé pour permettre le filtrage d'accès et l'ouverture de nouveaux droits de modification
 la fonction recuperer_page permet des appels SOAP en fournissant un $data du type string (headers+deux retour lignes+corps xml)
 API d'installation/désinstallation des plugins : les plugins qui gerent leur installation sont repérés visuellement par une icone
 les modèles peuvent utiliser du javascript qui restera actif, y compris dans l'espace privé
 le javascript dans les articles est désactivé dans l'espace privé, mais actif dans l'espace public (il est possible de modifier cette règle). Cela permet de programmer des comportements javascript ou jQuery directement dans les articles.
 annonce dans les entêtes HTTP des pages de la liste des plugins installés et de leur version (desactivable par $GLOBALS['spip_header_silencieux'] = true;)
Bugfix :

- MySQL 5 : Certaines configurations serveurs MySQL 5 posant problème, la constante _MYSQL_SQL_MODE_TEXT_NOT_NULL permet de contourner le bug, en attendant une refonte de la définition des tables ;

- le nom des vignettes issues de image_reduire pouvaient être identiques pour deux images sources différentes


Comme d'habitude, ces améliorations seront rapidement intégrées au reste de la documentation officielle, avec des exemples détaillés. En attendant n'hésitez pas à solliciter la liste des utilisateurs !


Version de correction 1.9.2a
SPIP 1.9.2a est parue le 14 mars 2007
Cette version [8878] n'apporte pas de nouveautés, elle fixe essentiellement des bugs :
- éviter un crash de Safari et divers bugs sous IE et FF (dans des sites dont l'url contient un ~) lors de l'upload de documents

- compatibilité avec les nouvelles versions de php (4.4.6) et en particulier PCRE

- éviter une erreur chez free avec le filemtime sur les fichiers inexistants

- raccourci hors du bloc des raccourcis (exec=articles_page)

- rectification de l'interface permettant de 'liberer les articles'

- Les visiteurs et les auteurs à la poubelle n'ont pas accès la messagerie interne.

- ne pas construire de vignettes vide si on n'a pas pu récupérer le fichier distant

- imprécisions sur les revisions anonymes

- colonne document dans les breves

- meilleure heuristique pour chercher la version svn

- cache pour exécution des squelettes dans l'espace privé

- précisions filtres robots d'indexation

- divers nettoyages de code et réglages css

Version de correction 1.9.2b
SPIP 1.9.2b est parue le 23 mai 2007.
Cette version [9381] n'apporte pas de nouveautés, elle répare essentiellement des bugs :

- lien [bla{blabla}->url] était cassé, sauf dans le cas ou on avait un hreflang

- plusieurs corrections dans calendrier

- toujours un effort pour rendre SPIP xhtml compliant

- ¡ qui apparaissait lors d'une restauration en espagnol

- renforcement vis à vis des PREG défaillants de PHP-4.4.6

- langue d'accueil fixée par le visiteur lors de l'installation

- règle les float sans largeur fixée après passage dans win_png.htc sur IE 
- syntaxe incorrecte dans l'installation LDAP

- rafraichissement des documents après téléchargement dans IE et Opera

- fonction import_identifie_id_type() en double

- sécuriser l'argument de parametre_url

-  etait cassée

- mauvais include pour des erreurs de squelettes

- crash dans autoriser si spip_query() n'a pas encore été chargée

- upgrade partiellement défaillant sur des vieilles versions

- images impossibles à associer à l'article si les documents sont interdits

- mauvais enregistrement des révisions partielles (avec les crayons par exemple)

- le filtre couper() crashait sur une note de bas de page de plusieurs lignes vers le début du texte

- fixe SQL auteur dans certains autoriser()

- (et, dernière minute) une correction d'un bug lors de la restauration des gros dump (reprise apres timeout)

Version de correction 1.9.2c
SPIP 1.9.2c est parue le 19 Septembre 2007.
Cette version apporte une correction critique d'une faille de sécurité. Elle apporte aussi un certain nombre de corrections et d'améliorations :
 Corrections :
 Restauration : reprise sur timeout et déconnexion,
 Messagerie interne : envoi du mail de suivi des discussions,
 Date de rédaction antérieure : contournement d'un bug IE empêchant la
modification,
 menu des rubriques (gadget tout le site) : arborescence incomplète
dans certains cas,
 fiche auteur : bug en modification de l'url du site,
 filtres images : bug sur aplatissement en gif,
 barre typographique : bug d'affichage,
 #URL_LOGOUT : suppression des &amp; et redirection vers la page en cours (self) par défaut,
 #LOGIN_PUBLIC : accepte les visiteurs.
 Améliorations :
 support JQuery 1.1.4 (la version intégrée restant la 1.1.1) et quelques correctifs,
 Fonction image_aplatir : prend un 3eme paramètre "qualité" (85 par défaut pour les jpg, nombre de couleurs de la palette pour gif et png),
 Mot de passe : Peut contenir des ' et des \,
 articles_tous et brouteur : optimisation des requêtes (surcharge MySQL
pour les gros sites),
 Ajout des extensions csv, mkv, mka, kml et kmz.

Version de correction 1.9.2d
SPIP 1.9.2d est parue le 27 Janvier 2008.
Cette mise à jour concerne exclusivement des corrections de bugs. Le
passage à cette version est conseillé, et ne doit entrainer aucun
impact fonctionnel pour les visiteurs de votre site si vous utilisez
déjà une version 1.9.2 (a,b ou c)
Pour les rédacteurs et administrateurs :
 correction d'une incohérence dans la gestion de date des documents
(date/heure a la création puis date seulement)
 correction d'un bug sur le menu de rubriques qui en masquait
certaines (ticket #1113)
 éviter une erreur javascript au début du chargement de la page
lorsque l'on bouge la souris trop vite
 la configuration graphique et l'adresse du site ne sont pas
écrasées lors de la restauration d'une sauvegarde, car liées au serveur
 affichage correct des captures d'écran successives dans les
statistiques
 ajout de la traduction en indonésien
 correction d'un bug sur les droits de modification des sites
syndiqués par les administrateurs restreints
 correction d'une série de bugs relatifs à la gestion des droits sur
les logos
 correction d'un bug sur la requête sql du navigateur de rubriques
qui le rendait inutilisable sur les gros sites (et tri des rubriques
par num titre, titre)
 correction d'un bug qui autorisait un
administrateur restreint à déplacer un article publié dans une rubrique dont il n'est pas administrateur.
D'un point de vue plus technique, pour les développeurs de plugins :
 remplacer la constante _INC_PUBLIC par la globale _INC_PUBLIC et l'incrémenter lors des inclusions pour que le plugin balise session fonctionne correctement (notamment sa gestion de cache reportée de la version en cours de développement)
 amélioration de la purge du cache dans le CRON (la purge pouvait ne jamais réussir après le passage d'un robot, et saturer les ressources serveurs à essayer de calculer la taille du cache)
 url_de_base peut être appelée depuis mes_options
 Correction d'un include manquant qui pouvait faire échouer la
fonction autoriser_voir_dist
 recuperer_page prend correctement en charge les urls du type https (si php a été compilé avec le support de ssl)

Version de Correction 1.9.2e
Cette version a été publiée le 13 septembre 2008 (révision [12624]).
Elle apporte quelques corrections de bugs mineurs et des adaptations techniques.
 Les expressions régulières sont désormais compatibles avec la version 5.2.6 de PHP (C'est LA correction principale)
 Correction de la mise en évidence des résultats de recherche sur deux mots ou plus
 Correction de l'indexation des forums
 Chaque message peut être indexé individuellement, plutôt que le fil complet
 Correction d'un bug de l'espace privé (cas de mots clés multiples séparés par des virgules)

Version de Correction 1.9.2f
Cette version a été publiée le 7 décembre 2008 (révision [13408]).
Elle apporte quelques corrections de bugs mineurs :
 Corrige le bug de fake HTTP_X_FORWARDED_HOST (#401)
 Correction d'orthographe pour l'ukrainien
 Protection des urls de redirection
 Optimisation des requêtes SQL, permet d'utiliser le cache des requetes de MySQL (idée de Thomas Radio France et Fabrizio Pix-L)
 Correction des conflits d'édition des SELECT MD5
 Amélioration du tri {par multi titre}

Version de Correction 1.9.2g
Cette version a été publiée le 24 décembre 2008 (révision [13534]).
 Correction d'orthographe pour l'asturien
 Protection de l'argument fournit au calcul de branche (Julien Cayssol)
 Correction d'une perte de date de l'agenda dans les calculs
 Rejet des urls avec le pseudo protocole data : dans la fonction de redirection redirige_par_entete
Pour plus de détails : historique de la branche 1.9.2 sur trac


Où placer les fichiers de squelettes ?
L'équipe de SPIP — 2006-08-30T13:34:06Z
Les squelettes sont rangés dans un dossier dédié, nommé squelettes-dist/.

Le dossier squelettes/ accueillera vos squelettes personnalisés.
		
Sommaire
 Les squelettes par défaut : squelettes-dist/
 Votre dossier squelettes/
 Utiliser un autre dossier de squelettes
 Priorité des dossiers de squelettes
Le code de SPIP et de la structure du site sont ainsi clairement séparés avec par exemple, la possibilité de changer tout un ensemble de squelettes d'un seul coup.
Les squelettes par défaut : squelettes-dist/
Les squelettes de la distribution — c'est-à-dire ceux fournis en standard à l'installation de SPIP — sont regroupés dans un unique répertoire. Ces fichiers contiennent les informations sur la mise en page par défaut du site et ne doivent pas être modifiés. Vous pouvez examiner le contenu de ce répertoire et partir de ce jeu de squelettes pour adapter la mise en page à vos besoins [1].
Toutefois, il ne faut pas modifier les squelettes de la distribution, sinon vous risqueriez de perdre toutes vos modifications à chaque mise à jour de SPIP !
Pour éviter cela, faites une copie des fichiers que vous souhaitez modifier, et placez-les dans un autre répertoire, comme indiqué ci-après.
Votre dossier squelettes/
Les squelettes personnalisés doivent être rangés dans un répertoire nommé squelettes/ (attention au « s » final !), que vous créerez à la racine de votre site SPIP. Que vous souhaitiez installer un jeu complet de squelettes (pris sur SPIP - Contrib ou ailleurs), ou apporter une légère modification aux squelettes par défaut, placez vos squelettes dans ce répertoire.
Ainsi, un utilisateur qui veut créer sa propre mise en page, développera ses propres fichiers article.html, rubrique.html, etc. dans le répertoire squelettes/. Notez bien qu'il n'est pas indispensable de placer un jeu de squelettes complet dans ce répertoire.
Pour afficher les pages du site, SPIP cherche les squelettes prioritairement dans le dossier squelettes/ ; si SPIP n'y trouve pas un fichier .html qui lui est nécessaire, il ira chercher celui de la distribution dans le dossier squelettes-dist/.
Ainsi, si vous n'avez placé qu'un seul fichier dans le dossier squelettes, par exemple article.html, SPIP utilisera ce squelette pour afficher les articles, et ceux de la dist pour toutes les autres pages du site.
Le dossier squelettes/ est destiné à recevoir tous les fichiers nécessaires à la mise en page d'un site. On y rangera donc :
 les squelettes, c'est-à-dire les fichiers .html avec du code SPIP ;
 les fichiers inclus dans les squelettes et les modèles ;
 les formulaires modifiés, dans un sous-répertoire formulaires/
 les feuilles de style CSS qui produisent l'habillage graphique ; les personnaliser permet en effet de varier, parfois spectaculairement, l'habillage d'un site sans intervenir dans les squelettes. Voir : « Mettez-y votre style ! » ;
 les images utilisées dans les squelettes ;
 le fichier mes_fonctions.php contenant les filtres et variables de personnalisation propres à ce jeu de squelettes ;
 les fichiers javascripts ;
 les fichiers de langue personnalisés (cf. : « article 2128 », méthode des fichiers de langues), dans un sous-répertoire lang/ ;
 etc...
Utiliser un autre dossier de squelettes
Il est possible de ranger les squelettes dans un répertoire portant le nom de votre choix, en le déclarant dans le fichier mes_options.php, avec la variable de personnalisation $GLOBALS['dossier_squelettes'], comme expliqué dans la documentation correspondante. SPIP ira chercher les squelettes en priorité dans le répertoire ainsi déclaré.
Cela vous permet, par exemple, d'essayer un nouveau jeu de squelettes sans écraser l'ancien, ou de gérer dynamiquement plusieurs jeux de squelettes.
Vous pouvez indiquer plusieurs dossiers, avec le caractère : comme séparateur.
Exemple : lorsque $GLOBALS['dossier_squelettes']='surcharge:mesquels:tests, les squelettes du dossier 'surcharge' sont prioritaires, puis ceux de mesquels puis ceux de tests.
Priorité des dossiers de squelettes
Soyons plus exhaustifs et résumons. Grosso modo, lorsque SPIP doit utiliser un fichier, il le cherche dans différents répertoires dans l'ordre suivant :
 en premier lieu dans la liste de dossiers désignés dans la variable $GLOBALS['dossier_squelettes'], si celle-ci est définie ;
 ensuite dans le dossier squelettes/ situé à la racine du site ;
 puis dans la liste de dossiers de la variable $plugins ;
 ensuite à la racine du site ;
 dans le répertoire squelettes-dist/ ;
 et enfin dans le répertoire ecrire/.
« Grosso modo », car à cela s'ajoutent quelques subtilités [2], dont un ordre de priorité par fichier de squelette, qui permet des variantes plus fines : par rubrique, par branche ou par langue, comme expliqué dans la documentation correspondante.

Remarque : En fait, le mécanisme décrit ci-dessus pour choisir l'emplacement d'un fichier ne s'applique pas seulement aux squelettes, mais aussi à l'ensemble du code de SPIP. Dans le jargon du developpment on parle de « surcharger du code », l'ordre de choix des dossiers étant dans le « SPIP_PATH ».
Cela met en place le cadre et les normes pour le développement des « plug-ins », extensions des fonctionnalités de SPIP que tout les membres de la communauté peuvent apporter.
Ainsi, on peut modifier n'importe quelle caractéristique du comportement de SPIP. Attention toutefois à ne pas se priver des évolutions de la distribution et du support de la communauté.

		
		
[1] C'est même une méthode vivement conseillée, car ce jeu de squelettes a été pensé pour être aussi modulaire que possible.

[2] Comme une nomenclature des fichiers en fonction de leur rôle, ce qui fait, par exemple, que SPIP ira chercher les fichiers de langue dans un sous répertoire lang/, comme nous l'avons vu plus haut.



SPIP 1.9.1
L'équipe de SPIP — 2006-08-29T22:31:39Z

		SPIP 1.9.1 est sorti !
Voici les principales nouveautés de cette version.
		
Sommaire
 Espace privé
 Un système de modèles
 Nouvelles balises
 Filtres
 Utilisateurs avancés
 Correctifs
 * * *
Espace privé
L'espace privé intègre de manière plus importante la technique de mise à jour asynchrone (AJAX/AHAH) d'une partie de la page. Les formulaires de descriptions d'images et de documents deviennent très fluides, la rotation des images, l'ajout de mots-clés ou d'auteurs, les références aux traductions sont également plus rapides.
Un système de modèles
Les modèles sont des mini-squelettes qui peuvent s'intégrer facilement dans un squelette normal mais aussi — et surtout — dans le texte des articles (ou brèves, etc).
Ils sont une extension naturelle des raccourcis , . Ceux-ci sont d'ailleurs désormais gérés par ces mini-squelettes ; vous pouvez définir les vôtres dans le sous-répertoire modeles/ de votre dossier de squelettes (ou d'un plugin).
Outre les raccourcis de document et d'image, les modèles proposés dans dist/modeles/ gèrent l'affichage des liens de pagination, de la balise #LESAUTEURS et des liens de traduction.
Les modèles sont plus largement documentés dans l'article « Utiliser les modèles ».

Nouvelles balises
 #SPIP_VERSION affiche la version de SPIP.
 #INSERT_HEAD : une balise a insérer dans la zone ... de vos squelettes pour permettre aux plugins d'ajouter automatiquement des css ou des javascript.
 #INCLURE : une nouvelle balise pour des inclusions « statiques » et non plus dynamiques.

Rappel : La syntaxe  provoque l'inclusion des pages à chaque visite d'un internaute, que celle-ci concerne une page déjà en cache ou non.
Avec la nouvelle balise [(#INCLURE{fond=...})], l'inclusion est réalisée lors du calcul du squelette, et son résultat est stocké dans le cache de la page appelante. Avec ce système, on ne peut plus gérer une durée de vie ($delais ou #CACHE{}) réduite pour un squelette inclus ; en revanche il devient possible d'appliquer des filtres sur le squelette inclus : [(#INCLURE{fond=lettre}|version_texte)].
NB : le résultat de l'inclusion étant stocké en cache, il ne faut donc pas que l'#INCLURE contienne d'éléments dynamiques, en particulier pas de balise #FORMULAIRE_XYZ.
 La pagination passe en « modèle » (cf. ci-dessus), ce qui permet sa personnalisation au moyen de modèles personnalisés. Ainsi :
 #PAGINATION{page} donne des numéros de page (1, 2, 3, 4...) au lieu des numéros d'item (0, 10, 20, ...) ;
 on peut aussi essayer #PAGINATION{page_precedent_suivant} et #PAGINATION{precedent_suivant}.
 Introduction d'une balise #SQUELETTE donnant le chemin du squelette courant.
Filtres
Enrichissement de image_masque :
 le placement vertical et horizontal du masque peut se faire désormais avec :
 text-align=center (ou left, ou right)
 vertical-align=middle (ou top, ou bottom)
 Désormais on peut choisir le mode de mélange des deux images, à la façon d'un logiciel comme Gimp. Par défaut, si on ne précise rien, on a : mode=masque qui est le fonctionnement déjà connu.
Les nouveaux modes sont :
 mode=normal : on place l'image par dessus l'autre ;
 mode=eclaircir : on place uniquement les pixels plus clairs ;
 mode=obscurcir : on place uniquement les pixels plus foncés ;
 mode=produit : on « multiplie » les pixels d'origine par les pixels du masque. De fait : les points noirs rendent l'image noire, les points blancs la laissent inchangée ;
 mode=difference : on remplit avec la différence entre les deux images.
Extension des filtres image au texte :
Tous les filtres d'images peuvent être appliqués sur un fichier d'image, un tag  ou un texte complet (les filtres étant appliqués alors sur chaque image trouvée). Il devient donc possible de faire [(#TEXTE|image_sepia)]
D'autres filtres ont été introduits... liste à compléter.
Utilisateurs avancés
Dossier formulaires/ : 
les formulaires personnalisés (pour la partie html) doivent maintenant être placés dans un sous-dossier formulaires/ de votre dossier de squelettes (ou de votre plugin). La partie php du formulaire peut, pour sa part, être personnalisée dans le dossier balise/ du dossier de squelettes (ou du plugin).
Calculer un fond depuis l'espace privé :
pour les développeurs de plugins, une fonction recuperer_fond permet maintenant de calculer un squelette, y compris depuis un script de l'espace privé. C'est ce système qu'utilisent aussi bien la balise #INCLURE que le système des modèles.
Variables dans le squelette
De nouvelles balises apparaissent, qui permettent de faire des calculs à l'intérieur des squelettes et d'affecter leur résultat à une « variable », laquelle peut ensuite être utilisée par ailleurs dans le même squelette : #SET{toto, valeur} et #GET{toto}.
Rechargement partiel de page (experimental) :
toute boucle peut définir un fragment de squelette rechargeable dynamiquement de facon asynchrone par le navigateur (ahah). Pour cela, il suffit d'utiliser le critère {fragment} sur la boucle considérée. Le critère {pagination} implique par défaut le critère {fragment}. Tout le contenu de la boucle (parties avant, principale, après ou alternative) est inclus dans un div portant la class fragment, et un id unique : 

 ...
En appelant l'url avec le paramètre supplémentaire var_fragment ayant pour valeur l'id d'une div fragment (ex : &var_fragment=fragment_html_1c4f894574d730e016e980d91fa678ca_articles), le serveur ne retournera que ce fragment du squelette. Ainsi il est facile de recharger seulement une partie du squelette avec du javascript (AJAX/AHAH).

Remarque :
Cette fonctionalité est encore expérimentale et évoluera probablement dans les futures versions. Nous vous encourageons tout de même à l'essayer et donner vos impressions ou proposer du code d'amélioration pour cette fonction.

Mode tidy :
Le mode XHTML Tidy (voir article 3070) n'est plus fourni en standard avec SPIP, et passe en plugin. Pour trois raisons :
 ce code repose sur l'appel à un binaire pas souvent disponible chez les hébergeurs — son mode php_tidy n'est toujours pas totalement fonctionnel ;
 le moteur de SPIP compose désormais en standard un code XHTML beaucoup plus satisfaisant, réduisant l'intérêt de ce système ;
 le débusqueur (ajouter &var_mode=debug dans l'URL de la page) offre un mode de validation signalant les balises invalides ainsi que les lignes du squelette qui les ont produites (ajouter $xhtml='spip_sax'; dans mes_options.php pour en bénéficier).
Documentation du code :
Une documentation du code a été mise en place sur http://doc.spip.org

- chaque fonction y est réferencée de facon automatique, et l'hypertexte fonctionne dans les deux sens (du code vers sa doc et vice-versa) ;

- le site est mis à jour quotidiennement en fonction des modifications du code de la version de développement (SVN) de SPIP.
Correctifs
De nombreux bugs ont été corrigés (notamment sur la syndication, le cache des images typographiques, le menu de langues), pour plus de détails voir notre site de développement http://trac.rezo.net/trac/spip/report/6.
Compatibilité avec les hébergements free et club-internet.
 * * * 
Si vous faites une mise à jour de votre site depuis une version ancienne de SPIP, lisez aussi l'article sur SPIP 1.9.
A lire également :

— Effectuer une mise à jour

— article 3370
Comme d'habitude, en cas de difficulté vous trouverez de l'aide sur la liste spip@rezo.net ou sur les forums de SPIP

répertoire	rôle
`/`	contient les squelettes. Leur nom se termine par `.html` pour des raisons historiques mais cela ne préjuge pas de leur contenu. Il sufit de donner un tel nom, privé de cette extension, au paramètre `page` de l'URL d'un site sous SPIP pour déclencher l'utilisation de ce squelette. Ce répertoire contient également les feuilles de styles (d'extension `.css`) définissant l'habillage par défaut
`formulaires/`	contient la partie html des balises dynamiques, squelettes de formulaires dont le code PHP figure dans le répertoire `ecrire/balise`
`images/`	images de l'espace privé
`javascript/`	librairies javascript (jQuery, barre typographique, ...)
`modeles/`	squelettes appelables avec la balise #MODELE ou avec les raccourics
`polices/`	polices utilisables pour les images typographiques
`vignettes/`	vignettes standards pour les types de documents pouvant être associés à un article