SPIP

Les outils utilisés pour le développement

bricebou, b_b, James, Maïeul, Matthieu Marcillaud, placido, tofulm — 2025-01-14T06:58:03Z

L'équipe de maintenance utilise ces outils pour maintenir et développer SPIP. Cet article résume succinctement le rôle des outils et les liens de documentation.

Nom de l'outil	Rôle	Documentation spécifique à la communauté SPIP

Développement côté serveur ou back-end
PHP	Langage dans lequel SPIP est écrit côté serveur
PHPdoc	Commentaire du code
Composer	Installer les bibliothèques de code (library) dont le projet principal a besoin
Qualité de code
Easy Coding Standard	Automatiser le respect des régles de codages	Utiliser ECS
Rector	Corriger du code historique pour le rendre plus durable	Utiliser Rector
PSR	Bonne pratiques de codage	Conventions
PHPUnit	Tester le code
PHPStan	Analyser le code
Refactoring Guru	Inspiration pour transformer le code procédural historique en code POO et pour gagner en robustesse
The Twelve-Factor App	Inspiration : une méthodologie pour concevoir des logiciels en tant que service

Développement côté navigateur ou front-end
Javascript	Langage pour l'affichage dynamique de fragments de page (front-end)
jQuery	Bibliothèque longtemps restée comme référence (en voie de migration)
npm + Bun	Installer des modules ou bibliothèques de code (library)
Qualité de code
bun:test	Tester le code
biomejs	Normaliser le code (linter)

Versionnage
Git	Suivi de version de code	Consulter un livre en français
Gitlab	Plateforme de développement
Sémantique	Comment fonctionnent les versions de SPIP et de ses dépendances
Conventionnel commit	Des messages des commits signifiants, lisibles pour l'humain	Voir aussi Écrire un message de commit
Changelog	Permettre de voir précisément quels changements notables ont été faits entre chaque publication (release) d'un projet	Voir aussi Tenir un CHANGELOG

Nous développons et utilisons aussi nos propres outils :

- spip-releases
- spip-league/ecs
- spip-league/rector
- spip-league/sdk

SPIP 4.3

b_b, jack, Maïeul, Matthieu Marcillaud — 2024-07-26T10:40:37Z

Compatibilité PHP 7.4 à 8.3

SPIP 4.3 nécessite PHP 7.4 minimum, et fonctionne jusqu'à PHP 8.3.
Il nécessite les extensions PHP : sodium, Zlib, Zip et Phar.

Changements apportés par SPIP 4.3

Les changements les plus importants concernent

le bandeau de l'espace privé plus condensé,
le formulaire de changement de statut des objets éditoriaux revu,
les filtres d'image plus rapides,
une écriture plus inclusive de certaines formulations,
l'envoi d'une notification par mail lorsqu'une mise à jour de SPIP est disponible, ainsi qu'une indication visuelle plus grande dans l'espace privé,

Le bandeau de l'espace privé prend moins de place en hauteur

Le formulaire de changement de statut est revu

Présentation initiale du formulaire de changement de statut

Formulaire de changement de statut déplié

Un message avertissant d'une nouvelle version disponible

Cette version apporte également d'autres améliorations ou corrections de bugs.

Ajouts

Afficher un encart pour signaler les nouvelles versions dans toutes les pages de l'espace privé pour les webmestres, et un bouton pointant vers spip_loader(voir Utiliser spip_loader) s'il est présent
Notifier par email les webmestres du site lorsque SPIP dispose d'une mise à jour (désactivable avec la constante _MAJ_NOTIF_EMAILS, voir la documentation)
Améliorer l'ergonomie du formulaire instituer (changement de statut d'un objet éditorial, voir plus haut)
Le formulaire d'identité du site permet de configurer la timezone utilisée
Nouveau filtre |balise_img_svg pour insérer une image ou un SVG inline sans savoir d'avance le format
Ajouter une option à find_all_in_path() pour renvoyer tous les fichiers répondant à un pattern
Filtre |propre qui applique propre() & safehtml() (cela permet de dés-échapper le code de confiance des modèles)
Débugueur : Afficher le nombre d'occurrences et temps total des inclusions de squelettes
La constante _DEBUG_MINIPRES définie à true active l'affichage d'un debug visible lorsqu'une erreur de type Minipage survient
Pipeline get_spip_doc pour manipuler le résultat natif de la fonction get_spip_doc()

Changements

Le bandeau de navigation de l'espace privé est réduit en hauteur (2 lignes au lieu de 3, voir plus haut)
Le menu de création rapide passe en menu déroulant avec des labels explicites (voir plus haut)
Écriture plus inclusive de certaines formulations
Optimisation des boucles avec pagination, en forçant une clause limit automatique dessus
Dans un plugin, si l'attribut logo d'un paquet.xml est absent, et qu'il existe un fichier {prefixe}.svg dans le plugin, il est utilisé comme logo
Les fonctions extraire_balise() et extraire_balises() peuvent gérer des balises imbriquées

Corrections

Améliorer la conformité HTML5
Icône Tâches de fond qui n'évoque pas les bases de données
Refactoring de ecrire_fichier()
Combinaison des critères {pagination} et {limit}
Ne pas conserver un double des fichiers calculés inchangés (#PRODUIRE_FOND)
Mise à jour de la bibliothèque mediaelement en version 7.0.3
Correction de inserer_attribut() sur un cas dérogatoire : les balises (même non autofermante)

Dépréciations

Déprécier les fonctions désuètes de ecrire/inc/presentation
La globale auteur_session (dépréciée depuis SPIP 2.0 !) sera supprimée en SPIP 5.0. Utiliser visiteur_session.
Déprécier la classe .label au profit de .editer-label dans les formulaires

Retrait

Retrait des options d'affichage des icônes dans les préférences

Plugins-dist

Images

Les performances du plugin-dist Filtres Images ont été très nettement optimisées, certains filtres images sont désormais jusqu'à 10 fois plus rapides grâce à l'utilisation des fonctions natives de PHP GD

Un nouveau filtre, |image_oriente_selon_exif pour réorienter automatiquement une image selon son exif
Les filtres d'images tel que |image_recadre réorientent l'image selon l'exif d'orientation
Optimisation des filtres |image_aplatir, |image_renforcement, |image_flou, |image_sepia, |image_flip_vertical, |image_flip_horizontal, |image_nb, |image_gamma, |image_rotation
Correction du paramètre crop de |image_rotation

Plugins compatibles

Dès sa sortie SPIP 4.3 bénéficie d'environ 700 plugins compatibles, ce qui facilitera les mises à jour.
Voir : Effectuer une mise à jour

SPIP 4.1

b_b, James, JLuc, Matthieu Marcillaud — 2022-03-25T13:39:45Z

SPIP 4.1 est avant tout une version qui suit les versions maintenues de PHP (7.4 à 8.1) et met à jour différentes librairies utilisées en interne. Il modifie aussi le système d'authentification des auteurs.

Compatibilité PHP

SPIP 4.1 nécessite PHP 7.4 minimum, et fonctionne jusqu'à PHP 8.1.
Il nécessite les extensions PHP : sodium, Zlib, Zip et Phar.

Rappel : SPIP 4.0 c'est PHP 7.3 à 8.0.

Compatibilité PHP 8.1

Pour la compatibilité PHP 8.1, nous avons du corriger / adapter de nombreuses fonctions.

Cela concerne particulièrement des appels à des fonctions de PHP traitant des chaînes de caractères, si elles reçoivent null au lieu d'une chaîne, pour éviter des deprecated : https://php.watch/versions/8.1/internal-func-non-nullable-null-deprecation

Authentification & Chiffrement

Nous reprenons en l'adaptant le travail de g0uz sur le plugin Chiffrer.

- Cela corrige certains rares cas où la librairie Javascript utilisée jusqu'à présent échouait dans l'identification de l'internaute
- Cela renforce la sécurité en évitant certains types d'attaques.

HTTPS est désormais encore plus fortement conseillé

En effet, SPIP ne cherche plus à chiffrer le mot de passe des auteurs en Javascript depuis le formulaire de login, et le mot de passe arrive donc systématiquement « en clair » à SPIP. Il est donc fortement conseillé d'avoir son site en HTTPS, car HTTPS assure alors la sécurité de la transmission.

En conséquence, la constante _AUTORISER_AUTH_FAIBLE, qui permettait de forcer l'envoi du mot de passe en clair, est supprimée.

Poivre, sel, hash du mot de passe

Le mot de passe d'un auteur est maintenant haché dans SPIP en utilisant un poivre (une clé spécifique pour le site). Par ailleurs, la fonction password_hash de PHP s'occupe de trouver le meilleur algorithme de hachage et de créer un sel dedans. La fonction password_verify de PHP est utilisée pour le vérifier.

Les "aléas" rotatifs des auteurs sont toujours créés, mais ne sont plus utilisés pour saler le mot de passe vu que PHP gère cela très bien. Par contre, l'application supplémentaire d'un poivre est une nouveauté.

Comme avant, à chaque authentification réussie d'un auteur, on enregistre un nouveau hash en base, en recréant un hash avec password_hash : cela applique un nouveau sel dessus donc, et éventuellement PHP en profite pour utiliser un algorithme de hachage plus performant si besoin.

Clés de chiffrement

Pour mener à bien ce poivre, et d'autres actions dans SPIP, des clés de chiffrement sont utilisées et stockées dans config/cles.php. Il y en a 2 par défaut :

secret_des_auth : elle sert à poivrer le mot de passe des auteurs. C'est une nouvelle clé donc.
secret_du_site : elle sert pour moitié à calculer le secret du site. L'autre moitié étant stocké en base dans l'entrée secret_du_site de la table spip_meta. Ce secret du site (combiné) permet de signer et/ou chiffrer certaines parties de SPIP (contextes ajax, actions d'auteurs).

Lorsqu'un webmestre se connecte, les clés sont sauvegardées dans le nouveau champ backup_cles de la table spip_auteurs, en le chiffrant avec le mot de passe en clair de l'auteur.

Ceci permet de restaurer les clés du site si le fichier cles.php a été effacé, lors de l'authentification d'un webmestre.

La classe \Spip\Chiffrer\SpipCles permet de manipuler les clés au besoin.

Password

SPIP fournit deux méthodes qui sont utilisées dans ecrire/auth/spip.php

- \Spip\Chiffrer\Password::verifier($clair, $hash, $key = null): bool
- \Spip\Chiffrer\Password::hacher($clair, $key = null): string

La clé par défaut est celle de secret_des_auth, utilisée pour poivrer.

Chiffrement

Trois méthodes sont aussi fournies pour chiffrer et déchiffrer (chiffrage symétrique) des contenus.
Dedans nous utilisons la librairie Sodium (fournie par défaut dans PHP >= 7.2).

- Chiffrement::chiffrer($message, $key): ?string
- Chiffrement::dechiffrer($encoded, $key): ?string
- Chiffrement::keygen(): string

La méthode keygen produit simplement une clé de chiffrement à la longueur adaptée.

Les méthodes chiffrer() et dechiffrer() seront très lentes si la clé transmise n'a pas la bonne longueur : on considère alors la clé de chiffrement comme étant un mot de passe nécessitant un traitement supplémentaire lourd (avec sodium_crypto_pwhash).

Signature des actions

Les actions sont authentifiées maintenant en utilisant hash_hmac et hash_equals (et les aléas d'auteurs et/ou le secret du site)

Qualité du code

Il y a de quoi progresser sur la qualité du code PHP de SPIP… l'avenir ne peut être que meilleur ;-)

Typage

Ce faisant pour PHP 8.1, nous avons commencé à typer certains arguments et retours de fonctions pour détecter au plus tôt certains appels incorrects.

C'est un changement potentiellement impactant : cela peut créer des erreurs de squelettes là où l'erreur était auparavant plus silencieuse ou tolérée. De même cela pourrait provoquer des erreurs PHP dans des plugins ou des scripts maison sur les appels erronés à ces fonctions.

En assurant la compatibilité avec les nouvelles versions de PHP nous irons forcément vers plus de typage dans le code de SPIP au fur et à mesure des évolutions et factorisations du code source.

La conséquence sera donc que les personnes développant des plugins ou des squelettes devront être plus vigilantes sur les appels effectués d'une part, et d'autre part que nous restreindrons certainement les nouvelles fonctions à des types uniques (éviter les mixed), de même que certaines fonctions déjà existantes verront probablement certains types d'arguments mixtes réduits (éviter qu'un argument puisse recevoir un peu tout comme int | string | array par exemple), de même pour les retours de fonctions.

Au vu du code de SPIP historique ce ne sera pas si évident.

Sucre syntaxique

Nous avons passé l'outil Rector sur le code de SPIP 4.1 avec la configuration PHP 7.4. L'outil permet de transformer la syntaxe du code source PHP en modifiant certains éléments qui peuvent être simplifiés grâce à des écritures plus récentes de PHP. Par exemple utiliser les opérateurs ?? ou ??= lorsque c'est possible (Voir la doc PHP).

C'est toujours ça de pris :-)

Changements d'API sur les URLs et objets

Certaines fonctions d'appels pour calculer ou décoder les URLs sont modifiées.
Les anciennes API sont dépréciées.

Il y a maintenant 2 jeux de fonctions distincts pour générer l'URL d'un objet et pour décoder une URL. Ce nouveau mécanisme permet de définir une fonction pour générer une URL propre pour les #URL_PAGE.

Les nouvelles fonctions sont typées. Dans les explications suivantes, on ne présente que le début des signatures des différentes fonctions modifiées.

Voir la demande d'ajout correspondante pour le détail complet.

Encodage

generer_objet_url (anciennement generer_url_entite)

Cette fonction génère une URL, qui peut être soit pour l'espace public (paramètre $public = true), soit pour l'espace privé ($public = false), soit par défaut ($public = null) retourner une URL pour l'espace dans lequel on se trouve actuellement …

La fonction generer_objet_url() est la fonction de haut niveau, qui va finir par appeler une fonction urls_xxx_generer_url_objet()_dist selon le module d'URL actif.

Note : Pour cette fonction la signature change légèrement.

Dans generer_url_entite() maintenant déprécié :

Le 5^e paramètre $public pouvait valoir true, false, null ou 'string'. Dans le cas d'une chaine, il correspondait à un paramètre "connect".

Ce sont maintenant 2 paramètres séparés pour generer_objet_url :

Le 5^e est ?bool $public = null (donc true, false ou null),
le 6^e est string $connect = ''.

Dans la majorité des cas, cela n'affectera pas les usages et renommer simplement la fonction devrait être suffisant.

- generer_url_entite($id, $objet, ...) + generer_objet_url($id, string $objet, ...)

generer_objet_url_absolue

Génère l'URL absolue vers un objet

- generer_url_entite_absolue($id, $entite, ...) + generer_objet_url_absolue($id = 0, string $entite = '', ...)

Décodage

La fonction de décodage des URLs s'appelle maintenant urls_xxxx_decoder_url_dist() ce qui évite toute confusion avec l'ancienne fonction urls_xxxx_dist().

De plus, pour un module d'URLs qui voudrait être compatible avec les anciennes versions de SPIP et cette nouvelle convention, il suffit de proposer une fonction urls_xxxx_dist() non typée qui fait le routage vers les 2 fonctions urls_xxx_generer_url_objet_dist() et decoder_url() du module.

Objet

generer_objet_lien

Génère un lien (titre cliquable vers url) vers un objet

- generer_lien_entite($id_objet, $objet, ...) + generer_objet_lien(int $id_objet, string $objet, ...)

generer_objet_info

Donner une information sur un objet éditorial. Utilisé entre autres par #INFO_XX

- generer_info_entite($id_objet, $type_objet, $info, ...) + generer_objet_info($id_objet, string $type_objet, string $info, ...)

Les fonctions permettant de définir des calculs spécifiques pour l'obtention d'information sont aussi renommées. Pour l'information calculée 'xxx' : appelé via generer_objet_info(3, 'article', 'xxx') ou #INFO_XXX{article,3}.

Si ces fonctions existent, elles sont utilisées par SPIP dans ce cas :

// xxx spécifiquement sur l'objet 'type' - generer_xxx_{type}($id_objet, $type_objet, ...) + generer_{type}_xxx($id_objet, string $type_objet, ...) // sinon xxx sur un objet quelconque - generer_xxx_entite($id_objet, $type_objet, $row, ...) + generer_objet_xxx($id_objet, string $type_objet, array $row, ...)

L'ancien nommage est déprécié.

Suivant ce principe, la fonction interne à SPIP pour calculer l'introduction a été renommée :

generer_objet_introduction

Génère l'introduction de l'objet (fonction privée à SPIP), utilisé par #INTRODUCTION et #INFO_INTRODUCTION)

- generer_introduction_entite($id_objet, $objet, $ligne_sql, ...) + generer_objet_introduction(int $id_objet, string $objet, array $ligne_sql, ...)

Réécriture de `transmettre` en .api

Pour faciliter et sécuriser partiellement l'envoi de données spécifiques (CSV, JSON) à des auteurs connus de SPIP, l'URL d'api transmettre.api a été mis en place (elle remplace un ancien mécanisme à l'objectif identique qui utilisait un squelette transmettre.html).

L'URL est générée avec la fonction generer_url_api_low_sec() (« low sec » signifiant ici « sécurité basse »). Un jeton fixe est créé pour cette action (avec ses paramètres) pour l'auteur désigné et sera acceptée même si l'auteur est déconnecté (ce qui veut dire que quiconque possède l'URL pourra accéder au contenu renvoyé).

Historiquement cela permet de générer des fichiers non publics (RSS des articles proposés à publication, statistiques du site) qui peuvent être exploités par des outils tierces (agrégateur RSS par exemple).

Également :

la fonction securiser_acces() est renommee en securiser_acces_low_sec() et definie dans inc/acces.
On garde un filtre_securiser_acces_dist() dans inc/filtres pour la compat des vieux squelettes
la fonction param_low_sec() est depreciee

Mises à jour des librairies

Nous avons mis à jour différentes librairies utilisées par SPIP.

Javascript

spip/spip -> Sortable 1.14.0
spip/spip -> jquery Form 4.3.0
spip/spip -> JS Cookie 3.0.1
spip/statistiques -> d3 7.3.0
spip/statistiques -> luxon 2.3.0
spip/plan -> jstree 3.3.12

PHP

spip/compresseur -> css-tidy 2.0.0
spip/medias -> getid3 1.9.21
spip/medias -> svg-sanitizer 0.14.1

Suppression de librairies

Nous avons supprimé jQuery.cookie qui était déprécié depuis SPIP 3.2 au profit de JS Cookie.

Pour rappel si vous n'aviez pas encore adaptés vos utilisations :

$.cookie(key) devient Cookies.get(key) $.cookie(key, value) devient Cookies.set(key, value) $.cookie(key, value, options) devient Cookies.set(key, value, options)

Interface

Les rubriques dans l'espace privé affichent maintenant aussi la liste des articles refusés.

Nettoyages

Nous avons supprimé

#FORMULAIRE_CONFIGURER_METAS

qui était déprécié depuis SPIP 3.0 au profit des formulaires

#FORMULAIRE_CONFIGURER_XX

. Voir la documentation Configurer une fonctionnalité de votre site, ou un plugin à ce sujet.

Quelques adaptations

Dans un squelette, pour avoir la liste des tables des objets éditoriaux, préférer #NULL (qui retourne null) plutôt que #REM (qui retourne une chaîne vide).

- [(#REM|lister_tables_objets_sql)] + [(#NULL|lister_tables_objets_sql)]

Plugins

Archiviste

Le plugin "Archiviste" a été mis à jour pour utiliser les extensions PHP Zip, zlib et Phar, qui sont désormais requises. Ceci nous a permis de supprimer les (très) vielles librairies Pcl* que nous traînions depuis quelques années.

À noter aussi que le plugin est accompagné de tests unitaires écrits avec PHPUnit.

Bigup

Le formulaire de configuration de Bigup est affiché sur la page des options avancées, avec une formulation un peu plus parlante pour le titre du formulaire d'explication.

Compresseur

Mise à jour de la librairie CSSTidy en version 2.0 et correction d'un bug dans la compression des fichiers Javascript sur certains environnements.

Forum

correction d'un bug qui affichait le lien vers la page de contrôle des forums pour les auteurs non autorisés.
normalisation de l'ajout d'un forum en base afin de bien faire passer les informations par les pipeline pre/post insertion
correction d'un bug d'affichage d'icône en langue RTL
correction d'un bug qui permettait d'accéder au forum privé des rédacteurs alors que celui-ci était désactivé dans la configuration
correction d'un bug dans la recherche de message depuis la page de contrôle des forums

Mediabox

amélioration de l'affichage des textes longs dans la légende des modales, avec l'attribut data-box-caption-state valant min ou expanded sur les liens mediabox.
utilisation d'un thème sombre par défaut dans l'espace privé
rétablissement du support des URLs avec fragments à l'aide d'un sélecteur dans l'attribut data-href-popin
ajout du support des attributs data-box-(max|min)-(width|height) et data-box-(width|height) sur les liens mediabox et rétablissement de la compatibilité avec les anciennes classes du type boxInline boxIframe boxWidth-xx boxHeight-xx (documentation : https://contrib.spip.net/MediaBox)
correction d'un bug avec certaines images distantes qui n'étaient pas affichées par la modale (notamment des SVG), car l'image n'a pas de dimension connue

Medias

permettre de personnaliser le comportement en autolien des images en fonction du media, de l'extension, de la taille ou de l'id_document
correction d'un bug dans le modèle d'embed des fichiers CSV
retrait de la librairie obsolète jQuery multifile
mise à jour des librairies SVG Sanitizer et getid3
retrait des préfixes navigateurs dans les CSS du plugin
amélioration UX des boutons dans le bloc des documents d'un objet
correction d'un bug dans le code généré pour les attributs d'une image avec légende
amélioration du modèle utilisé pour l'insertion des images SVG dans le texte d'un objet
correction d'un bug d'affichage de la médiathèque quand un document comporte une très longue URL dans les champs titre ou credit

Plan

Mise à jour de la librairie Jstree en version 3.3.12.

Révisions

Correction d'un bug qui empêchait le fonctionnement du génie d'optimisation des révisions.

Sites

correction d'un bug qui affichait la date en double dans les listes d'articles syndiqués
amélioration des formulaires d'édition de site en utilisant un placeholder dans les champs d'URL (au lieu de les pré-remplir avec http://)
correction d'un bug d'affichage de la liste des sites en colonne latérale de l'espace privé

Statistiques

mise à jour des librairies D3.js, d3-time-format et Luxon.js
correction d'un bug d'affichage des noms des mois dans les statistiques en langue arabe

SVP

correction d'un bug dans le déballage des archives de plugin avec les nouvelles fonctions du plugin Archiviste
amélioration de présentation des cases à cocher dans la liste des plugins
correction d'un bug de sélection des plugins quand la personne faisait "tout cocher" puis "cocher les mises à jour"
correction d'un bug dans l'affichage des messages de retour du formulaire de chargement de plugin
toujours afficher le lien vers la documentation du plugin qu'il soit actif ou non
correction d'un bug qui empêchait d'activer un plugin quand les téléchargements sont interdits

TextWheel

correction d'un bug qui échappait par erreur certains liens automatiques
correction d'un bug de direction d'affichage des puces quand la page contient des bloc de textes de directions différentes

URLs étendues

Pour faire suite aux changements d'API sur les URLs et objets, les fonctions d'URLs ont été reprises pour une écriture plus claire et mieux typée avec 2 points d'entrée pour la partie décodage/encodage.

Voir la demande d'ajout correspondante pour le détail complet.

Squelettes dist

correction d'un bug qui provoquait le débordement des paginations sur petit écran
application du filtre |header_silencieux sur les pages publiques afin de respecter la valeur de la globale spip_header_silencieux
retrait des classes spécifiques à Internet Explorer dans les CSS
correction d'un bug d'affichage des images et SVG sur petit écran

SPIP 4.0

erational, Matthieu Marcillaud, tcharlss — 2021-07-09T05:58:08Z

Sommaire

Interface

Espace privé relooké

Un gros travail d'ergonomie a été initié pour rendre à terme l'espace privé adaptatif sur toutes les tailles d'écrans afin d'en faciliter l'usage.

L'espace privé s'adapte mieux à la largeur de l'écran, et commence à utiliser différentes variables CSS pour faciliter sa maintenance.

Aperçu de l'espace privé de SPIP 4.0

L'espace privé de SPIP 4.0 dans le site SPIP Contrib.

Vue d'un article (avec la couleur grise)

Édition d'un article (avec la couleur grise)

Un écran de connexion (login) élégant

La page de connexion par défaut (login.html) est toute re-stylée, teintée du rose SPIP en fond.

Écran de connexion par défaut à SPIP 4.0

L'écran de connexion sur le site SPIP.net.

Et si le rose vous surprend, pas de panique ! Un nouveau formulaire dans la configuration de l'identité du site existe. Il permet de choisir la couleur qu'on veut. Et mieux : il permet même de déposer une magnifique image de fond.

Écran de connexion avec une image, dans SPIP 4.0

Iconographie en SVG

Une grande partie des icones et illustrations dans l'espace privé de SPIP et ses plugins sont passés en SVG.

Tickets #4468 et #4562 : Harmonisation dans l'espace privé du HTML & CSS des boutons
Nouveau jeu d'icône basé sur le thème Numix (en SVG) pour les types de document de la médiathèque

Documents & Logos

Un gros travail a été fait sur les documents et logos :

Les logos des articles et autres objets éditoriaux sont stockés comme les documents (dans spip_documents en base de données, et dans IMG/logo/ sur le disque en conservant le nom du fichier). Une phase de migration déplace les logos à leur nouvel emplacement sur le disque.
Les logos, documents images et filtres d'images acceptent et gèrent le format SVG
Le filtre balise_img permet de gérer des fichiers SVG et de déclarer leur taille
Le nouveau filtre balise_svg permet d'intégrer le code source d'un fichier d'image SVG dans le code html directement. Peut être pratique par exemple pour les petites icônes.
Les documents / logos peuvent être téléversés par drag'n'drop, quelles que soient leurs tailles (intégration du plugin BigUp en plugins-dist, amélioré pour l'occasion). La taille maximum autorisée est configurable.
Les modèles de documents (, , ...) sont revus et simplifiés et utilisent la balise
. Commit fa13018a. Attention : Les modèles doc.html, img.html et emb.html ne sont plus utilisés (et donc toute ancienne surcharge de ces fichiers dans des plugins ou squelettes ne sera plus utilisée). À la place, on utilise les modèles image.html, audio.html, video.html et file.html, correspondant au type de document. Le mode de document n'est plus pris en compte pour le calcul du modèle. NB : afin de ne pas casser vos anciens sites, un plugin de rétro-compatibilité permet de retrouver les anciens modèles.
Possibilité de décliner les fichiers HTML des modèles de document par type de fichier (mime type) détaillé : file_text_csv.html ou principal : file_text.html ; ou par extension : video_mp4.html. En conséquence vos variantes personnalisées doc_[variante].html correspondant au raccourci ne fonctionneront plus et sont à décliner : image_[variante].html, video_[variante].html, etc.
L'écriture des raccourcis SPIP des modèles de documents , ou devient équivalente. L'écriture recommandée est (où XX est le numéro du document).
La notion de Portfolio et de mode document / image sur les documents disparaît. Commit 9cf774b9. La constante _COMPORTEMENT_HISTORIQUE_PORTFOLIO déclarée à true permet de rétablir l'ancien fonctionnement.

Compatibilité PHP

Limitation de la compatibilité de SPIP 4.0 avec PHP de 7.3 à 8.0. De nombreuses notices, dépréciations ont été aussi corrigées. À noter que SPIP 3.2 sera donc la dernière version de SPIP à être compatible avec PHP 5.

Base de données

SPIP 4.0 fonctionne avec Mysql ou Sqlite. Il peut mettre à jour une base issue d'un SPIP >= 2.0.0.

Pour une mise à jour d'un SPIP antérieur, une étape de migration en SPIP 3.2 sera nécessaire.

Syntaxe des squelettes étendue

Ajout du support des boucles anonymes :

Marre du fichage ? une boucle anonyme n'a pas besoin de préciser son nom !
Un identifiant lui sera automatiquement attribué en interne.

[(#REM) Une boucle nommée ]    #TITRE

[(#REM) Une boucle anonyme ]    #TITRE

Et si vous êtes ambitieux, vous pouvez en mettre autant que vous le souhaitez dans un squelette, et même les imbriquer ! Mais bon, pensez à vos successeurs pour ne pas rendre le code trop anonyme à ne plus pouvoir s'y retrouver :)

    #TITRE
    #TITRE

Ajout des parties non conditionnelles de boucles, avant et après

Une syntaxe pour des parties non conditionnelles aux boucles est ajoutée : ce contenu sera toujours affiché, qu'il y ait un résultat ou pas, tout en permettant d'utiliser les balises propre à la boucle (#TOTAL_BOUCLE, #TRI, etc).

Cette syntaxe sert particulièrement pour les tableaux d'éléments avec des tris et filtrages. Si la boucle ne retourne pas d'éléments, on souhaite toujours afficher les filtres (pour les décocher / les modifier).

[(#REM) Une partie non conditionnelle avant / après la boucle ]  [(#REM) cette partie est affichée même si la boucle ne retourne pas d'articles ] Les articles
 Nombre : #TOTAL_BOUCLE
  #TITRE  [(#REM) cette partie est affichée même si la boucle ne retourne pas d'articles ] #PAGINATION

Cela complète les parties conditionnelles des boucles avant et après qui elles s'affichent uniquement si la boucle a au moins un résultat.

[(#REM) Une partie conditionnelle avant / après la boucle ]  [(#REM) cette partie n'est affichée que si la boucle retourne des articles ] Les articles
 Nombre : #TOTAL_BOUCLE
  #TITRE  [(#REM) cette partie n'est affichée que si la boucle retourne des articles ] #PAGINATION
  Aucun article

La partie non conditionnelle des boucles peut se coupler avec la partie conditionnelle : dans se cas elle encadre la partie conditionnelle.

[(#REM) Mix non conditionnel / conditionnel avant / après ]   Les articles
    #TITRE
  
 #PAGINATION

Ajout du support des boucles dans la partie conditionnelle des balises

Oui ! On peut maintenant mettre des boucles dans des balises !
Si si ! Dans les parties conditionnelles des balises.

Quelques exemples :

[(#BALISE) #TITRE ] [#TITRE (#BALISE)] [(#ENV{documents}|oui)      [(#TITRE|sinon{Document n°#ID_DOCUMENT})] \(#EXTENSION\)  
    ]

Changements et apports pour les squelettes

Les balises #PAGINATION nécessitent un changement de syntaxe et d'arguments.

Le changement porte 1) sur la balise englobante, qui doit être nav 2) sur les arguments.

1) La balise englobante doit désormais être

Jusqu'à SPIP 3.2, on écrivait par exemple :

[(#PAGINATION)
]

Avec SPIP 4.0, il faut maintenant utiliser :

[(#PAGINATION)
]

2) Il n'existe plus qu'un seul modèle de pagination. De ce fait, les différences de rendu de la pagination se font en lui passant des arguments.

afficher_lien_precedent=oui pour afficher le < vers les résultats précédents
afficher_lien_suivant=oui pour afficher le > qui mène aux résultats suivants
afficher_lien_tous=oui pour afficher un lien permettant de voir tous les résultats simultanément. Dans ce cas, le texte du lien est "∞" par défaut, mais il est possible de spécifier un autre label avec l'argument label_tous. Exemple : label_tous=tous.
nombre_liens_max permet de définir le nombre de lien de pagination maximum affiché par le modèle. On peut également employer la constante _PAGINATION_NOMBRE_LIENS_MAX pour l'espace public ou _PAGINATION_NOMBRE_LIENS_MAX_ECRIRE pour l'espace privé.

Le premier argument peut indiquer quel est le type de pagination désiré. On peut également l'indiquer avec un argument type_pagination.
Exemple : #PAGINATION{naturel} est équivalent à #PAGINATION{type_pagination=naturel}.

type_pagination=page pour afficher les n° de page : 1, 2, 3, 4...
type_pagination=rang pour afficher les rangs : 0, 10, 20, 30...
type_pagination=naturel pour afficher les rangs avec 1 à la place du 0 : 1, 10, 20, 30...
type_pagination=resultats pour afficher les rangs de 10 en 10 à partir de 1 : 1, 11, 21, 31...
type_pagination=page_precedent_suivant est la combinaison d'une pagination de type page avec les liens précédents et suivants.

L'utilisation de la balise dans l'espace privé est détectée automatiquement, ce qui rend inutile le passage de l'argument type_pagination=prive. La compatibilité avec l'ancienne syntaxe étant toutefois assurée sur ce point, on pourra conserver, sur des anciens squelettes, l'argument de l'ancienne version ainsi :

[(#PAGINATION{prive})
]

Critère {id_?}

Le critère {id_?} permet de faire toutes les liaisons possibles avec les variables d'environnement. Il se comporte donc comme autant de critères {id_xxx ?} que possibles pour la boucle donnée.

Voir id_ ?

Fonction lister_champs_id_conditionnel et pipeline exclure_id_conditionnel

Le critère {id_?} s'appuie directement sur la fonction lister_champs_id_conditionnel($table) qui retourne une liste des champs de sélection conditionnelle possibles pour cette table.

Le calcul est fait à partir des champs commençant par 'id_' dans la table, ainsi qu'avec un éventuel champ 'objet'. On complète ensuite avec les clés primaires des tables éditoriales qui peuvent être liées facilement.

Enfin, le résultat traverse le pipeline exclure_id_conditionnel qui permet d'exclure certains champs de la liste calculée par la fonction lister_champs_id_conditionnel. Voir l'exemple dans le plugin Brèves ou le plugin SVP.

Critère {par_ordre_liste champ,#LISTE{...}}

Nouveau critère par_ordre_liste pour ordonner une boucle selon un ordre précis.

Critère {fusion_supprimer}

Ce critère entre dans le Core. Il était jadis défini dans le plugin SPIP-Bonux. Important : Il faut mettre à jour le plugin SPIP-Bonux, s'il est actif, en version >= 3.7.1 avant de mettre à jour le site vers SPIP 4.0 pour éviter un conflit.

Filtre et fonction identifiant_slug

Ticket #4628 : ajout de la fonction identifier_slug(). Permet de transformer un texte clair en nom court pouvant servir d'identifiant, class, id, url… en ne conservant que des caractères alphanumériques et un separateur.

Filtres label_nettoyer et label_ponctuer

Ces filtres sont ajoutés pour gérer et utiliser un peu mieux les chaînes de langues historiques de SPIP (parfois avec des :, parfois sans).

label_nettoyer enlève les : en fin de texte
label_ponctuer ajoute  : en fin de texte

Évolution des critères {tri} et {par num xxx}

Le critère {tri xxx} accepte un #TRI{par numéro, num xxx} se comportant comme {par num xxx} (les éléments sans numéros sont classés après les éléments ayant un numéro)
Le critère {par num xxx} intègre automatiquement le critère {par sinum xxx} avant lui : ainsi dans (ARTICLES){par num titre}, les articles sans numéros (ou avec le numéro 0) passent après les articles ayant un numéro

Autres points sur les squelettes

Nouveaux arguments de #FORMULAIRE_INSCRIPTION et #FORMULAIRE_LOGIN
Nouveaux filtres ajouter_class, supprimer_class et commuter_class
Filtre lien_ou_expose amélioré
Le filtre |singulier_ou_pluriel peut être étendu pour chaque langue en créant son propre filtre singulier_ou_pluriel_, qui sera appelé si la langue correspond
Nouveau filtre appliquer_si_filtre en complément de appliquer_filtre : le 1er renvoie le contenu initial si le filtre cherché n'existe pas, le 2nd ne renvoie plus rien.

Squelettes-dist (thème de l'espace public par défaut)

Le squelettes-dist par défaut utilise maintenant une syntaxe HTML5

Autres apports

Intégration de la librairie Javascript Sortable.js pour prendre en charge le glisser-déposer de façon plus fluide, notamment pour ordonner les documents, en remplacement du module de jQuery UI.
Une nouvelle boite modale légère, accessible, responsive et plus jolie basée sur Lity
Une feuille de style XSLT fournit des flux RSS stylés
Le graphique des statistiques refait à neuf (il utilise d3.js)
Le compagnon peut être ignoré pour chaque auteur qui connait déjà SPIP
L'option "se limiter au HTML4" pour l'espace public est supprimée. Les squelettes par défaut (la dist) passent en HTML 5 (plugin de rétro-compatibilité)
L'attribut summary pour les tableaux est enlevé
Intertitres de niveau h2 par défaut, et plus de niveau h3 comme c'était le cas avant (plugin de rétro-compatibilité)
La fonction autoriser_exception() accepte un argument * en guise d'id : cela l'autorise pour tout id. Quand on annule une exception avec *, cela annule toutes les exceptions pour cet objet, même celles qui auraient été posées individuellement avec des ids.
Le filtre heure_minutes accepte en argument optionnel abbr lorsqu'on ne souhaite pas indiquer l'unité des minutes. Ainsi [(#DATE|heures_minutes{abbr})] affichera, par exemple : 17h26
La constante _AUTO_SELECTION_RUBRIQUE, qui permet d'affecter automatiquement une rubrique à la création d'un article si sa valeur est true accepte maintenant en plus un entier : dans ce cas cela correspond à l'identifiant de rubrique à attribuer par défaut.
Si le 3è paramètre (class) de #BOUTON_ACTION{libellé, url, class ,message de confirmation} contient "ajax", cette classe est ajoutée au formulaire qui contient le bouton.

Corrections

Mise à jour de toutes les librairies JS utilisées
[login] Ticket #3957 : Ne plus afficher le cadenas sur la page login, trop ambigu avec le cadenas https du navigateur.
[admin] Le lien "Afficher les visiteurs" n'est pas présenté s'il n'y a pas d'utilisateurs avec ce statut sur le site.
[svp][plugins] S'il y a une erreur XML sur un paquet.xml, elle est directement explicitée sur la page de gestion des plugins.

Nettoyages

Plugins

Les fichiers plugin.xml des plugins SPIP 2.x ne sont plus interprétés. Seuls les paquet.xml le sont désormais. Un plugin qui n'aurait donc que plugin.xml (sans paquet.xml à côté) ne fonctionnera donc plus à partir de SPIP 4.0.

Divers

Ticket #4060 : Nettoyage code < PHP 5.4
Nettoyage code & CSS <= IE9
Nettoyage htaccess (plus de compat sur les URLs .php(3) de SPIP <= 1.8

Fichiers

Suppression de inc/mail déprécié depuis SPIP 2. Utiliser par exemple :

$envoyer_mail = charger_fonction('envoyer_mail', 'inc'); $envoyer_mail(...);

Suppression de action/preferer.php inutilisé depuis SPIP 3.2 (suppression de ecrire/oo/).
Supression de exec/valider_xml.php non fonctionnel, déplacé dans le plugin à corriger Valider XML
Suppression de exec/fond_monobloc.php. Créer les squelettes de l'espace privé dans prive/squelettes.

Balises / Filtres / Critères

Suppression des balises #DEBUT_SURLIGNE et #FIN_SURLIGNE dépréciées depuis SPIP 2. Utiliser les classes CSS surlignable et pas_surlignable.
Les filtres aligner, aligner_gauche, aligner_droite, centrer, justifier et style_align sont supprimés. Utiliser du code CSS pour obtenir le même résultat.
Suppression de #LOGIN_PRIVE. Utiliser #FORMULAIRE_LOGIN
Suppression de #LOGIN_PUBLIC. Utiliser #FORMULAIRE_LOGIN
Suppression de #DOSSIER_SQUELETTE. Utiliser #CHEMIN
Suppression de #NOOP. Utiliser #VAL
Suppression de {datasource ...}. Utiliser directement le critère {source ...}

Fonctions PHP

Suppression de echo_log() (inutile maintenant).
Suppression de spip_fetch_array(). Utiliser sql_fetch() à la place.
Suppression de generer_url_retour(). Utiliser parametre_url() à la place, avec le paramètre 'redirect'.
Suppression de charger_php_extension() (utiliser extension_loaded())
Suppression de revisions_articles(). Utiliser article_modifier()
Suppression de revision_article(). Utiliser article_modifier()
Suppression de articles_set(). Utiliser article_modifier()
Suppression de insert_article(). Utiliser article_inserer()
Suppression de instituer_article(). Utiliser article_instituer()
Suppression de insert_auteur(). Utiliser auteur_inserer()
Suppression de auteurs_set(). Utiliser auteur_modifier()
Suppression de instituer_auteur(). Utiliser auteur_instituer()
Suppression de revision_auteur(). Utiliser auteur_modifier()
Suppression de insert_rubrique(). Utiliser rubrique_inserer()
Suppression de revisions_rubriques(). Utiliser rubrique_modifier()
Suppression de instituer_rubrique(). Utiliser rubrique_instituer()
Suppression de admin_repair_plat(). Les fichiers .plat ne sont plus utilisés. Cette fonction n'est plus appelée depuis r14292
Suppression de version_svn_courante(). Utiliser version_vcs_courante()
Suppression de lire_meta(). Utiliser $GLOBALS['meta'][$nom] ou lire_config('nom')
Suppression de auteur_referent(). Utiliser auteur_associer()
Suppression de table_jointure(). Utiliser Utiliser l'API editer_liens ou les tables de liaisons spip_xx_liens ou spip_yy_liens, selon.
Suppression de modifier_contenu(). Utiliser les fonctions génériques pour l'API de modification de contenu.
Suppression de revision_objet(). Utiliser objet_modifier().
Suppression de notifier_publication_article().
Suppression de notifier_proposition_article().
Suppression de calcul_branche(). Utiliser calcul_branche_in().
Suppression de ecrire_metas().
Suppression de spip_query_db(). Utiliser sql_query() ou autre.
Suppression de spip_get_lock() et spip_release_lock() qui n'étaient plus utilisées.
Suppression de recuperer_entetes(). Utiliser recuperer_entetes_complets().
Suppression de maj_version() et upgrade_vers() qui ne servent plus.
Suppression de upgrade_types_documents(). Utiliser directement creer_base_types_doc() du plugin Medias

Dépréciations

La et son critère {tableau ...} sont dépréciés au profit de la et son critère {source table, ...}.
De même, le fitre |foreach est déprécié au profit de la syntaxe à base de boucle (DATA).

`Plugins`


- Les plugins breves, jquery_ui, organiseur, petitions, vertebres, squelettes_par_rubriques ne sont plus distribués avec SPIP par défaut. Ces plugins, breves, organiseur, petitions et squelettes_par_rubriques sont toujours maintenus mais il faut les installer à la main (via SVP par exemple) afin de bénéficier de leurs fonctionnalités. Par exemple, installer le plugin Squelettes par rubrique pour utiliser des squelettes suffixés par numéro de rubrique et/ou par code de langue : (-23.html, =23.html, et .en.html). Pour installer ces plugins via SVP, il faut jouter le dépôt SPiP-Zone - Core (ref https://plugins.spip.net/spip.php?page=depots) dans la page de gestion des dépôts de l'interface privée.
- jquery_ui est maintenu par la communauté, mais déprécié
- vertebres bien que fonctionnel en SPIP 4.0 est abandonné : le plugin Adminer est une alternative plus complète.
Pour faciliter la suppression de leurs tables dans la base de données lors de la migration 3.2 -> 4.0, le plugin dédié Léon est mis à votre disposition : https://contrib.spip.net/leon-le-nettoyeur
Breves
Fonctions PHP
 Suppression de insert_breve(). Utiliser breve_inserer()
 Suppression de revisions_breves(). Utiliser breve_modifier()
Grenier
Le grenier est nettoyé et ne contient plus que les fonctions enlevées de SPIP 3.2 et SPIP 4.0. 

Ce qui est antérieur à SPIP 3.2 n'est plus présent dedans.
Il reçoit les différentes fonctions et fichiers supprimés de SPIP 4.0 qui pouvaient potentiellement être utilisés par des squelettes ou plugins.
Medias
Fonctions PHP
 Suppression de document_set(). Utiliser document_modifier()
 Suppression de insert_document(). Utiliser document_inserer()
 Suppression de revision_document(). Utiliser document_modifier()
 Suppression de afficher_documents_colonne(). Utiliser l'inclusion prévue ou une véritable déclaration d'objet éditorial (la colonne document est alors affichée automatiquement sur la page d'édition de l'objet)
 Suppression de lien_objet(). Utiliser generer_lien_entite()
 Suppression de instituer_document(). Utiliser document_instituer()
Mots
Fonctions PHP
 Suppression de groupemots_inserer(). Utiliser groupe_mots_inserer() ou objet_inserer()
 Suppression de groupemots_modifier(). Utiliser groupe_mots_modifier() ou objet_modifier()
 Suppression de revision_groupe_mot(). Utiliser groupe_mots_modifier()
 Suppression de insert_mot(). Utiliser Utiliser mot_inserer()
 Suppression de mots_set(). Utiliser mot_modifier()
 Suppression de revision_mot(). Utiliser mot_modifier()
Pétitions
L'utilisation des pétitions est maintenant optionnelle : elles sont désactivées par défaut sur les nouvelles installations [1]. Vous pouvez les activer dans la configuration des contenus du site.
Sites
Fonctions PHP
 Suppression de insert_syndic(). Utiliser site_inserer()
 Suppression de revisions_sites(). Utiliser site_modifier()
 Suppression de syndic_set(). Utiliser site_modifier()
 Suppression de instituer_syndic(). Utiliser objet_instituer()


		
		
[1] Sur les installation existantes, ce n'est le cas que si elles nétaient pas utilisées auparavant



SPIP 3.2
Matthieu Marcillaud, peetdu, tofulm — 2017-10-13T12:56:56Z
SPIP 3.2 est une version améliorée de SPIP 3.1, qui comprend une mise à jour des bibliothèques JavaScript embarquées, une meilleure ergonomie de l'espace privé ainsi que de nombreuses améliorations.
		
Sommaire
 Javascript
 PHP
 Core
 Plugins
Voici le détail des évolutions

Javascript
jQuery
 Mise à jour de jQuery en version 3.2 (dans SPIP 3.1 c'est jQuery 1.12). https://jquery.com/upgrade-guide/3.0
 intégration de jQuery-migrate-3.0.1.js pour faciliter les migrations des scripts utilisant jQuery. https://github.com/jquery/jquery-migrate/#README


Note importante :  Ces changements impliquent qu'il est fortement conseillé de mettre à jour les scripts utilisant jQuery. Cela concerne principalement les modifications suivantes :
 bind() => on()
 unbind() => off()
 load() => on('load', ...)
 unload() => on('unload', ...)
 jQuery.isArray() => Array.isArray()

jQuery UI
 Mise à jour de jQuery UI en version 1.12 (dans SPIP 3.0 c'est jQuery UI 1.11). http://jqueryui.com/upgrade-guide/1.12/ . Changement d'implémentation au passage :
 tout jQuery UI est chargé dans l'espace privé par défaut.
 Dans l'espace public, dès lors qu'un élément de jQuery UI est demandé via le pipeline "jqueryui_plugins", tout le JS / CSS de jQuery UI est également chargé.


Note importante :  Ces changements impliquent que les usages de javascript qui chargeaient des modules de jQuery UI avec $.getScript() ne fonctionneront plus. Vous pouvez soit charger globalement jQuery UI dans votre squelette, ou via le pipeline jqueryui_plugins pour un plugin, soit utiliser $.getScript() sur le chemin du fichier "jquery-ui.js" directement.
Ainsi :
$.getScript("#CHEMIN{prive/javascript/ui/core.js}", function(){ $.getScript("#CHEMIN{prive/javascript/ui/widget.js}", function(){ $.getScript("#CHEMIN{prive/javascript/ui/mouse.js}", function(){ $.getScript("#CHEMIN{prive/javascript/ui/sortable.js}", function(){ // ... })})})}); 
Pourrait devenir :
$.getScript("#CHEMIN{prive/javascript/ui/jquery-ui.js}", function(){ // ... }); 

JS Cookie
 La librairie JS Cookies est intégrée en version 2.1.4. Elle remplace jQuery.cookie. https://github.com/js-cookie/js-cookie
 L'ancienne écriture $.cookie() fonctionne encore dans la plupart des usages mais il est conseillé de migrer :
 $.cookie(key) devient Cookies.get(key)
 $.cookie(key, value) devient Cookies.set(key, value)
 $.cookie(key, value, options) devient Cookies.set(key, value, options)
PHP
 Nombreuses notices PHP enlevées encore.
 Compatibilité PHP 7.4 maximum

Core
Tri des items de navigation & entrées favorites

Le fonctionnement du plugin « Menu privé alphabétique » est intégré :
 les sous-menus de navigation (au survol des menus « Édition », « Publication », « Activité », ...) sont maintenant triés par ordre alphabétique [1].
 dans ses préférences personnelles, il est maintenant possible de cocher des entrées de menus « favorites », qui s'afficheront alors en tête dans les sous-menus de navigation concernés.
 si un sous-menu contient plus de 20 entrées, il est alors affiché en 2 colonnes.
Simplification du « cookie de correspondance »
Le bouton pour activer ce cookie dans l'espace privé n'était pas explicite. Par ailleurs, le cookie se désactivait à terme si un auteur se connectait régulièrement sur un même site. La solution retenue est de supprimer la notion (et le bouton) de « cookie de correspondance », et de créer le cookie (dit d'admin) systématiquement lorsqu'un auteur se loge et a les droits d'accès à l'espace privé. Le cookie d'admin est renouvelé en même temps que le cookie de session. Et s'enlève en se déconnectant.

Tickets associés : #1740, #1710.
Dépendances des plugins à des extensions PHP
Il est maintenant possible d'indiquer dans un paquet.xml qu'un plugin a besoin d'une extension PHP pour fonctionner. Ticket #3829. Une erreur sera affichée dans le cas contraire à l'activation du plugin. Syntaxe :
  
Formulaire

La balise #FORMULAIRE_INSCRIPTION s'enrichie de deux nouvelles possibilités :
 elle accepte un 3e argument pour indiquer la page vers laquelle on redirige la personne lorsqu'elle confirme son inscription ;
 Il est possible de forcer l'utilisation du lien de confirmation contenu dans l'email.
Les explications détaillées dans l'article FORMULAIRE_INSCRIPTION
Critères
 le critère {par champ} a été réécrit et tolère mieux les noms de champs provenant de tables de jointures, en harmonisant avec {par num champ} et {par multi champ} le fonctionnement. Des expressions {par expr champ} peuvent maintenant être créées sans surcharger tout le critère, à toutes fins utiles.
 ajout de {par sinum champ} qui met en premier les éléments ayant des numéros (hors 0.). Ainsi {par sinum titre, num titre, titre} mettra les titres avec des numéros avant ceux n'en ayant pas (contrairement à {par num titre, titre}), puis triera par numéro. Et contrairement à {par titre, num titre}, le numéro 100 sera bien placé après le numéro 20.
Pipelines
 formulaire_receptionner : pipeline appelé au moment où un formulaire est posté par un visiteur, mais avant l'analyse des données postées par la fonction de vérification. https://core.spip.net/projects/spip/repository/revisions/23308
Divers tickets
 Inclusions, connect & pagination (Tickets #3823 et #3899) : les paginations ajax prennent en compte le paramètre connect qui était utilisé. Le connect explicité sur une inclusion est prioritaire sur celui provenant de l'URL.
 Limiter le nombre de fichiers de session d'un auteur (Ticket #3807)
 Permettre d'envoyer un nouveau mot de passe à un auteur depuis l'interface privée (Ticket #2250)
Fichiers supprimés
 ecrire/inc/aider.php (déplacé dans plugins-dist/aide/inc/aide.php)
 ecrire/inc/pclzip.php (déplacé dans plugins-dist/archiviste/inc/pclzip.php)
Déplacements
 les filtres de dates sont maintenant dans inc/filtres_dates.php (déplacés depuis inc/filtres.php) (Ticket #3583).
Suppression
 les fonctions dépréciées afficher_plus(), debut_cadre_couleur_foncee(), fin_cadre_couleur_foncee() sont passées dans le plugin Grenier.

Plugins
Aide
 Nouveau plugin qui intègre la gestion de l'aide en ligne (fonctions déplacées depuis le Core ou plugin SVP)
Archiviste
 Nouveau plugin qui intègre la gestion des archives zip et tar (fonctions déplacées depuis le Core)
Filtres Images
 Suppression des fonctions et fichiers dépréciés depuis SPIP 2.1 (Ticket #3601). Les éléments ont été déplacés dans le plugin Grenier.
Grenier
 Accueil des fonctions dépréciées du plugin Filtres images.
 Accueil des fonctions dépréciées du Core
Médias
 Intégration du plugin Minidoc dans le plugin médias. Il permet différents affichages des listes de documents attachés aux objets éditoriaux. Ticket #3888
 Modification également de la présentation par défaut de ces listes documents attachés
 Intégration du plugin Ordoc dans le plugin médias. Ticket #3887. Il permet d'ordonner les listes de documents joints aux objets éditoriaux [2], et ajoute un champ "rang_lien" dans la table spip_documents_liens. Il devient alors possible d'utiliser des boucles telle que :

 
.
 Changement de structure du code HTML attendu en retour du pipeline afficher_metas_document, qui par ailleurs envoie le code HTML des détails affichés pour le document plutôt que rien par défaut, ce qui permet de compléter la balise  utilisée.Mots
 Ajout d'une administration avancée sur les mots pour permettre de les fusionner ou de créer des associations/dissociations par rapport à un autre mot clé Commit 100448
Organiseur
 Mise à jour de la librairie FullCalendar en version 3.5.1 (auparavant en version 1.6). Pour migrer si vous utilisiez cette librairie dans l'espace public, se reporter à https://fullcalendar.io/wiki/Upgrading-to-v2/ ou https://fullcalendar.io/docs/
 Intégration de la librairie Moment.js (nécessaire à FullCalendar)
Sites
 Permettre de rechercher dans les articles syndiqués sur un site. Ticket #3859
SVP - Gestion des plugin
 Prise en compte de l'affichage des erreurs de dépendances sur les extensions PHP. Ticket #3819.
 Affichage plus compréhensible des versions sur les erreurs de dépendances.
 On peut maintenant télécharger un plugin sans l'activer. Dans ce cas on reste sur la page de recherche de plugin. Ticket #3471
 Afficher une barre de progression lors d'actions multiples (évite des erreurs de redirections). Ticket #3473
 Correction de l'absence de confirmation des actions lorsque des actions supplémentaires sont ajoutées automatiquement par SVP (par exemple activer ou désactiver des dépendances).
 inc/pcltar.php et lib/pcltar/ déplacés dans le plugin Archiviste.
URL Étendues
Les URLs Arborescentes (principalement) peuvent gérer du multilinguisme (champs multis sur les rubriques par exemple) et des parents multiples (polyhiérarchie).
 Tolérer plusieurs parents pour un objet. Commit 100814
 Ajout d'un champ langue sur la table spip_urls. Commit 100835
 Il est possible de définir une URL spécifique pour une certaine langue langue sur un objet éditorial en éditant l'URL. Pour ce faire, dans le champ de saisie, indiquer [code langue]:[url propre] tel que en:movies et fr:videos. Commit 100835
 La déclaration du « type » préfixant éventuellement l'URL d'un objet dans les URLs arborescentes (exemple : 'mot' dans mot/titre_du_mot) peut recevoir une écriture à base de balise multi pour que le terme soit traduit en fonction de la langue Commit 100836
 Les URLs arborescentes peuvent gérer du multilinguisme, en ajoutant le code de langue dans l'URL, activable par la constante _url_arbo_multilang. Commit 100844.

[1] Auparavant, l'ordre pouvait dépendre d'une position souhaitée, mais aussi de l'ordre dont s'activaient les plugins

[2] Pour les sites qui utilisaient le plugin Mosaique pour cela, un plugin de migration existe

Les itérateurs de SPIP - la boucle (DATA)
Fil, Matthieu Marcillaud — 2012-05-19T09:30:50Z
SPIP 3.0 a apporté une notion générale de boucle, basée sur les itérateurs de PHP.
		
Sommaire
 Syntaxe et formats de la boucle (DATA)
 Filtrage, tri, pagination, fusion
 Le critère {liste ...}
 Le critère {enum ...}
 Protection des données manipulées par les itérateurs
Les boucles (DATA) ne portent plus exclusivement sur des requêtes SQL [1], mais elles peuvent tourner sur toutes sortes de listes de données.
Par exemple :
 un tableau de données produit par une fonction quelconque (dont les itérateurs PHP)
 le contenu d'un fichier local au format XML, CSV, JSON, YAML, etc.
 une liste de fichiers dans un répertoire du serveur
 une requête sur un webservice
 une requête SQL (telle que calculée par SPIP, par ex.)
 etc. (LDAP...).
Syntaxe et formats de la boucle (DATA)
C'est une boucle capable d'itérer n'importe quel tableau de données. Sa syntaxe de base est la suivante :
 #BALISES  
Le critère {source format, données} définit les données sur lesquelles la boucle va itérer.
La définition d'une source de données nécessite deux éléments :
— La partie données : cet élément peut être de plusieurs natures :

- un tableau de données, par exemple #ENV*

- le chemin d'un fichier sur le disque dur, ex : sources/definitions.csv

- l'URL d'un fichier ou d'un webservice, ex : http://per.sonn.es/bases/phobia.fr.yaml

- ou encore, une chaîne quelconque que le format saura transformer en tableau de données, ex : "select * from flickr.photos.search where text='spip'"
— La partie format est à prendre dans la liste ci-dessous :

- table (alias array ou tableau), pour un tableau déjà créé

- csv, json, yaml pour un fichier composé dans l'un de ces formats

- file pour boucler sur les lignes d'un fichier

- glob ou pregfiles pour boucler sur les fichiers d'un répertoire (et plus...)

- rss (alias atom) pour lire un flux de nouvelles

- plugins pour lister les plugins actifs sur le site

- yql pour envoyer une requête sur le webservice de Yahoo Query Language

- sql pour envoyer une requête brute au serveur SQL . Attention dans ce cas : 1) la chaîne spécifiant la requête ne doit pas contenir de fins de lignes 2) utiliser la syntaxe {source sql, connecteur:requete} pour envoyer la requête sur une base externe 
- ics pour boucler sur des calendriers (nécessite le plugin icalendar : lire Plugin iCalendar)

- etc.
Tous ces formats sont déjà disponibles, et il est très aisé d'en ajouter un nouveau, en créant une simple fonction inc_FORMAT_to_array($u). A titre d'exemple voici la fonction qui transforme un fichier JSON en tableau de données :
function inc_json_to_array_dist($u) { if (is_array($json = json_decode($u)) OR is_object($json)) return (array) $json; } 
On peut déclarer une nouvelle boucle DATA dans un fichier inc/ma_source_to_array.php
function inc_ma_source_to_array_dist($data,$param1='',$param2='') { // $data contient le contenu du fichier (local | distant) ou bien la valeur de la variable passée dans le critère. // $param1, $param2... sont des paramètres facultatifs ... } 
et l'afficher ensuite :
 #VALEUR  
Cache : 
- Le critère {datacache 3600} permet de spécifier la durée pendant laquelle le résultat d'une boucle DATA est enregistré en cache. On peut donc désactiver tout cache avec le critère {datacache 0}

- Voir plus d'infos sur les caches des boucles DATA
 Filtrage, tri, pagination, fusion 
Filtres. Comme les boucles SQL, les boucles (DATA) peuvent être filtrées par des critères du type {valeur=x} ; les opérateurs disponibles sont =, >, <, >=, <=, == (expression rationnelle) et LIKE.
Cependant ce filtrage s'effectue non pas en amont lors de la requête, comme en SQL, mais en aval, sur le tableau de données initialement récupéré.
Tris. Les tris {par xx} sont également possibles, avec leur variante {!par xx} pour trier en ordre inverse.
Pagination. La pagination fonctionne normalement, ainsi que le critère {offset,limite}.
Fusion. Le critère {fusion /x/y} fonctionne aussi. Par exemple, pour un fichier d'adresses au format CSV, si l'email est le champ n° 3, on pourra ne retenir qu'un seul enregistrement par email avec la boucle suivante :
 '}> #VALEUR{0} : #VALEUR{3}  
La fusion se fait après le tri, et retient le premier élément rencontré. De cette manière, si un tableau est trie {!par date} puis fusionné sur l'email, l'enregistrement retenu pour chaque email sera le plus récent.
 Le critère {liste ...} 
Pour simplifier l'écriture de tableaux de données, lorsqu'il s'agit d'une simple liste d'éléments qu'on veut indiquer manuellement, la boucle (DATA) accepte le critère {liste ...}, qui permet de constituer un tableau de données en séparant celles-ci par des virgules.
Boucle :
"}>  [(#VALEUR|mult{#_i:VALEUR})]   
Résultat :

 18 21 24 
 24 28 32 
 30 35 40 

A noter : on a utilisé #_i:VALEUR pour référencer dans la boucle j la valeur calculée par la boucle i.
Voir aussi Deux itérateurs simples : les listes et les énumérations
 Le critère {enum ...} 
 #VALEUR  
Résultat :

 2 4 6 8 10 
 #VALEUR  
Résultat :

 g, h, i, j, k, l, m 

val1 et val2 sont 2 valeurs numériques, ou bien 2 caractères. SPIP déterminant laquelle des 2 valeurs est la plus petite, cette boucle va énumérer les valeurs entre val1 et val2. Dans la première forme, le pas n'est pas précisé : il vaut 1 par défaut.
Voir aussi Deux itérateurs simples : les listes et les énumérations
Protection des données manipulées par les itérateurs
La boucle (DATA) protège automatiquement toutes les balises qui sont à l'intérieur, car les données qu'on y manipule sont en général de provenance inconnue et potentiellement dangereuse. Cela impacte aussi les balises des formulaires (#FORMULAIRE_xx) qu'il faut donc utiliser avec un * comme expliqué dans l'article sur les balises étoilées.
 #FORMULAIRE_XXX*{#VALEUR}  
A noter : si vous utilisez le plugin "Bonux", il suffira d'utiliser une boucle (POUR), qui elle n'a pas ce comportement.
 #FORMULAIRE_XXX{#VALEUR}  
 
Lire la suite : régalez-vous avec des exemples de boucles (DATA) !
		
		
[1] Sans surprise, l'itérateur classique de SPIP s'appelle SQL : il exécute la requête telle que SPIP l'a calculée, et sait parcourir la liste de résultats pour les envoyer à la boucle.


Configurer une fonctionnalité de votre site, ou un plugin
JLuc, Matthieu Marcillaud, severo — 2011-12-13T07:40:48Z
La configuration d'une fonctionnalité ou d'un plugin consiste à définir des valeurs pour ses différents paramètres. Il faut donc pour cela définir un formulaire et pouvoir accéder aux valeurs des paramètres, partout dans vos squelettes.
Les formulaires CVT permettent aussi, simplement, de créer une page de configuration pour une fonctionnalité de votre site, ou pour la configuration d'un plugin.
Un mode de configuration est intégré à SPIP.
		
Sommaire
 Formulaire de configuration
 Configuration d'un plugin
 Accéder aux valeurs configurées
 Autorisations
 Personnaliser les traitements
 Utiliser une autre table pour stocker les valeurs configurées
Formulaire de configuration 
Supposons que vous ayez une fonctionnalité "truc" à configurer.
 créez un formulaire CVT dont le nom commence par « configurer_ », avec juste le fichier HTML et sans le PHP (et donc sans définir les fonctions charger, verifier et traiter) [1].
 créez une page configurer_truc.html dans prive/squelettes/contenu/, à l'intérieur de votre plugin ou de votre répertoire squelettes. Dedans, appelez le formulaire avec simplement #FORMULAIRE_CONFIGURER_TRUC
C'est tout !
Configuration d'un plugin
Lorsqu'un plugin dispose d'une page de configuration, une option "Configurer" amenant à cette page apparaît automatiquement dans la ligne présentant ce plugin dans la page d'administration des plugins.
Cette page est définie par le squelette prive/squelettes/contenu/configurer_prefixeplugin.html et fait le plus souvent appel à un formulaire de configuration.
Exemple : Pour le plugin 'mediabox', le fichier prive/squelettes/contenu/configurer_mediabox.html contient :
[(#AUTORISER{configurer,mediabox}|oui) <:mediabox:titre_page_configurer_box:>
  #FORMULAIRE_CONFIGURER_MEDIABOX 
 ] 
Si vous souhaitez qu'une entrée apparaisse également dans les menus de la partie privée pour vous donner un accès direct à cette page de configuration, ajoutez une entrée 
 dans le fichier paquet.xml.
Exemple :
 
Pour initialiser la valeur d'une configuration (paramètre "a_la_une", par exemple) lors de la création ou de la mise à jour du plugin, ajouter, dans le pipeline monplugin_upgrade() :
 lors de la création :
$maj['create'] = array( array('ecrire_config','monplugin/a_la_une', '3'), ); 
 lors d'une mise à jour :
$maj['0.1'] = array( array('ecrire_config','monplugin/a_la_une', '3'), ); 
Pour effacer la valeur lors de la désinstallation du plugin, ajouter, dans le pipeline monplugin_vider_tables() :
effacer_config("monplugin/a_la_une"); 
Accéder aux valeurs configurées
Dans un squelette, on accède à la valeur d'une configuration au moyen de la balise #CONFIG (par exemple #CONFIG{monplugin/a_la_une})
En php on accédera en lecture aux valeurs avec la fonction lire_config avec lire_config('monplugin/a_la_une').
En écriture, on utilisera la fonction ecrire_config :

ecrire_config('monplugin/a_la_une', 3)
Autorisations
Tous les internautes n'ont pas accès à la page de configuration. Par défaut, seuls les administrateurs ont cette possibilité, mais vous pouvez redéfinir les droits d'accès à votre formulaire de configuration. Utilisez pour cela l'API php autoriser, ainsi que la balise #AUTORISER et le filtre sinon_interdire_acces pour votre squelette de formulaire.
Exemple : [(#AUTORISER{configurer,mediabox}|sinon_interdire_acces)]
Personnaliser les traitements
Parfois, on a besoin de faire d'autres traitements précis lorsque des valeurs de configuration sont changées. Dans ce cas il faut ajouter la fonction traiter() habituelle de l'API CVT, et appeler la fonction commune qui s'occupe de traiter les configurations :
function formulaires_configurer_monplugin_traiter_dist() { include_spip('inc/cvt_configurer'); $retours = array(); // On enregistre la nouvelle configuration $trace = cvtconf_formulaires_configurer_enregistre('configurer_monplugin', array()); // Traitements personnalisés // … $retours['message_ok'] = _T('config_info_enregistree') . $trace; $retours['editable'] = true; return $retours; } 
Utiliser une autre table pour stocker les valeurs configurées
Par défaut, les valeurs configurées sont stockées la table spip_meta, et l'intégralité de cette table est chargée en mémoire à chaque hit. Il est toutefois possible d'utiliser une autre table pour stocker les valeurs configurées.
Par exemple, pour utiliser la table meta_monplugin, il faut ajouter la ligne suivante dans le formulaire de configuration :

Puis, pour accéder aux valeurs enregistrées dans cette table, indiquer le nom de la table préfixé par un / au début de l'argument de lire_config :
ecrire_config('/meta_monplugin/descriptif', 'blah'); lire_config('/meta_monplugin/argument'); 
Outre _meta_table, le nom de la table où stocker les valeurs configurées, il existe 3 autres variables utiles pour varier l'endroit ou la méthode d'enregistrement de la configuration :
 _meta_casier : nom du "casier" dans lequel sérialiser (par défaut c'est le xx de formulaire_configurer_xx)
 _meta_prefixe : préfixer les meta (alternative au casier) dans la table des meta (pas de préfixe par défaut)
 _meta_stockage : utiliser une méthode externe de stockage. Aucune n'est fournie par le core.
		
		
[1] Pour simplifier encore la création de ce formulaire, il est possible d'utiliser le plugin Saisies


Mutualisation : un SPIP pour plusieurs sites
Committo, Ergo Sum., Matthieu Marcillaud — 2010-07-08T22:30:11Z
Partager les fichiers de SPIP entre plusieurs sites, ce que l'on appelle une mutualisation, permet un gain d'espace disque important, ainsi qu'une possibilité de mise à jour de SPIP simple de l'ensemble des sites en ne mettant à jour que le noyau.
		
Sommaire
 Le concept...
 Initialisation de la mutualisation
 Mutualiser des domaines ou des sous-domaines
 Mutualiser les répertoires d'un domaine
 Préfixe des tables
 Fichier config/mes_options.php
 Configurer Apache pour les domaines et sous-domaines
 Note sur les sauvegardes et les restaurations
SPIP permet de mutualiser ses fichiers. 

(les restaurations peuvent se réaliser d'un SPIP à l'autre comme s'il n'était pas mutualisé).
Le concept...
Les dossiers nécessaires au fonctionnement du noyau SPIP (ecrire, prive, squelettes-dist), et ceux marquant l'activité d'un site (config, IMG, tmp, local) sont clairement identifiables et séparés. 

C'est cette séparation qui permet d'avoir plusieurs sites SPIP autonomes pour un même noyau de SPIP.
Cette autonomie repose sur quatre répertoires par site dans lesquels SPIP va écrire les données résultant de l'activité du site. On distingue les données temporaires et permanentes d'une part, et les données accessibles par HTTP et celles qui ne le sont pas d'autre part. Les deux répertoires inaccessibles par HTTP seront protégés par un .htaccess installé automatiquement par SPIP (les administrateurs du serveur peuvent mettre ces répertoires en dehors de l'arborescence servie par HTTP).
Ces quatre répertoires sont distincts et nommés par les constantes PHP suivantes :
define('_NOM_TEMPORAIRES_INACCESSIBLES', "tmp/"); define('_NOM_TEMPORAIRES_ACCESSIBLES', "local/"); define('_NOM_PERMANENTS_INACCESSIBLES', "config/"); define('_NOM_PERMANENTS_ACCESSIBLES', "IMG/"); 
Dans une installation simple de SPIP, ces répertoires sont créés à la racine du site avec les valeurs par défaut ci-dessus.

La mutualisation des sources de SPIP repose sur l'association de quatre répertoires spécifiques à chaque site, déduits de leurs URL.
Initialisation de la mutualisation
Cette association est effectuée par une fonction,

spip_initialisation. Elle admet quatre arguments indiquant la localisation des quatre répertoires fondamentaux, et construit à partir de ceux-ci les constantes servant au fonctionnement de SPIP.

Dans une installation simple, ces quatre arguments sont les quatre constantes ci-dessus. La fonction spip_initialisation est appelée juste après le chargement de mes_options.php, 

et refuse silencieusement de s'exécuter si elle a déjà été appelée.

En conséquence, si dans ce fichier cette 

fonction est appliquée sur des arguments différents déduits de l'URL du site, on aura autant d'utilisation des sources de SPIP que d'URL de site.

On peut aussi définir dans ce fichier les constantes servant au fonctionnement de SPIP, ces définitions ayant priorité sur celles qu'essaiera de définir spip_initialisation.
Le code ci-dessous, placé dans le fichier config/mes_options.php prend le nom de domaine et exécute une mutualisation sur les quatre répertoires tmp, local, config et IMG placés dans le dossier sites/nom_du_domaine/. 

Auparavant, la définition de quelques constantes permet de centraliser les fichiers de journalisation de tous les sites dans un unique répertoire, log, et non dans sites/nom_du_domaine/tmp/ pour chacun. Cette centralisation n'a rien d'obligatoire mais se révèle utile ; elle peut s'appliquer aussi aux répertoires d'aide et de sauvegarde.
 
Mutualiser des domaines ou des sous-domaines
Pour mutualiser plusieurs domaines ou sous-domaines, vous devez tous les diriger vers le répertoire physique contenant SPIP. Par exemple, http://example.org/, http://example.net/ et http://sous_domaine.example.net/, pour les mutualiser, doivent tous pointer sur le même répertoire, comme /var/www/spip/.
Ce dossier contient donc SPIP ainsi qu'un fichier config/mes_options.php pour activer la mutualisation. En reprenant l'exemple de code donné au dessus, il faudra alors créer les dossiers sites et log ainsi que sites/example.org, sites/example.net et sites/sous_domaine.example.net avec dans chacun d'eux les répertoires config, local, IMG et tmp accessibles en écriture. Il n'y a rien d'autre à réaliser. En allant sur l'un des sites, SPIP devrait vous proposer son installation.
Si vous souhaitez pouvoir activer des types d'url différents, comme les « url arborescentes » ou les « url propres », il sera nécessaire de créer un fichier d'accès Http, qui est fourni dans la distribution sous le nom de htaccess.txt : il suffit de le renommer en .htaccess pour le mettre en œuvre. Il s'appliquera à tous les sites mutualisés, mais il est possible d'avoir des accès différenciés en configurant astucieusement le serveur (voir plus bas). Dans les deux cas,

tout cela ne fonctionnera que si votre serveur accepte d'exécuter toutes les directives présentes dans ce fichier, notamment celles concernant

la réécriture d'url (« url rewriting »).
Mutualiser les répertoires d'un domaine
Chaque dossier (virtuel) d'un domaine, en analysant correctement l'URL, peut aussi devenir un site SPIP mutualisé. Il faut pour cela que l'URL du dossier soit redirigée de façon transparente vers la racine du SPIP. C'est le rôle du fichier .htaccess modifié. Ainsi http://example.com/premier_site/ et http://example.com/second_site/ peuvent être chacun des sites SPIP mutualisés (et http://example.com/ aussi).
Dans un premier temps, il faut renommer le fichier htaccess.txt en .htaccess et le modifier pour indiquer que les répertoires qui sont virtuels doivent pointer à la racine de SPIP. Pour cela, ajouter dans la partie « Réglages personnalisés » soit le code générique qui traite tous les répertoires virtuels (mais http://example.com/premier_site sans / final renverra une erreur), soit un code indiquant les noms des dossiers (pas d'erreur si aucun / final) :
// code générique RewriteCond %{REQUEST_URI} !^/(config|ecrire|IMG|prive|plugins|plugins-dist|sites|squelettes-dist|squelettes|tmp|lib|local|mutualisation)/(.*) RewriteRule ^[^/]+/(.*) /$1 [QSA,L] // OU code spécifique RewriteRule ^(premier_site|second_site)$ /$1/ [R,L] RewriteRule ^(premier_site|second_site)/(.*) /$2 [QSA,L] 
Dans un second temps, il faut créer une mutualisation en analysant dans le fichier config/mes_options.php l'url transmise. Voici un exemple pour avoir les sites mutualisés dans sites/exemple.com, sites/premier_site et sites/second_site :
 
Préfixe des tables
Les exemples présentés nécessitent autant de bases de données que de sites mutualisés. Cependant, il est possible d'installer tous les sites dans une même base de données, en préfixant les noms de leurs tables d'un préfixe unique.
L'exemple ci-dessous crée un préfixe de 8 caractères : un préfixe avec les 4 premières lettres du site, suivi de 4 autres caractères.
$table_prefix = substr(str_replace('.', '_', $site),0,4) . substr(md5($site),0,4); 
Fichier config/mes_options.php
Toute modification du fichier config/mes_options.php du noyau SPIP affectera les options de tous les sites hébergés.
Par exemple, mettre dans ce fichier :

$type_urls = 'propres' ;
donnera par défaut à tous les sites ce type d'URL... Mais chaque site peut le changer dans son propre /sites/repertoire_du_site/config/mes_options.php.
Configurer Apache pour les domaines et sous-domaines
La mutualisation côté serveur, pour ce qui concerne la gestion des sous-domaines ou des domaines reste simple. Il suffit de créer une redirection entre le nom de domaine et le répertoire physique où est stocké SPIP.
Voici un exemple de configuration (minimale) pour un serveur nommé 'exemple.tld' utilisant des sous-domaines. Le fichier de configuration est à créer dans /etc/apache2/sites_availables/exemple.tld, qu'il faut ensuite activer
sudo a2ensite exemple.tld sudo /etc/init.d/apache2 reload 
SPIP est installé dans cet exemple dans '/var/www/spip/'.
 ServerName exemple.tld ServerAdmin webmaster@localhost ServerAlias *.exemple.tld DocumentRoot /var/www/spip/  Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all   
Si vous voulez en plus avoir des fichiers d'accès différenciés, il suffit d'utiliser la directive AccessFileName à l'intérieur de la directive 

VirtualHost, de sorte que le fichier d'accès du site S se nomme par exemple .htaccess-S.
Note sur les sauvegardes et les restaurations
Chaque site copie par défaut ses fichiers de sauvegardes dans le répertoire

/sites/premier_site/tmp/dump (ou /sites/premier_site/tmp/upload/login pour les sauvegardes d'un administrateur restreint).
Les restaurations se font par le même dossier. Le chemin des images est aussi correctement pris en compte .

Structure HTML des formulaires de SPIP
ARNO*, cerdic, Matthieu Marcillaud, tetue — 2009-06-27T10:48:14Z
Document de références précisant comment les formulaires dans SPIP doivent être structurés.
		
Sommaire
 Structure HTML
 Les classes spéciales
 Cadre englobant
 Gestion des messages réussite/erreur
 Particularités pour les styles css
Structure HTML
Un formulaire de base est ainsi structuré :
  
  Une légende Un texte d'explication
   Courriel #AIDER{arttitre}  Explication du label
 Message d'erreur  
 
 
  
 
Le div englobant porte la classe générique formulaire_spip. Les formulaires d'édition de l'espace privé portent de plus la classe formulaire_editer indiquant qu'on a affaire à un formulaire d'édition de données d'une base.
Chaque champ de saisie est encapsulé dans un élément de classe .editer, qui doivent être regroupés dans un élement de classe .editer-groupe. Jusqu'à SPIP 3.0 ces classes étaient portées respectivement par des balises html li et ul. A partir de SPIP 3.1 on prend pour convention d'utiliser de simples div pour réduire la verbosité de la synthèse vocale et améliorer l'accessibilité des formulaires.
Le premier fieldset étant optionnel, on peut aussi écrire, sans le fieldset et sans les paragraphes optionnels :
  
   Courriel  
 
  
 
Les classes spéciales
 « explication » : pour indiquer un message d'explication (qui porte soit pour l'ensemble des champs, soit sur une étape). Exemple : .
 « attention » : pour afficher un message concernant un champ d'édition critique. Exemple : <:texte_login_precaution:>.
 « obligatoire » : pour signaler un champ obligatoire, à appliquer à l'élément de liste parent. Exemple : .
 « erreur » : pour signaler une étape en erreur, à appliquer à l'élément de liste parent. Exemple : . chaque erreur bénéficie d'un message explicatif, portant la class « erreur_message » : .
Cadre englobant
Ce formulaire peut optionnellement être inclus dans un cadre-formulaire-editer, et peut alors contenir un entete-formulaire :
 
 
 
 
Gestion des messages réussite/erreur
Messages globaux
Un formulaire comporte obligatoirement deux paragraphes permettant d'afficher les réussites et erreurs globales qui ont pu apparaître à la soumission. Les variables d'environnements message_ok et message_erreur sont des retours envoyés par SPIP (formulaires CVT).
 [(#ENV*{message_ok})
] [(#ENV*{message_erreur})
] 
 
Messages spécifiques
Chaque champ de formulaire, encapsulé dans un .editer peut recevoir un message d'erreur spécifique. Celui-ci est contenu dans le tableau d'environnement 'erreurs' et peut être obtenu de la sorte :
[(#ENV**{erreurs}|table_valeur{nom_du_champ})] 
On peut attribuer la classe 'erreur' à .editer et afficher une erreur spécifique si elle existe de la sorte :
 <:texte_descriptif_rapide:> [(#ENV**{erreurs}|table_valeur{desctiptif})] [(#ENV**{descriptif})] 
 
 Particularités pour les styles css
Champs input
Chaque  différent de hidden doit posséder une classe identique à son type (afin de palier à un déficience du navigateur Internet Explorer) :
 
Boutons de soumission
Les boutons de soumissions sont inclus dans une boîte .boutons (qui peut recevoir plusieurs boutons) :
" />
 
radio/checkbox
Dans le cas de bouton radio ou checkbox, on peut ne pas reprendre tout a fait la même structure, par exemple pour avoir le bouton avant le label, ou pour avoir la liste radio en horizontal.
Chaque entrée (radio + label) peut alors être encadrée par un bloc .choix
   <:bouton_radio_non_syndication:> 
   <:bouton_radio_syndication:>#AIDER{rubsyn} 
 
 
Par défaut, la liste est verticale. Pour rendre la liste horizontale,

il suffit de spécifier que .champ en question est de type inline :
.formulaire_editer .editer_syndication .choix {display:inline;} 
		Principes généraux de ces formulaires pour avoir les labels alignés à gauche
On se retrouve dans un cas où l'on a :
    
      
 
 

1) on applique un padding gauche au .editer supérieur à la taille du label (ex:120px)
.formulaire_spip .editer { margin: 0; padding: 10px 10px 10px 130px; clear:both; border-top: 1px solid #eee; } 
2) on demande au label d'être flottant et décalé sur la gauche (via un margin négatif)
.formulaire_spip .editer label { width: 120px; float:left; margin-left:-125px; text-align: left; vertical-align: top; } 
3) lorsqu'un fieldset suit un .editer, on le décale aussi vers la gauche
 (seul IE n'en tient pas compte) pour que le fieldset prenne toute la
 largeur aussi
.formulaire_spip .editer fieldset { border:1px solid #888; background:white; margin-left:-125px; /* redecalage vers la gauche... IE < 8 ne le prend pas en compte */ } 


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- IMG/

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

SPIP

Les outils utilisés pour le développement

SPIP 4.3

Sommaire

Compatibilité PHP 7.4 à 8.3

Changements apportés par SPIP 4.3

Le bandeau de l'espace privé prend moins de place en hauteur

La création rapide des contenus passe dans un menu dépliant

Le formulaire de changement de statut est revu

Un message avertissant d'une nouvelle version disponible

Ajouts

Changements

Corrections

Dépréciations

Retrait

Plugins-dist

Images

Plugins compatibles

SPIP 4.1

Sommaire

Compatibilité PHP

Compatibilité PHP 8.1

Authentification & Chiffrement

Le formulaire de login

Poivre, sel, hash du mot de passe

Clés de chiffrement

Password

Chiffrement

Signature des actions

Qualité du code

Typage

Sucre syntaxique

Changements d'API sur les URLs et objets

Encodage

Décodage

Objet

Réécriture de transmettre en .api

Mises à jour des librairies

Javascript

PHP

Suppression de librairies

Interface

Nettoyages

Quelques adaptations

Plugins

SPIP 4.0

Sommaire

Interface

Compatibilité PHP

Base de données

Syntaxe des squelettes étendue

#TITRE

Les articles

Les articles

Aucun article

Les articles

Changements et apports pour les squelettes

Autres apports

Corrections

Nettoyages

Dépréciations

Plugins

SPIP 3.2

Sommaire

Javascript

PHP

Core

Plugins

Les itérateurs de SPIP - la boucle (DATA)

Sommaire

Syntaxe et formats de la boucle (DATA)

Filtrage, tri, pagination, fusion

Le critère {liste ...}

Le critère {enum ...}

Protection des données manipulées par les itérateurs

Configurer une fonctionnalité de votre site, ou un plugin

Sommaire

Formulaire de configuration

Configuration d'un plugin

<:mediabox:titre_page_configurer_box:>

Réécriture de `transmettre` en .api

`Plugins`

Syntaxe et formats de la boucle `(DATA)`

Le critère `{liste ...}`

Le critère `{enum ...}`