WP-Apidae 6.3.8 : les pannes qui ne se voyaient pas depuis le tableau de bord

Sur l’un de nos propres sites, 31 sélections sur 32 avaient cessé de se synchroniser depuis onze mois. Le site fonctionnait, l’administration ne signalait rien, et personne ne s’en était aperçu. Chez un office de tourisme, une panne de la même famille n’a été repérée que dix-sept jours plus tard, et par sa chargée de communication. La 6.3.8 corrige ce défaut et plusieurs autres de la même famille : des pannes qui ne se voient pas depuis le tableau de bord. Mise à jour fortement recommandée.

Une synchronisation qui s’arrête ne repartait jamais

WP-Apidae planifie l’import de vos sélections avec Action Scheduler. Le principe est simple : une tâche s’exécute, et en se terminant elle programme la suivante. Le défaut tient dans cette dernière phrase. Quand une tâche est tuée en cours de route, par un délai dépassé sur un gros import ou par une erreur fatale, elle ne programme jamais sa suivante. La chaîne s’arrête, définitivement, et rien ne le dit.

Un garde-fou existait pour rattraper exactement ce cas. En relisant le code, nous avons découvert qu’il était chargé mais jamais mis en service au démarrage de l’extension : il n’avait pas tourné depuis 369 jours. Sur le site où nous l’avons mesuré, 31 sélections sur 32 étaient à l’arrêt depuis onze mois, agenda compris. Rien, dans l’administration, ne l’indiquait.

Ce que fait la 6.3.8 :

le surveillant démarre avec l’extension et reprogramme la sélection dès qu’un import échoue, à son intervalle normal, au lieu de la laisser sortir de la file pour toujours ;
il reconnaît aussi les sélections dont les options de réglage ont disparu, en relisant la taxonomie ;
l’écran des sélections signale visuellement une synchronisation en retard, avec un seuil calé sur la fréquence réglée pour votre site.

L’import peut toujours échouer. Ce qui change, c’est qu’il repart au cycle suivant, et que le retard se voit en attendant.

Quand l’API Apidae ne répondait pas, vos sélections disparaissaient

Celui-ci est le plus lourd de conséquences. La récupération de la liste des sélections traduisait un échec de l’API Apidae, une panne réseau, une clé refusée, un service momentanément indisponible, par une réponse lisible : « aucune sélection disponible ». WP-Apidae en concluait ce qu’il devait en conclure. Toutes les sélections du site passaient en « retirées » et étaient supprimées, avec leurs fiches.

La récupération des sélections respecte désormais le même contrat que le chemin d’import : elle renvoie une liste, ou une erreur, jamais une liste vide pour dire « ça s’est mal passé ». Sur erreur, la mise à jour est abandonnée sans aucune suppression, et sans réécrire la liste enregistrée.

Deux défauts voisins sont corrigés avec lui. Le bouton « Mettre à jour les sélections » répondait « Vos sélections ont été mises à jour » même quand l’API renvoyait une erreur. Et le test de connexion ne vérifiait que le cas « accès interdit » : n’importe quelle autre réponse d’erreur était annoncée comme « Connexion réussie ! », et les identifiants fautifs étaient enregistrés. Un projet Apidae classique configuré avec le mode « Consentement API » activé tombe précisément dans ce cas : la configuration était validée, puis figée, et plus aucune sélection ne remontait. Le message d’erreur renvoyé par l’API est désormais affiché, la clé API masquée.

Des agendas qui servaient des événements terminés

Les dates passées n’étaient écartées qu’au moment de l’indexation. Le résultat se périmait donc tout seul dès qu’Apidae cessait de modifier la fiche : plus une fiche est stable, plus elle a de chances de traîner dans votre agenda après la fin de l’événement. Mesuré sur des sites en production : 74 fiches terminées sur 240 listées, et jusqu’à 287 sur 372.

Le critère est désormais appliqué à la lecture, une seule fois, pour toutes les surfaces d’affichage : blocs, carte, routes REST, widgets Divi et Elementor. Seuls les types événementiels sont concernés. Un hébergement ou un restaurant qui déclare ses horaires n’est jamais écarté.

Deux corrections de tri complètent le tableau. Les listings ordonnaient les fiches sur leur occurrence la plus ancienne, passée comprise : un marché hebdomadaire se classait sur une date de la semaine précédente et passait devant les événements du jour. Et le bloc « Prochains événements » s’appuyait sur la première occurrence historique de la fiche, jusqu’à 277 relevées sur une seule, ce qui lui faisait proposer des événements à trois ou six jours à la place de ceux du jour même.

Sécurité et données personnelles

Cette version referme plusieurs accès qui n’auraient pas dû être ouverts. Nous restons volontairement généraux : tant que des sites tournent en version antérieure, le détail leur servirait de mode d’emploi.

Données des fiches : leur lecture brute est désormais réservée aux utilisateurs qui peuvent éditer la fiche. Rien ne change pour les administrateurs et les éditeurs.
Actions d’administration : plusieurs opérations sensibles ne vérifiaient que le jeton, pas les droits de l’utilisateur. Le contrôle est ajouté sur chacune.
Adresses IP de vos visiteurs : le sélecteur de dates des filtres chargeait sa bibliothèque depuis un CDN tiers. Chaque visiteur d’une page à filtre de dates transmettait donc son adresse IP à ce tiers, sans consentement. La bibliothèque est maintenant livrée avec l’extension, avec ses 66 traductions : un transfert vers un tiers en moins sur vos pages publiques.

Vos modèles s’ouvrent à votre constructeur de pages

Jusqu’ici, les modèles de fiche et de carte se composaient dans l’éditeur de blocs, quel que soit le constructeur utilisé par le site. Sur un site équipé du module correspondant, « Modifier » ouvre désormais l’éditeur du constructeur, l’installation des modèles par défaut ne pose que ce que ce constructeur sait afficher, et les réglages du modèle, type de fiche, nom, fiche d’aperçu, taxonomies associées, restent gérés par WP-Apidae.

Sans module de constructeur, rien ne change : tout reste dans l’éditeur de blocs, y compris les modèles créés avant cette version.

La 6.3.8 est le prérequis technique des deux modules qui arrivent, WP-Apidae Divi 2.0 et WP-Apidae Elementor 2.0. Nous y reviendrons dans un prochain article.

L’assistant de migration progresse au passage : le parcours accueille maintenant les étapes des modules dans un seul enchaînement, et un écran final récapitule ce qui a été fait automatiquement et ce qui reste à vérifier, avec le lien d’édition de chaque contenu concerné. Ce rapport survit à la fin du parcours et s’exporte.

Si votre site utilise le module Divi, lisez ceci avant de mettre à jour

Le module WP-Apidae Divi doit être en version 2.0 ou supérieure pour fonctionner avec ce cœur. Les versions antérieures appellent une fonction supprimée depuis la 6.0 : laissées actives, elles mettent le site en erreur, front et administration compris. La 6.3.8 les neutralise donc au chargement et les désactive, avec un avertissement en administration.

Concrètement, sur un site Divi équipé d’un module antérieur à la 2.0, les contenus WP-Apidae ne s’affichent plus après la mise à jour, et peuvent apparaître sous forme de code sur les pages publiques. Deux précautions :

attendez la sortie du module 2.0, prévue dans les tout prochains jours, et mettez alors les deux à jour dans cet ordre : le cœur d’abord, le module ensuite ;
faites-le sur une copie du site avant la production. Le module 2.0 est une réécriture, et un assistant convertit vos pages existantes : c’est une migration, pas une simple mise à jour ;
vérifiez votre version de PHP. Le cœur demande PHP 8.1, mais le module Divi 2.0 demande PHP 8.2 ;
si vous devez revenir en arrière, sachez que la désactivation est enregistrée en base : restaurer la version précédente de WP-Apidae ne suffit pas, il faut réactiver le module depuis l’écran des extensions, et depuis celui du réseau en multisite.

Le module Elementor, lui, n’est pas concerné : il continue de fonctionner sur ce cœur, tel quel. L’édition des modèles dans Elementor arrivera avec sa version 2.0.

Mettre à jour, et vérifier trois choses ensuite

La mise à jour se fait depuis l’écran des extensions de WordPress. Elle ne demande aucune manipulation et ne modifie ni vos pages ni vos réglages. Elle peut en revanche remettre en route des imports arrêtés, qui rafraîchiront alors vos fiches. WP-Apidae 6.3.8 demande PHP 8.1 et WordPress 6.1 au minimum.

Une fois à jour, trois vérifications valent le détour :

L’écran des sélections. Si une synchronisation était en panne sans le dire, c’est maintenant qu’elle se signale.
Votre agenda. Les événements terminés en disparaissent. Le nombre de fiches affichées peut donc baisser, et c’est le comportement attendu.
Vos pages de listing et de filtres, si vous les aviez adaptées. Le tri par date et le mode liste ont été corrigés, l’ordre affiché peut changer.

La liste complète, une quarantaine d’entrées, est dans le changelog de l’extension, accessible par le lien de détails de la version sur votre écran des extensions.

Une question sur cette version, ou un doute sur votre configuration ? Écrivez-nous depuis le support, nous regardons avec vous.