Je suis passé à SPIP 4.0

Introduction

Je me suis décidé à passer à SPIP 4.0 en cette rentrée 2021. Pour être honnête, j’avais un peu peur de ce passage car j’avais quitté un peu l’actualité de SPIP (ses développements, son évolution, etc.). Je ne savais pas où j’allais mettre les pieds même si j’ai toujours aimé ce CMS. Je vais vous parler de mon chemin vers son adoption.

Par beau temps

Mon site était sous SPIP 3.2.9. Et j’utilise Zcore avec un template maison basé sur Bootstrap. Jusque là, rien de bien méchant. J’ai décidé de profiter de cette montée de version de SPIP pour revoir mon template et avoir également la dernière version de bootstrap : 5.1.1

J’ai dû retravailler les différentes classes que j’avais. Pas trop méchant. J’ai fait les choses étape par étape. Avant de migrer pour SPIP 4.0, j’ai fait la mise à jour de SPIP en 3.2.11 qui permet d’avoir la compatibilité PHP 7.4 (la version minimum pour SPIP 4.0 est PHP 7.3).

Mon hébergeur, OVH pour ne pas le citer, prend en charge cette version de PHP. Ouf.

Début septembre, j’ai mis en ligne mon template avec bootstrap 5.1.1 et SPIP 3.2.11. Cela me laissait le temps de tester en "live" la compatibilité avec PHP 7.4. Une lettre à la poste par beau temps !

Puis vint la pluie…

SPIP 3.2.11, PHP 7.4, Boostrap 5.1.1, c’était trop beau pour être vrai ! J’ai testé en local le passage à SPIP 4.0. Depuis le back-office, belle page avec la nouvelle interface de l’espace privé. Responsive, prenant toute la largeur de la fenêtre, c’est beau ! Certains diront que l’espace privé n’a pas changé depuis sa création, mais en fait tout a changé ! Il est plus light, plus agréable avec ces nouveaux jeux d’icônes SVG.

Puis, j’ai cliqué sur le bouton "voir le site public"… Et patatra ! La page met du temps à se charger… Je me dis que ce n’est que le cache qui se recalcule… Et ben non, j’ai une belle erreur php me disant soit que je n’ai suffisamment de mémoire allouée (mouais… 128Mo puis 256Mo…), soit qu’il ne trouvait pas une variable dans les scripts php…

Panique à bord !

Je cherche… désespérément… Je regarde mes scripts PHP maison en pensant trouver la bonne piste… Et non, rien y fait. J’y passe des heures sur le sujet, je change même d’environnement : d’un raspberry Pi avec LAMP, je passe sous MAMP sur mon mac et même en preprod sur mon espace d’hébergement. Rien y fait. Toujours ces erreurs aléatoires. Pourtant, tout fonctionne sous SPIP 3.2.11 en PHP 7.4.

Je sais que la gestion des documents et des logos a changé sous SPIP 4.0. Et j’utilise avec grand plaisir les filtres sur mes templates. Je décide alors d’aller vers cette piste.

Mes images sur mon site sont en moyenne à 2500px de largeur. Ça me permet d’avoir des images de bonnes dimensions et de pouvoir les redimensionner selon mon design. Je décide de venir à une version plus allégée de mes filtres. Suppression des filtres image_passe_partout, image_recadre, image_aplatir et j’en passe. Rien y fait !

Je peste sur mon idée de passer à SPIP 4.0 avec la méthode R.A.C.H.E. Même en sachant que SPIP 4.0 avait changé son approche pour les logos, je ne pensais pas que cela allait être aussi compliqué.

J’utilise un modèle nommé "logo.html". Ce modèle me permet de ne pas dupliquer mes filtres pour les visuels de mes articles, rubriques et cie. Je décide de l’ouvrir dans PHPStorm par raccourcis clavier "Search everywhere". Je tape donc modeles/logo.html. Et OH ! Surprise ! le plugin medias utilise un modèle logo en SPIP 4.0.

Ah tiens… En fait, j’étais tellement subjugué par la nouvelle interface que je n’avais pas remarqué qu’aucun de mes logos d’articles ne s’affichait. J’ai regardé en base de données dans la table spip_documents comment SPIP indique les logos d’articles. Je pige le truc rapidement. J’adopte la méthode R.A.C.H.E… La migration des données par SPIP n’a pas bien insérée les "anciens" logos dans la table de documents. Que cela ne tienne ! Je crée un petite fonction PHP qui va insérer dans la bdd mes logos d’article (de rubriques et de sites) en respectant les bons chemins (exemple : logo/arton-XX.png). Ça se fait rapidement.

Je reviens au fichier modeles/logo.html du plugin medias. Je consulte ce fichier et constate son extrême simplicité et efficacité :

[<a href="(#ENV{lien})">]<img
	src="#ENV{logo_on}"
	class="spip_logo[ spip_logo_(#ENV{align})][(#ENV{logo_off}|oui)spip_logo_survol]"[
	width="(#ENV{width})"][
	height="(#ENV{height})"]
	alt=""[
	data-src-hover="(#ENV{logo_off})"]/>[(#ENV{lien}|?{</a>})]

Je n’ai pas trouvé exactement où était appelé ce fichier. Mais j’ai pour principe de ne jamais utiliser les même noms que dans un framework. Cela évite les effets de bord indésirables. Donc, je renomme mon modèle maison en modeles/visuel.html. Cela colle bien à son utilisation première.

Une île paradisiaque au loin

Suite à ce renommage, je commence à avoir de nouveau un début de page sur mon espace public. Il y a encore quelques petits effets à régler. Des warnings plus compréhensibles. Je m’attèle à régler ça.

J’adopte de façon systématique (pas comme les antibiotiques) l’utilisation de modeles/visuel.html, je vide les répertoires local, tmp/cache et tmp/logs/ avant chaque grosse modification. Le site est à nouveau opérationnel et je retrouve le même template que j’utilisais en SPIP 3.2.21 en production en début de mois de septembre.

Je respire enfin. L’espoir en moi renait.

Un avenir radieux

Je teste toujours sur mon propre site la dernière version de SPIP avant de la proposer à mes clients. Ainsi, j’aurais déjà essuyé les plâtres. Il sera plus simple pour passer la peinture chez les clients.
L’erreur était toute bête, mon modèle logo gênait SPIP dans sa nouvelle monture. Ma surcharge changeait le comportement attendu. Je suis incapable de dire exactement pourquoi cela faisait planter PHP. Je n’ai pas cherché à le savoir non plus pour être franc.

Je constate surtout que SPIP est plus rapide. Merci PHP 7.4, merci à la core team d’avoir rendu SPIP plus léger et véloce. Je sais que si je passe à PHP 8.0, cela sera encore plus rapide. Mais j’ai plusieurs sites sur mon hébergement OVH qui ne sont pas compatibles PHP 8.0.

Vous pouvez consulter le résultat de cette migration en lisant cet article. En effet, en ce mardi 14 septembre, mon site est officiellement sous SPIP 4.0 sous vos yeux ébahis !

Et la suite ?

J’ai commencé à travailler sur mes plugins de la communauté pour une compatibilité avec SPIP 4.0 :

• Info SPIP
• Socicon
• Lister les constantes PHP de SPIP
• Lister les pages de configuration
• Lister les pages ?exec=xxx
• Lister les fonctions PHP de SPIP
• Lister les objets principaux de SPIP
• Lister les dossiers
• Commits de projet
• jQuery Vector Maps
• Projets (je ne fais que la maintenance de ce plugin, je n’en suis pas le créateur, je tiens à le préciser)
• Sites pour projets

Il m’en reste quelques uns à migrer dont le plus gros : InfoSites. Il est dans les bacs. Il est dépendant d’un plugin qui est en attente de mise en compatibilité avec SPIP 4.0. Plus qu’un pour pouvoir livrer la v2 de ce plugin qui me tient à cœur.

Fin de vie pour…

La liste précédente est plutôt longue. Mais il y aura des "laissés pour compte" dans la course à SPIP 4.0. En effet, selon ma vision, un plugin n’a plus lieu d’être :

• Agrandir la largeur de page (SPIP_hop pour les intimes) : l’interface de l’espace privé a été revu pour prendre toute la largeur de la fenêtre et va même plus loin que ce qu’offrait spip_hop. Je ne vois pas l’utilité de le maintenir pour SPIP 4.0

Pour le moment, je n’ai plus le temps/besoin pour certains autres plugins. Donc leur mise à jour est repoussée à une date ultérieure :

• Déréférencer les médias ;
• Nettoyer la médiathèque.

Voilà le périple que j’ai connu avec SPIP 4.0. Je n’ai pas de regrets pour mon passage vers cette dernière version. Au contraire. :-)