SPIP 1.9

1. L’espace public

Nouveaux squelettes standards

Les squelettes par défaut ont été rafraîchis, et respectent mieux les standards W3C et les critères d’accessibilité. Leur navigation a été repensée. Les feuilles de style CSS ont été simplifiées pour faciliter la personnalisation de l’habillage (traité dans cette rubrique).

Ces squelettes sont construits avec des inclusions : trois pour le menu de navigation par rubriques, l’entête et le pied de page, qui sont répétés sur chaque page, et deux autres pour les forums et les signatures de pétitions.

Les formulaires de SPIP ont aussi été remaniés pour améliorer leur accessibilité et faciliter leur habillage graphique ; voir : « Ils sont beaux, mes formulaires ! »

Syndication avancée

Les squelettes des flux de syndication (backend) passent au format RSS 2.0. Un réglage, dans la configuration du site, permet de préciser si l’on veut diffuser tout le contenu de nos articles dans ces flux RSS, ou seulement un résumé. Le flux de syndication comporte aussi des informations sur la rubrique de l’article ainsi que sur les mots-clés et les fichiers qui lui sont associés (podcasting). En lecture, lorsque votre site sous SPIP syndique un autre site disposant d’un flux enrichi, il sait aussi analyser ces données. Lire l’article La syndication de contenus.

Formats de documents supplémentaires

Le format SVG (Scalable Vector Graphics), interprété en natif par FireFox et Opera depuis peu, est admis comme nouveau type document intégrable dans un texte (via le raccourci <emb1>). Ce format incorporant du javascript, son chargement est sécurisé de la manière suivante :
-  en cas de chargement par un simple rédacteur, SPIP purge le document de tout code javascript et de toute référence à un fichier javascript ;
-  en cas de chargement par un administrateur, SPIP accepte le document tel quel.

D’autres formats sont aussi pris en compte : Abiword (abw), Blender (blend), Flash Video (flv), polices de caractères truetype (ttf), ainsi que l’ensemble des formats de type « open document » (OpenOffice.org).

Adresses des pages

Les fichiers article.php3 etc., qui étaient installés à la racine du site pour appeler le squelette article, ne sont plus nécessaires et ont donc disparu.

Ces fichiers n’apparaissent donc plus dans les URLs par défaut (qui s’appellent désormais « urls page » et sont de la forme /spip.php?article12 (pour l’article numéro 12) ou encore /spip.php?page=plan (pour.. le plan !).

Si un squelette xxx nécessite des fonctions ou autres supplémentaires qui étaient anciennement placées dans ce xxx.php3, les placer dans squelettes/xxx_fonctions.php, par exemple pour article dans squelettes/article_fonctions.php

À noter :
-  un fichier htaccess.txt est fourni pour permettre aux visiteurs (et moteurs de recherche) qui connaissent ces anciennes adresses d’être correctement servis. Chez la plupart des hébergeurs il suffit de recopier ce fichier sous le nom .htaccess (fichier invisible) pour l’activer. Ce fichier permet par ailleurs de servir les autres modes de gestion des adresses des pages (« URLs propres », etc).
-  dans le cas d’une migration, si vous laissez les anciens fichiers article.php3 etc à la racine, ils continuent à fonctionner grâce au fichier fantôme inc-public.php3 — mais attention cette compatilibité disparaîtra avec la version suivante de SPIP.
-  la gestion de la durée de validité du cache (variable $delais) est à présent confiée à la balise #CACHE qui s’inscrit directement dans le squelette (la variable $delais continue toutefois à fonctionner si elle est présente).

Pour choisir un autre mode de gestion des adresses il reste toujours possible de modifier la variable $type_urls dans le fichier ecrire/mes_options.php.

Fichiers php ou php3 ?

De manière générale, tous les fichiers .php3 sont à présent nommés .php, mais les anciens noms sont toujours compris de SPIP, ce qui fait que vos fichiers personnalisés (mes_fonctions.php3, ecrire/inc_connect.php3 ou ecrire/mes_options.php3) sont toujours pris en compte.

Ce ne sera plus le cas avec SPIP 2.0 : pensez donc à renommer ces trois fichiers dès aujourd’hui.

Compatibilité : SPIP nécessite une version de php supérieure à 4.0.8, et est compatible avec les versions 5.x. Sa compatibilité avec MySQL 4 et 5 a été revue et améliorée.

Filtres graphiques

Une importante collection de nouveaux filtres permet d’appliquer des traitements graphiques aux images.

Ils nécessitent la présence de GD2 sur le serveur.

Certains filtres concernent la couleur (passer en noir et blanc, en sépia, foncer, éclaircir...), d’autres la rotation, permettent de flouter, d’appliquer un effet de miroir, rendre semi-transparent, appliquer un « masque » de transparence, etc.

Un article présente l’ensemble de ces nouveaux filtres de traitement graphique.

Le filtre |couleur_extraire permet d’extraire une couleur d’une image (logo, document joint...) pour l’appliquer à d’autres éléments de la page (blocs de couleurs, style CSS, image typographique, etc.). On peut ainsi automatiser des variations de couleurs entre les différentes pages du site, tout en conservant un certaine cohérence graphique.

Une série de filtres permet ensuite de modifier cette couleur (éclaircir, foncer, etc.) pour créer une palette de couleurs complète. Un article présente l’utilisation de ces filtres sur les couleurs d’images.

De même, apparaît le filtre |image_typo qui permet de créer des images typographiques, c’est-à-dire des images représentant du texte avec une police de caractères disponible sur le serveur, garantissant une présentation uniforme sur tous les navigateurs dont les polices particulières ne sont alors pas sollicitées. Un article présente l’utilisation complète du filtre image_typo. Outre GD2, ce filtre requiert la présence de Freetype sur le serveur (il est le plus souvent installé avec GD2).

Amélioration de la réduction d’images

Dans la configuration du site, onglet « Fonctions avancées », il est vivement conseillé de sélectionner la méthode GD2 (si elle est disponible sur le serveur, évidemment). En effet, la réduction réalisée avec cette méthode est désormais beaucoup plus précise : elle conserve les zones transparentes des images GIF et PNG.

Le filtre |reduire_image devient |image_reduire (tous les filtres de traitement d’image commencent ainsi tous par |image_). L’ancienne dénomination est toujours disponible.

Un nouveau filtre, |image_reduire_par réduit les dimensions d’une image selon un certain facteur (par exemple : |image_reduire_par{2} réduit les dimensions de l’image par deux).

Nouvelles balises

• #CACHE. Les $delais des pages peuvent désormais être fixés dans les squelettes eux-mêmes, avec #CACHE{duree} (à noter : on peut indiquer ici, comme avant, une expression du style 24*3600). Cette nouvelle écriture a comme avantage supplémentaire de produire également une entête HTTP prévenant le client que la page ne changera pas pendant un certain intervalle de temps.
• #HTTP_HEADER permet de définir les en-têtes HTTP des pages. Exemple #HTTP_HEADER{Content-Type: text/css}. IMPORTANT : le fait d’utiliser cette balise provoque la suppression par SPIP des boutons d’administration : cela remplace donc l’ancienne variable globale $flag_preserver, qui sera abandonnée pour SPIP 2.0.
• #CHEMIN{fichier} (améliore #DOSSIER_SQUELETTE). #CHEMIN{xxx} donnera le chemin complet vers le fichier xxx, qu’il se trouve à la racine, dans le dossier des squelettes, dans dist/ etc.
• #DESCRIPTIF_SITE_SPIP renvoie, comme son nom l’indique, le descriptif du site, que l’on renseigne dans la page de configuration générale du site. Utile pour les balises meta.
• Modification de #LOGO_SITE_SPIP : désormais distinct du logo par défaut des rubriques (rubon0.jpg), #LOGO_SITE_SPIP renvoie maintenant le logo du site (siteon0.jpg). Le logo de site est ajouté, comme le le titre et le descriptif du site, dans la page de configuration générale du site.
• Sites syndiqués : création des balises #SOURCE et #URL_SOURCE qui permettent d’afficher respectivement le nom et l’adresse de la source originale d’un contenu syndiqué via un portail. Dans les contenus syndiqués, la balise #TAGS affiche sous forme de microformats les liens vers les documents joints, les mots-clés et la rubrique.
  Pour plus de détails lire La syndication de contenus.
• la balise technique #CONFIG permet d’afficher la valeur d’un réglage stocké dans la table spip_meta
• très technique aussi, #EVAL{} évaluera l’expression PHP mise entre accolades. #EVAL{2*7} donne donc 14, #EVAL{_DIR_IMG_PACK} donne ainsi le chemin vers le répertoire ecrire/img_pack/ (à utiliser avec modération)
• Une notation simplifiée est désormais disponible pour les INCLURE où l’on ne précise plus que le nom du squelette à inclure, sous la forme <INCLURE {fond=squelette2} {id_article}>. (Note : il n’est pas encore décidé si cette notation aboutira à terme à un stockage « interne » du morceau ainsi inclus dans le fichier cache de la page courante.)
• en matière de sécurité, il est désormais possible de désactiver totalement les filtres de sécurité sur une balise en lui appliquant une double étoile (exemple : [(#TEXTE**)] permet de compiler du php inséré dans un article — si vous laissez cette possibilité telle quelle dans un squelette vous vous exposez aux pires ennuis).
• les balises avec arguments, c’est-à-dire suivi d’une paire d’accolades, bénéficient d’une écriture allégée, les crochets et parenthèses n’étant plus obligatoire : on peut ainsi écrire #EXPOSE{rouge} au lieu de [(#EXPOSE{rouge})].

Pagination automatique des boucles

Un système générique de pagination des résultats d’une boucle est intégré : il utilise le critère {pagination} (qui peut prendre en argument le nombre d’éléments à afficher sur une page : {pagination 5}) et les balises #PAGINATION et #ANCRE_PAGINATION. Les squelettes par défaut regorgent d’exemples de pagination (lire l’article de documentation Le système de pagination). A noter, ce système est incompatible avec la contrib’ qui a largement défriché le sujet.

Critères

• Le critère {inverse} peut prendre en paramètre n’importe quelle balise pour varier dynamiquement le sens du tri. Il est possible d’écrire : <BOUCLE_exemple(ARTICLES){par #ENV{tri}}{inverse #ENV{senstri}}>, ce qui permet de choisir la colonne de tri et le sens du tri par l’url (&senstri=1 ou &senstri=0)
• la possibilité de rendre conditionnel un critère ({lang?}>) est généralisée et bénéficie d’une compilation soignée, évitant de provoquer une jointure lorsqu’il est finalement absent.
• le critère {xxx IN 1,2,3} accepte à présent qu’un tableau de valeurs lui soit passé par l’URL (voir définition du critère IN).

Meilleure gestion du cache

Le fichier cache ne dépend plus seulement de l’URL de la page, mais aussi du nom de domaine, de la valeur de $dossier_squelettes ainsi que de la valeur d’une variable globale nommée $marqueur, que l’on peut fixer librement. Cela permet, entre autres, de changer de squelette « à la volée » tout en bénéficiant du cache (personnalisation, fonctionnalité « var_skel »...).

Egalement, le fichier cache n’est plus compressé s’il est léger (< 16 ko) pour gagner un peu en efficacité sur les squelettes ayant beaucoup de (petites) inclusions.

Langue et caractères

-  SPIP s’installe désormais par défaut dans le jeu de caractères « universel » utf-8. Il propose un bouton, dans l’espace privé, pour convertir votre site dans ce jeu de caractères (ça n’a rien d’obligatoire).

Pour faciliter cette conversion, si vos squelettes comportent des caractères accentués, ils seront convertis à la volée (au moment du recalcul de la page) dans le jeu de caractères spécifié pour le site.

-  Une nouvelle langue est proposée : le bosnien.

-  Un filtre |direction_css permet d’« inverser » un fichier CSS pour les langues s’écrivant de droite à gauche. Si la css à inverser s’appelle par exemple style.css, ce filtre utilise (dans le cas où la langue courante s’écrit de droite à gauche) une éventuelle feuille style_rtl.css ; si celle-ci n’existe pas, il crée automatiquement une feuille RTL en remplaçant toutes les occurrences de left par right et vice-versa (et la stocke dans le répertoire IMG/cache-css/). Il s’applique le plus souvent sur une balise #CHEMIN : [(#CHEMIN{style.css}|direction_css)].

2. L’espace privé et l’administration

Introduction d’AJAX

L’espace privé intègre, de manière expérimentale (certaines fonctionnalités ne sont pas actives dans MSIE), des éléments de navigation AJAX (ou plutôt AJAH, les éléments HTML sont fabriqués directement par le serveur). Ceux-ci autorisent une navigation plus riche sans recharger l’intégralité de la page. Ces formes de navigation sont destinées, essentiellement, aux « gros » sites (c’est-à-dire comportant de nombreuses rubriques et articles).

À partir d’un certain nombre de rubriques, le menu déroulant permettant de sélectionner dans quelle rubrique se trouve l’élément courant (par exemple un article) devient un petit navigateur en quatre colonnes affichant la structure du site :

Ce petit navigateur, outre une navigation plus claire dans la structure du site, propose son propre moteur de recherche.

Les listes d’éléments (notamment d’articles) profitent d’AJAX de deux manières :
— lorsqu’il y a de nombreux éléments, l’affichage de 10 en 10 (articles 1 à 10, puis 11 à 20, etc.) se fait sans recharger l’intégralité de la page, seule la liste est réaffichée ; le petit bouton « Plus » en haut à droite permet d’afficher l’intégralité de la liste, également sans recharger toute la page ;
— sur les articles, lorsque le site est multilingue, le sigle « Microphone » marquant le multilinguisme fait basculer l’affichage de la liste dans un mode permettant de suivre l’état des traductions.

Rapidité d’affichage

L’affichage de l’espace privé était très lent sous Internet Explorer 6 ; un code spécifique a été développé pour ce navigateur qui obtient désormais un affichage comparable en terme de rapidité à ce qui est obtenu avec les autres navigateurs. Que cela ne vous dissuade pas de passer à FireFox !

Par ailleurs la compression des pages a été desactivée dans l’espace privé pour permettre un rendu final plus rapide.

Refonte du statut des administrateurs restreints

Ce statut souffrait de quelques incohérences et a été entièrement revu. Pour profiter pleinement de ses nouvelles attributions, il est préférable que ce statut s’applique exclusivement aux secteurs (les rubriques de premier niveau) quoique son application sur d’autres rubriques reste possible.

Les administrateurs restreints peuvent à présent gérer les forums de leurs secteurs, télécharger des documents par FTP à partir du répertoire upload/login, procéder à une sauvegarde XML de leurs rubriques (sauvée dans ce même répertoire), visualiser les statistiques. Sur la page d’accueil de l’espace privé, un cartouche en haut à droite fournit les liens directs aux rubriques qu’ils administrent, et symétriquement la page d’accueil d’une rubrique indique dans un cartouche semblable la liste des administrateurs restreints de la rubrique.

A l’inverse, les possibilités transversales à l’administration d’une rubrique (création de mots-clés, ouverture de compte, vidage de cache) ne leur sont pas accessibles (certaines l’étaient, plus ou moins facilement) afin que les administrateurs puissent maîtriser l’évolution du site (éviter les mots-clés quasi-identiques, connaître les nouveaux rédacteurs).

Amélioration du système de sauvegarde

Le système d’import / export de tables SQL au format XML tient compte à présent des tables externes. Il est également plus robuste face aux interruptions du processus de sauvegarde lorsque la base est volumineuse, et il affiche la progression plus souvent.

La restauration est accélérée elle aussi, et elle est plus robuste vis a vis des fichiers de sauvegardes des anciennes versions de SPIP. Elle permet de restaurer directement une sauvegarde XML réalisée avec phpmyadmin.

Amélioration de l’indexation

Le code a été réécrit de façon générique pour prendre en compte toute table déclarée qui comporte un champ idx : SPIP peut donc indexer des tables supplémentaires, et les restituer normalement via des boucles et le critère {recherche}.

Les poids des différents champs dans l’indexation des mots est paramétrable.

Les différentes tables d’indexation sont fusionnées en une seule.

Amélioration du comptage des statistiques

Une analyse plus fine des liens entrants permet un décompte plus significatif, et il n’est plus nécessaire d’établir une connexion à la base de données à chaque visite, ce qui peut alléger considérablement la charge sur le serveur.

Par ailleurs, l’affichage des sites referers propose des vignettes des pages d’accueil de ces sites (en tout cas, pour une large partie de ces sites). Par défaut, la source de ces vignettes est Thumbshots.org. Il est possible de modifier le site fournissant les vignettes, avec l’un ou l’autre des réglages suivants :

$source_vignettes = "http://open.thumbshots.org/image.pxf?url=http://";
$source_vignettes = "http://msnsearch.srv.girafa.com/srv/i?s=MSNSEARCH&r=http://";
$source_vignettes = "http://pthumbnails.alexa.com/image_server.cgi?id=www.monsite.net&size=small&url=http://";

3. L’interface de programmation

La réécriture du code s’est poursuivie pour offrir à terme une interface de programmation standardisée. Les informations de cette section sont fournies afin de permettre aux différentes extensions de SPIP (en particulier les milliers de contributions disponibles sur SPIP-Contrib) de pouvoir fonctionner sur cette nouvelle version, même dans le cas d’une installation mutualisée. Pour autant, ces informations ne garantissent pas la présence de telle ou telle fonctionnalité dans les versions ultérieures de SPIP, où la problématique de l’interface de programmation sera entièrement revue.

Réorganisation des fichiers et répertoires

Comme on l’a vu, les fichiers terminés par .php3 ont disparu, entérinant l’abandon de la compatibilité avec PHP3 déjà opérée avec SPIP 1.8. Ce renommage indispensabe pour lever l’ambiguïté des contenus s’est accompagné d’une réorganisation complète des répertoires.

La racine ne contient plus les fichiers de squelettes et de feuille de styles qui figurent à présent dans le répertoire dist, indispensable et non effaçable.

La racine ne contient plus comme script que spip.php, et son alias index.php (un réglage interne permet de mettre ./ à la place de spip.php dans les URL : define('_SPIP_SCRIPT', '') mais par défaut c’est define('_SPIP_SCRIPT', 'spip.php') car on ne peut être absolument certain que la racine du site va appeler ce script (elle pourrait être un bête index.html avec un écran d’accueil).

Les autres scripts ont été déménagés dans des sous-répertoires du répertoire ecrire/ et se répartissent comme suit :

• exec/ => les scripts qui produisent les pages de l’espace privé ;
• action/ => les scripts qui modifient la base sans construire une page à renvoyer au client (par exemple le changement de statut commandé par une puce) ;
• base/ => les fonctions qui traitent la base de données ;
• inc/ => les bibliothèques de fonctions utilisées par SPIP.

Surcharge des fichiers standards

Grâce à l’organisation ci-dessus, il devient possible de changer le comportement de SPIP dans l’espace privé sans modifier ses sources.

Tout script s de l’espace privé est à présent appelé par une URL de la forme ecrire/?exec=s..... SPIP va alors regarder pour chacun des répertoires figurant dans la constante SPIP_PATH s’il y existe un fichier exec/s.php. Le premier trouvé sera chargé, et il est supposé définir la fonction exec_s, qui sera alors appliquée. En dernier recours, SPIP chargera le fichier standard ecrire/exec/s.php qui contient la définition de la fonction exec_s_dist qui sera appliquée.

Ce comportement est également assuré pour les fonctions action_a_dist définies dans les fichiers action/a.php.

On peut aussi surcharger les bibliothèques standards, qui sont chargées par la fonction include_spip et non plus include_ecrire (qui est déclarée obsolète mais continue à fonctionner). Lors d’un appel de include_spip('inc/nom') SPIP va là aussi chercher un fichier homonyme dans un sous-répertoire inc des répertoires de SPIP_PATH qui sera chargé à la place du fichier standard.

On aura compris que cette interface permet aussi de rajouter à SPIP des scripts et des bibliothèques, toujours sans modifier ses sources.

L’appel des scripts à travers une fonction, et non plus directement, présente aussi l’avantage de forcer à la nomenclature des variables globales, ce qui a des avantages en matière de sécurité.

Ce travail a deux débouchés importants : l’intégration d’un système de plugins, et la possibilité de mutualiser les sources de SPIP entre plusieurs sites.

Plugins

Introduction d’un système de plugins ; un nouveau sous-menu apparaît dans le menu « Configuration » lorsqu’un dossier nommé plugins/ est détecté à la racine du site. On peut alors activer un à un les plugins installés dans ce dossier. Pour plus d’informations, voir l’article installer des plugins.

De nombreux plugins sont en préparation ; leur développement se fait essentiellement sur SPIP Zone http://zone.spip.org/trac/spip-zone..., et leur documentation se trouvera sur le site SPIP Contrib.

Mutualisation des sources

Une réécriture importante de tout le code de SPIP permet aujourd’hui à une même distribution de servir plusieurs sites à la fois sans nécessité de copier les sources. Cette fonctionnalité peut se déployer aussi bien par un hébergé ayant plusieurs sites chez un hébergeur (avec plusieurs comptes MySQL ou même avec un seul grâce au préfixe de table) que par l’hébergeur désireux d’offrir SPIP clé en main à l’ensemble de ses hébergés (pour optimiser ses accès disque). Une telle installation n’empêche pas une personnalisation de SPIP par chaque utilisateur, grâce au système de surcharge décrite dans la dernière section de cet article. Elle exige en revanche que l’hébergeur autorise certaines directives (Alias ou RewriteRule) dans les .htaccess de ses hébergés, ou qu’il s’en charge directement dans son httpd.conf (directive VirtualHost).

Détection automatique de tables SQL et de jointures

Dans un squelette comportant BOUCLE_a(xxx), la table xxx peut être n’importe quelle table SQL connue du serveur SQL. SPIP demandera alors au serveur SQL de décrire cette table, ce qui lui permettra de compiler le squelette en interprétant toute balise #NOM comme un accès au champ <span class="base64" title="PGNvZGUgY2xhc3M9J3NwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lJyBkaXI9J2x0cic+eHh4PC9jb2RlPg=="></span>.nom s’il existe. Ces champs sont également repérés dans les critères des boucles.

Dans un squelette comportant BOUCLE_a(table table1 ... tablen), les tables supplémentaires seront vues comme des candidates à une jointure, à travers les champs homonymes. Des exemples plus concrets seront donnés dans la documentation.

Autres améliorations

-  Si le suivi des révisions est activé, on dispose désormais de la possibilité de revenir à une version précédente d’un article.

-  La barre d’édition des raccourcis est désormais disponible aussi sur Safari.

Installation et mise à jour

spip_loader : pour l’installation automatique de SPIP 1.9, un nouveau spip_loader.php a été mis en place (/spip-dev/INSTALL/). Il télécharge directement le même fichier zip que pour une installation manuelle et prend en charge le décompactage. Autres nouveautés concernant spip_loader : il est désormais multilingue, et il est très facile de l’éditer pour qu’il installe la version de développement (SVN) au lieu de la version stable.

Pour la mise à jour depuis une version antérieure de SPIP, vous pouvez copier tous les fichiers de SPIP 1.9 sur votre installation existante comme auparavant. Néanmoins, compte tenu de la profonde réorganisation des fichiers, vous obtiendrez un mélange peu satisfaisant des anciens et des nouveaux scripts. Une documentation plus complète explique comment faire une mise à jour « propre » : article 3370.

* *

Toutes les nouveautés seront progressivement intégrées aux pages de référence de la documentation. Des articles plus détaillés sont en cours de préparation sur les points les plus techniques.

De manière générale nous avons besoin d’aide pour améliorer la documentation de SPIP : n’hésitez pas à participer à la rédaction, la relecture, la correction, l’organisation de cette documentation.

Un grand merci à toutes celles et tous ceux qui ont contribué à cette nouvelle version en signalant des problèmes ou en donnant des idées (sur les listes ou sur trac), du code, des images, de la documentation, en faisant du « support » aux utilisateurs, des formations et dans tous les cas en apportant... de la tendresse.