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

Comprendre les versions de SPIP

Maïeul — 2024-11-20T14:18:00Z

Comment comprendre les numéros de version de SPIP ? Comment savoir s'il faut mettre à jour ?

Sommaire

Versionnement sémantique

Depuis 2024, SPIP a adopté le versionnement sémantique.

Voici un résumé de son fonctionnement, pour les détails on se réferera à la documentation officielle .

Chaque version de SPIP est désignée par 3 nombres, séparés par un point : x.y.z.

Lorsque le z est augmenté, c'est une mise à jour corrective. Cela peut corriger des bugs ou bien une faille de sécurité. La fréquence de sortie des versions correctives est d'environ une fois par mois.

Lorsque le y est augmenté, c'est une mise à jour mineure. De nouvelles fonctionnalités sont ajoutées et des bugs résolus, mais il n'y a pas besoin d'adapter son code / ses squelettes. La fréquence de sortie des versions mineures est approximativement une fois tous les six mois.

Lorsque le x est augmenté, c'est une mise à jour majeure. Des nouvelles fonctionnalités sont ajoutées, d'anciennes sont retirées, certaines changent. Il peut y avoir besoin d'adapter son code / ses squelettes. Une note de version indique les changements à faire. La fréquence de sortie des versions majeures est d'environ tous les 24 mois.

Les mises à jours sont annoncées sur le blog de SPIP. Il est fortement conseillé de s'inscrire à la mailing list d'annonce.

Les surcharges et le versionnement sémantique

Le principe du versionnement sémantique permet de s'assurer qu'il n'y ait pas de rupture de compatibilité / de changement à faire lorsqu'on augmente un y ou un z.

Toutefois, il est possible dans SPIP de surcharger des squelettes. Mais attention aux surcharges des squelettes de l'espace privé. Ce mécanisme de surcharge, puissant, est ici dérogatoire au versionnement sémantique : il peut y avoir des modifications dans les paramètres passés à un squelette lors d'une mise à jour corrective ou mineure.

Une personne surchargeant un squelette de SPIP le fait donc à ses risques et périls, et en conscience.

Notions de branche

Une combinaison d'un x et d'un y correspond à une branche de SPIP. En général, deux branches sont maintenues en même temps, permettant ainsi aux personnes de prendre le temps de migrer. Voir à ce sujet l'article Versions maintenues.

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

Utiliser les plugins

cy_altern, erational, jack, Maïeul — 2023-12-04T18:46:13Z

Qu'est ce qu'un plugin ?

SPIP est fourni avec un nombre de fonctionnalités standard (le noyau ou "core").

Il arrive souvent qu'on ait besoin d'autres fonctionnalités comme par exemple un agenda, une newsletter .... Pour répondre à ces besoins particuliers, SPIP dispose d'un système de plugins (parfois appelé "extensions") à travers une API normalisée qui permet de se brancher ("plug" en anglais) au système pour y ajouter ou compléter des fonctions.

Organisation de plugins

Il existe deux types de plugins :

- Les plugins fournis par défaut dans SPIP
Ils sont placés dans le répertoire réservé ./plugins-dist/. Ces "plugins-dist" sont verrouillés et il n'est pas possible de les désinstaller. Ils sont mis à jour lors de chaque mise à jour de SPIP.

- Les plugins spécifiques au site
Ils sont placés dans le répertoire ./plugins/
Si vous souhaitez pouvoir les installer et mettre à jour automatiquement, il faudra créer un sous-répertoire ./plugins/auto/. (Ce sous-répertoire est automatiquement créé si vous installez SPIP via le spip-loader)

Utiliser SVP le gestionnaire des plugins de SPIP

SPIP dispose d'un système automatisé pour gérer les plugins qui s'appelle SVP (acronyme de "SerVeur d'information et de téléchargement des Plugins").

Il permet de gérer et de mettre à jour au quotidien les plugins.

La gestion des plugins est réservée aux administrateurs-trices complet-es du site.
L'ajout, la mise à jour et suppression des plugins sont restreints aux webmestres.

Gérer les dépôts

SVP va chercher les plugins disponibles dans un "dépôt".
Lors de la première installation le webmestre doit installer le dépôt et valider avec son mot de passe.

Par défaut le dépôt "principal" "SPIP-Zone - Plugins" est proposé.

Il est possible d'ajouter d'autres dépôts.
Certains dépôts sont listés sur https://plugins.spip.net/spip.php?page=depots

Pour des raisons de sécurité, il est nécessaire de saisir son mot de passe pour installer un nouveau dépôt.

Chercher et trouver le plugin

Il est possible de rechercher le plugin via l'interface de SVP, "ajouter un plugin"
Il est peut être utile de rechercher le plugin adapté à votre besoin sur le site dédié aux plugins SPIP : https://plugins.spip.net/

Ajouter un plugin

Lorsque vous avez trouvé votre plugin, vous le sélectionnez et demandez son installation "télécharger et installer" ; SVP va alors proposer d'installer le plugin avec toutes les dépendances nécessaires à son fonctionnement.

Une fois installés certains plugins proposent un bouton "Configurer" qui permet d'ouvrir un formulaire de configuration.

Mettre à jour un plugin

Un plugin comporte un numéro de version sous la forme x.y.z où

z représente une correction mineure,
y représente un ajout de fonctionnalités,
x représente un changement majeur présentant des risques d'incompatibilité.

Lorsqu'une mise à jour est disponible (et que l'installation a été faite par SVP) une information s'affiche :

Une mise à jour corrective est disponible (up de z)
Une mise à jour fonctionnelle est disponible (up de y)
Une mise à jour majeure est disponible (X.0.0). Pensez à vérifier les incompatibilités. (up de x)

Désactiver, Désinstaller et/ou Supprimer

Les webmestres ont plusieurs options pour retirer un plugin installé :

Désactiver : le plugin passe dans les plugins inactifs,
Désinstaller : supprime les données et les paramètres de configuration du plugin, le plugin passe dans les plugins inactifs,

Lorsque le plugin est inactif il est maintenant possible de le :

Supprimer : supprime les fichiers du plugins, pas les données ;
Réactiver : si le plugin a été désactivé (et non désinstallé) on retrouvera toutes les données et les paramètres.

NB :
- Par conséquent, pour retirer complètement un plugin et ses données, il faut d'abord le désinstaller, puis le supprimer.
- Attention, ne pas oublier que désinstaller entraîne une perte de données

Méthodes alternatives pour gérer les plugins

Ajouter un plugin manuellement via l'interface SVP

Il est possible d'installer un plugin manuellement via l'interface SVP, avec par exemple une version de zip récupérée sur git.spip.net.
Pour des raisons de sécurité il est nécessaire de saisir son mot de passe webmestre lors de toute installation de plugin de cette manière.

Gestion des plugins par FTP

On peut déposer les plugins avec transférant par FTP les fichiers des plugins dans le répertoire ./plugins/. Une fois déposé, il faudra activer les plugins via SVP.

Attention, cette méthode ne permet pas de mettre à jour automatiquement les plugins.

Gestion des plugins par SPIP-Cli

SPIP-Cli permet de gérer un site en ligne de commande. Il existe plusieurs commandes dédiées à la gestion des plugins. Pour en savoir plus se reporter à la documentation officielle de SPIP-Cli
https://contrib.spip.net/SPIP-Cli

Créer son plugin

Si vous ne trouvez le plugin correspondant à vos besoins, il est toujours possible de le créer !

Pour apprendre à coder, vos propres plugins :
https://programmer.spip.net/-Developper-des-plugins-

A noter : le plugin La fabrique permet de créer d'une façon simple et rapide un plugin à partir de zéro
https://contrib.spip.net/La-Fabrique

Tenir un CHANGELOG

Maïeul — 2023-07-26T17:27:03Z

Les fichiers de CHANGELOG suivent la norme Tenez un Changelog.

Sommaire

Qu'est-ce qu'un changelog ?

Un changelog (journal des modifications) est un fichier qui contient une liste triée antéchronologiquement des changements notables pour chaque version d'un projet.

Pourquoi tenir un changelog ?

Pour permettre aux personnes qui utilisent et contribuent de voir précisément quels changements notables ont été faits entre chaque publication (ou version) d'un projet.

Plus de détails sur https://keepachangelog.com.

Chaque entrée du changelog doit :

référencer le ticket (ou la PR s'il n'y a pas de ticket correspondant) ;
décrire clairement et de manière concise les modifications apportées par la PR ;

Pour chaque version, indiquer le numéro de version suivi de la date au format ANNÉE-MOIS-JOUR.

Les entrées sont regroupés par catégorie. Voici les catégories utilisées dans SPIP.

Type d'entrée	Signification
Added	Pour les nouvelles fonctionnalités
Changed	Pour les changements aux fonctionnalités préexistantes
Deprecated	Pour les fonctionnalités qui seront bientôt supprimées
Removed	Pour les fonctionnalités désormais supprimées
Fixed	Pour les corrections de bugs
Security	En cas de vulnérabilités

Exemple de Changelog simple

# Changelog ## 1.0.2 - 2023-07-25 ## Fixed - Ne pas afficher le texte du modèle `icone` et le mettre en `title` du lien ### Changed - mise à jour du README.md maintenant que la doc est sur contrib ## 1.0.1 - 2023-06-22 ### Added - ajout d'un CHANGELOG.md ### Changed - compatibilité SPIP 4.1+ - mise à jour de la documentation dans le README.md

Exemple de changelog complet

Pour un exemple plus complet, voir celui de SPIP.

Écrire un message de commit

Maïeul — 2023-07-26T17:24:48Z

Les messages des commits dans SPIP suivent les spécifications des Commits Conventionnels. Ceci facilite la relecture a posteriori de l'historique du code, ainsi que l'analyse des PR.

Le corps du message doit être clair et explicatif : décrire le problème traité et les évolutions ou corrections apportées.

Sommaire

Structure d'un commit conventionnel

Première ligne commençant par le type de commit, suivi de deux points (:), suivi d'un message résumant le commit.
Le type peut éventuellement être complété par un scope entre parenthèses afin de préciser le composant ou la fonctionnalité modifiée.
Optionnellement, on peut ajouter, après une ligne vide, un ou plusieurs paragraphes complémentaires décrivant plus en détail le commit. La syntaxe Markdown peut être utilisée.
Enfin, une dernière ligne (séparée des précédentes par une ligne vide) doit contenir une référence au ticket auquel est lié le commit. La référence prend la forme suivant Refs: #XXX, ou Fix: #XXX pour fermer le ticket automatiquement lors de la fusion dans la branche de destination.

Exemple de commit conventionnel

Exemple de log de commit complet :

fix: réparer le lien vers la licence GPL dans le pied des pages du privé en le remplaçant par un simple lien vers le site officiel gnu.org Fix: #5328

Liste des types de commit

Convention utilisée dans SPIP.

Type	Signification
build	Modifie un script de compilation du programme ou modifie des dépendances externes. Indique également une montée en version.
change	Modifie l'implémentation d'une fonctionnalité — peut modifier des signatures de fonctions (≠ refactor)
chore	Travail de fond n'altérant pas le code (sortir une version, regénérer du code compilé)
ci	Relatif à l'intégration continue
deprecate	Déprécier (sans l'enlever) une fonctionnalité
docs	Relatif à la documentation (docs, readme, changelog)
feat	Ajoute une fonctionnalité
fix	Corrige un problème
i18n	Relatif aux traductions et chaînes de langue
perf	Améliore la performance d'algorithme ou du programme
refactor	Réécriture de code, sans en modifier l'API
remove	Suppression de code ou de fonctionnalité (déprécié auparavant)
revert	Annule une modification précédente (commit)
security	Relatif à la sécurité
style	Relatif aux règles d'écriture du code (Coding Standard)
test	Relatifs aux tests du logiciel

Pour aller plus loin

Se référer au site www.conventionnalecommits.

Migration d'un squelette de SPIP 2 vers SPIP 3

JLuc, Maïeul — 2019-01-04T15:39:35Z

Ainsi que sa numérotation l'indique, la version SPIP 3 est une version majeure de SPIP, qui apporte de nombreuses et importantes fonctionnalités. Dans l'ensemble, l'équipe de SPIP s'est assuré que les sites fonctionnant avec SPIP 2 fonctionnent également avec SPIP 3.

- Base de données : la mise à jour se fera sans encombre mais aussi, comme toujours, sans possibilité de revenir à SPIP 2. Comme pour toute migration, il est donc recommandé de faire une sauvegarde de la base de donnée dans sa version SPIP 2 avant de faire une migration de vos sites vers SPIP 3, afin de vous ménager la possibilité de revenir à SPIP 2.

- Plugins : l'API ayant été modifiée, une modification du code des plugins est souvent requise pour SPIP 3, soit pour simplement fonctionner, soit pour bénéficier des nouveaux apports de SPIP 3. De nombreux plugins distribués par la zone sont d'emblée compatibles avec SPIP 3 ou bénéficient d'une version adaptée pour SPIP 3.
Si jamais vous avez réalisé vous même un plugin et que vous devez le porter en SPIP 3, un bloc note a collecté un ensemble de points destinés à faciliter sa migration. Voyez l'article "Migration de Plugins de SPIP2 à SPIP3" du Carnet SPIP. Au besoin, vous pouvez aussi demander de l'aide sur les listes ou IRC.

- Squelettes : Les éléments du langage SPIP 2 sont tous valables en SPIP 3. Bien que très rarement rencontrées, il existe toutefois de petites incompatibilités dans certaines configurations de squelettes, qui nécessiteront donc une adaptation, et ce d'autant plus que vous utiliserez des fonctionnalités profondes.

C'est sur ce dernier point : les rares incompatibilités du langage de squelette, que porte cet article.

Chaînes de langues déportées dans des plugins

Un grand nombre de fonctionnalités du noyau de SPIP sont désormais déportées dans des plugins, et avec elles les chaînes de langues qu'elles utilisent. En conséquence, pour y faire appel dans les squelettes, il faut les préfixer par le préfixe du plugin correspondant si vous les utilisez dans vos squelettes.

Par exemple,

<:forum_texte:>

doit pour SPIP3 être remplacé par

<:forum:forum_texte:>

A propos des chaines de langues, voyez la doc sur les nouveautés des chaînes de langues avec SPIP 3.

Formulaire inscription

La balise #FORMULAIRE_INSCRIPTION n'est jamais totalement vide en SPIP3 , même quand les inscriptions ne sont pas autorisées sur le site. En conséquence, elle ne pourra pas servir pour conditionner un affichage (par exemple [(#FORMULAIRE_INSCRIPTION) lien vers la page d'inscription] affichera toujours le lien).

A la place, il faut tester directement la configuration du site SPIP. Il existe deux entrées pour cela :
- accepter_visiteurs
- accepter_inscriptions

Exemple :

[(#CONFIG{accepter_visiteurs}|=={oui}|oui) ]

Critère `{id_parent}`

Avec SPIP 3, cette boucle ne fonctionne pas de la même manière qu'avec SPIP 2

 #ID_RUBRIQUE

En effet :
- si il y a une boucle RUBRIQUES englobante, {id_parent} prend le #ID_RUBRIQUE de la boucle englobante
- s'il n'y en pas, id_parent prend le #ENV{id_parent},

En SPIP 2 {id_parent} prend #ENV{id_rubrique}.

En conséquence, avec SPIP 3, il est désormais possible d'écrire {id_parent ?}{id_rubrique ?}.

Pour migrer une telle boucle, il faut :
- appeler l'url avec un paramètre id_parent supplémentaire ;
- ou adapter la boucle en mettant un critère supplémentaire {id_parent ?}{id_rubrique ?}.

Dans certains cas, le critère suivant a son utilité pour remplacer {id_parent} en assurant la compatibilité d'un squelette entre versions SPIP 2 et SPIP 3 : {id_parent=#ENV{id_parent,#ENV{id_rubrique}}}.

Boucles `FORUMS` et `ARTICLES` imbriquées

Avec SPIP 2, la table forums comporte plusieurs champs id_article, id_breve et id_rubrique qui permettent certaines boucles.

Ces boucles doivent être adaptées pour fonctionner avec SPIP 3 puisque ces champs ont été remplacés par deux champs objet etid_objet.

Ces deux champs permettent de mettre des forums sur n'importe quel objet éditorial, que ce soit des mots, des documents ou tout autre objet créé par un plugin.

Par exemple, les emboitements suivants ne marchent plus :

...

ou :

  #ID_ARTICLE

En SPIP 3 on corrige en :

  #ID_ARTICLE

ou bien avec :

 etc...

Titres et rangs

#TITRE bénéficie désormais d'un traitement qui enlève automatiquement le n° qui préfixe éventuellement le contenu.

La plupart du temps, c'est bien ce comportement qu'on recherche, et il est donc inutile d'appeler le filtre supprimer_numero comme il le fallait avant. Si toutefois vous voulez afficher le titre avec son numéro, il faut enlever ce traitement, c'est à dire employer #TITRE*.

Cette différence de comportement par défaut peut avoir des conséquences sur des squelettes qui feraient des comparaisons dans un critère, car le traitement n'est par contre toujours pas appliqué sur le champ 'titre' lorsqu'il figure en partie gauche d'un critère.

Par exemple :

 #TITRE|recuperer_numero} > etc...

Cette boucle pour afficher les articles de rangs supérieurs au rang de l'article courant ne marchera plus puisque #TITRE ne renvoie plus de numéro. À la place, il faut employer la balise avec étoile #TITRE*.

 #TITRE*|recuperer_numero} > etc...

Modèles

Les modèles reçoivent maintenant l'environnement. Tous les paramètres de contextes, présents dans l'environnement d'appel ou explicitement passés en paramètre de l'appel, avec une priorité à ces derniers, sont à la fois accessibles par #VARIABLE et en #ENV{variable}. Des adaptations sont donc nécessaires dans certains modèles.

À titre d'exemple, un modèle inclus dans le corps de l'article 18 et donc noté : transmet 2 informations supplémentaires :

 #ENV{article18} => #ENV{id_article} => 18

Dans le cas où l'appel du modèle inclue id_article comme paramètre () c'est bien cet id_article là (2) qui sera transmis, quel que soit l'id de l'article dans lequel ce modèle est appelé (comportement : comme avant).

En revanche, lorsqu'on ne passe pas de paramètre explicite, le comportement sera différent, si le modèle fait appel :
- au critère conditionnel {id_article?} dans une boucle
- à un test sur [(#ID_ARTICLE) affichage si id_article]
puisque dans tous les cas #ID_ARTICLE ou #ENV{id_article} existera.

Pour corriger lorsque ce sera nécessaire, il est possible :
- de changer de nom de paramètre pour enlever l'ambiguité
- d'utiliser le fait que seuls les paramètres passés explicitement lors de l'appel du modèle sont accessibles en plus par #ENV{arg/variable}, à la différence des paramètres non explicites passés automatiquement au contexte.

Ainsi on pourra remplacer un critère conditionnel {article ?} par la combinaison de deux critères :

{id_article >= #ENV{args/id_article, 0}} {id_article <= #ENV{args/id_article, 99999999}}

Balise `#FOREACH`

La balise #FOREACH disparaît. A la place il faut utiliser une boucle itérateur DATA.

 #CLE / #VALEUR

Si c'est juste pour afficher le contenu des tableaux#ENV ou #CONFIG, il est aussi possible d'utiliser :

[(#ENV**|unserialize|print_r{1})
] [(#CONFIG**|unserialize|print_r{1})
]

Avec le plugin developpement on pourra plus simplement écrire :
[(#ENV|bel_env)] ou [(#CONFIG|bel_env)]

Boucles avec jointures

Certaines jointures qui devaient être explicitées dans SPIP 2 se font désormais automatiquement.

Exemple : jointure de spip_rubriques avec spip_mots.

Le commit 90091 remplace la boucle SPIP 2

par la boucle SPIP 3

Table de liens

Les tables de liaisons sur les mots ou sur les auteurs, qu'il y avait pour chaque objet spip spip_mots_articles, spip_auteurs_articles, spip_mot_breves, spip_mot_rubriques... ont toutes été fusionnées en spip_mots_liens et spip_auteurs_liens.

Au lieu d'une seule colonne id_article ou id_breve ou id_rubrique comme l'avaient chacune des tables disparues, les nouvelles tables génériques de lien ont deux colonnes génériques : objet etid_objet. Elles peuvent ainsi décrire les liens avec mots et auteurs de tous les objets : ceux livrés avec SPIP, et ceux créés par les plugins.

Cela ne change rien pour les boucles simples qui ne mentionnent pas ces tables de liaison même si SPIP les utilise grâce à l'ingéniosité de son compilateur de boucles.

En revanche, il faut évidemment modifier les boucles plus complexes qui référencent explicitement ces tables, si jamais il y en a dans vos squelettes.

Exemple : dans c90093, la boucle avec double jointure explicite, dont une sur mots_rubrique

 =(#CONFIG{soyezcreateurs/age_goodies,30})} />

est remplacée par les deux boucles imbriquées :

  =(#CONFIG{soyezcreateurs/age_goodies,30})}{lang} />

Jointures sans critère identifiant

Dans une boucle avec jointure implicite, si vous ne spécifiez pas l'identifiant sur laquelle la jointure se fait en critère de boucle, SPIP ne pourra plus deviner sur quel type d'objet vous bouclez, et il n'y aura que #ID_OBJET à disposition.

Par exemple si vous avez en SPIP 2 une boucle :

#ID_ARTICLE

il faudra la remplacer par :

#ID_OBJET

Fort heureusement, ce besoin est assez rare, car le problème ne se pose pas dés qu'il y a un critère portant sur {id_article} dans la boucle. En effet, le compilateur de SPIP détecte ce critère et s'en sert pour comprendre d'où vient l'#ID_ARTICLE demandé dans le corps de la boucle.

Personnalisation des urls publiques

Si vous définissez des modèles d'urls publiques personnalisées, vous devrez renommer les fonctions qui les définissent.

Par exemple, pour la balise #URL_ARTICLE , renommez la fonction generer_url_article en urls_generer_url_article_dist. Et pour les adresses des documents insérés par les modèles dans un article, renommez la fonction generer_url_document en urls_generer_url_document_dist

$GLOBALS['controler_dates_rss']

Maïeul — 2010-05-31T06:24:42Z

Cette variable globale définit si SPIP doit vérifier les dates des éléments des flux rss des sites syndiqués.

Lorsque SPIP intégre les articles issus d'un flux RSS dans sa base de données, il vérifie la date des articles :

si l'article a plus d'un an
ou s'il est daté de plus de deux jours dans le futur

Si l'une de ces conditions est remplie, SPIP considère alors qu'il y a une erreur dans la date de l'article, et remplace celle-ci par la date courante.

Il est possible de désactiver ce comportement en définissant la variable $controler_dates_rss comme false dans le fichier config/mes_options.php (voir l'article qui lui est consacré)

Exemple :

// ne pas modifier la date des articles syndiqués $GLOBALS['controler_dates_rss'] = false;

#VAL

Maïeul — 2009-06-18T09:15:46Z

La balise #VAL prend un paramètre qui est retourné tel quel.

Sommaire

Voir aussi

Elle permet par exemple, d'appliquer des filtres sur des constantes.

[(#VAL{<:chaine_de_langue:>}|image_typo)] est équivalent à <:chaine_de_langue|image_typo:>

Exemple

Si vous désirez attribuer une feuille de styles (.css) par jour de la semaine, vous pouvez procéder de la manière suivante :

[]

Des feuilles de styles nommées respectivement jour_0.css à jour_6.css (traduire : jour_dimanche.css à jour_samedi.css)

Voir aussi

#SQUELETTE

Maïeul — 2009-03-11T12:33:19Z

#SQUELETTE retourne le chemin du squelette courant.

- Balises / #SQUELETTE, SPIP 1.9.1

SPIP

Les outils utilisés pour le développement

Comprendre les versions de SPIP

Sommaire

Versionnement sémantique

Les surcharges et le versionnement sémantique

Notions de branche

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

Utiliser les plugins

Sommaire

Qu'est ce qu'un plugin ?

Organisation de plugins

Utiliser SVP le gestionnaire des plugins de SPIP

Gérer les dépôts

Chercher et trouver le plugin

Ajouter un plugin

Mettre à jour un plugin

Désactiver, Désinstaller et/ou Supprimer

Méthodes alternatives pour gérer les plugins

Ajouter un plugin manuellement via l'interface SVP

Gestion des plugins par FTP

Gestion des plugins par SPIP-Cli

Créer son plugin

Tenir un CHANGELOG

Sommaire

Qu'est-ce qu'un changelog ?

Pourquoi tenir un changelog ?

Exemple de Changelog simple

Exemple de changelog complet

Écrire un message de commit

Sommaire

Structure d'un commit conventionnel

Exemple de commit conventionnel

Liste des types de commit

Pour aller plus loin

Migration d'un squelette de SPIP 2 vers SPIP 3

Sommaire

Chaînes de langues déportées dans des plugins

Formulaire inscription

Critère {id_parent}

Boucles FORUMS et ARTICLES imbriquées

Titres et rangs

Modèles

Balise #FOREACH

Boucles avec jointures

Table de liens

Jointures sans critère identifiant

Personnalisation des urls publiques

$GLOBALS['controler_dates_rss']

#VAL

Sommaire

Voir aussi

#SQUELETTE

Critère `{id_parent}`

Boucles `FORUMS` et `ARTICLES` imbriquées

Balise `#FOREACH`