Projet

Général

Profil

Actions

Bug #526

fermé

Study #521: Régler les problèmes liés à la date de dernière modification

Identifier le code qui ajoute la date de dernière modif ACF

Ajouté par ggallais il y a 11 mois. Mis à jour il y a 11 mois.

Statut:
Closed
Priorité:
High
Assigné à:
-
Catégorie:
-
Début:
15/01/2025
Echéance:
% réalisé:

100%

Temps estimé:
Découvert le:
15/01/2025
Affecte:
Desktop
Opquast:
Lot:
S02
Avis équipe:
Passage recette / prod:
à discuter ED:
Non
Environnement:

Description

Quand un article est publié, normalement, y'a un bout de code qui remplit sa date de dernière modif ACF avec la date de publication WP core.

Pour résoudre les 666 problèmes de date ACF, faut qu'on identifie :

  • quel est ce code ? (où il est)
  • à quel moment il se lance

Fichiers

Mis à jour par ggallais il y a 11 mois

  • Priorité changé de Normal à High

Mis à jour par ggallais il y a 11 mois

  • Lot mis à S02

Mis à jour par ggallais il y a 11 mois

Medhy ne voit pas ce code dans le thème, même en regardant les anciennes branches (avant et après la livraison Inovagora).
Je lui ai demandé de vérifier les plugin MU, les dropin : on le trouve pas.

Une possibilité c'est qu'il ait sauté par erreur à un moment (livraison, changement d'hébergeur - cf. reorg pour supprimer l'install bedrock).
Mais c'est moins cohérent avec le fait qu'on le trouve pas.

Une autre possibilité c'est que ce code n'ai jamais existé.
Faut re-tester pour voir si seulement le fonctionnement a bien lieu.

Mis à jour par ggallais il y a 11 mois

  • % réalisé changé de 0 à 10

Mis à jour par ggallais il y a 11 mois

Alors dossier_maj est bien rempli automatiquement d'une façon ou d'une autre.

Quand on ouvre une page dans l'éditeur, le champ dossier_maj est prérempli.

À la sauvegarde de la page, il est sauvegardé.

Si on fait une 2e modif, on débloque l'historique de révision, où la sauvegarde du champ est visible.

Cf. vidéo

Mis à jour par ggallais il y a 11 mois

Si on crée un post via WP CLI, apparemment dossier_maj n'est pas rempli.

[gp.inserm.staging.ho_e1tc2ko25vr@desjoyeaux httpdocs]$ wp post create --post_type=post --post_title='re-526'
Success: Created post 135803.

Même après avoir donné un contenu au post et l'avoir publié, toujours pas de dossier_maj:

[gp.inserm.staging.ho_e1tc2ko25vr@desjoyeaux httpdocs]$ wp post update 135803 --post_content='kikou'
Success: Updated post 135803.
[gp.inserm.staging.ho_e1tc2ko25vr@desjoyeaux httpdocs]$ wp post update 135803 --post_status=private
Success: Updated post 135803.

Si je tente un wp post edit, pour éditer le contenu en CLI via un éditeur (vi), toujours aucun dossier_maj.

dans le détail j'ai fait wp post edit 135803 et j'ai modifié le texte, puis sauvegardé dans vi (:w!) avant de quitter (:q!)

Et quand je regarde la table post_meta y'a aucune méta pour un article créé en CLI.

SELECT * FROM `wp_...._postmeta` WHERE `post_id`=135803 AND `meta_key`='dossier_maj';

Parce qu'en fait à ce stade, l'article n'a AUCUNE meta

SELECT * FROM `wp_...._postmeta` WHERE `post_id`=135803

Donc y'a un bien un code qui déclenche l'ajout du champ dossier_maj, mais c'est lié à la façon d'accéder au contenu (via le backend).

C'est pas lié à la création ou la publication du contenu en tant que tel.

Mis à jour par ggallais il y a 11 mois

Réponse de Medhy :

Dans le thème, le fichier inc > Services > Acf.php
Il y a le bout de code qui gère le remplissage de l'ACF "dossier_maj", en fait au lieu d'être remplis sur une action save_post comme ce à quoi je m'attendais, le champ est rempli dans la page à la création du post.
Du coup normal que ça fonctionne pas quand on créer un post via wp cli car sans interface, le champ ne peut pas être rempli.

Prochaine étape :

Ajouter une action qui a au moment du save_post vérifie que dossier_maj n'est pas vide, et correspond au format AAAAMMJJ.

Si c'est pas le cas, refuser la publication et afficher un message d'erreur :

Le champ "Dernière mise à jour" doit être rempli avec une date valide.

Mis à jour par ggallais il y a 11 mois

Vu avec Medhy, on met une action sur le save_post de sorte que si on sauvegarde et que la date est vide, ça mette la date de publication du post.
Ça marchera même pour des posts édités hors Gutenberg.

On sait qu'il n'y a que 3 posts published qui posent problèmes actuellement et qui ont une valeur NULL (les autres sont OK, vérifiés).
Donc si le phénomène persiste après le fix de Medhy, faudra chercher ailleurs que coté utilisateurices.

Si on regarde plus large, il y a 2 autres posts concernés, qui sont en eux privés :

135841 Rencontre scientifique grand public : Sport et Art... post 2024-11-28 17:30:25 private 23 NULL
135889 Deux partenariats internationaux « Joint Lab » pou... post 2024-12-03 17:54:36 private 23 NULL
134966 "Activité physique et pathologies chroniques, les ... post 2024-10-16 16:56:05 publish 23 NULL
135216 Sport et Santé : rencontre scientifique grand publ... post 2024-10-31 16:46:17 publish 23 NULL
135250 Plaquettes sanguines : une production… sous pressi... post 2024-10-28 10:03:44 publish 22 NULL

Ils sont tous écrits par Patricia (DR Aura) ou la DR Est.

Mis à jour par ggallais il y a 11 mois

Medhy ajoute un fix qui gère ces cas là :

les cas que je gère du coup :
cas où dossier_maj est vide
cas où dossier_maj a une date qui n'est pas au bon format (YYYYMMDD)
cas où dossier_maj contient une date antérieur à la date de publication
cas où pour une raison ou une autre, il n'y a pas de date de publication disponible (ne devrait jamais arriver à priori mais sait-on jamais) => j'ai mis la date du jour

Pour moi :

  • si on vide la date en backend, ça corrige
  • si on met une date antérieure à la publication, ça corrige
  • si on met une date mal formée (en esquivant le date picker), ça corrige

En vrai, si on passe par la CLI, les on peut faire nimp. Mais quel que soit le borde qu'on met via CLI, il se corrige quand on rentre dans le post via le backend.

Mis à jour par ggallais il y a 11 mois

  • % réalisé changé de 10 à 100

OK en prod.

Note que ça règle pas forcément les soucis, vu qu'on ignore leur origine.

Mais c'est un filet de sécurité.

C'est pas forcément le meilleur filet tissé parfaitement avec une vérification logique de toutes les possibilités.

Mais pour ce qu'on fait, ça sera suffisant.

Mis à jour par ggallais il y a 11 mois

  • Statut changé de New à Closed
Actions

Formats disponibles : Atom PDF