Changement du rangement des logos et #DATE_MODIF #4950

Open
opened 6 days ago by JLuc · 6 comments
JLuc commented 6 days ago

Cf https://discuter.spip.net/t/155347

Lors d'une migration à SPIP 4, il semble que le changement du dossier de rangement des logos provoque une actualisation de la #DATE_MODIF des objets concernés.
Comme dit rastapopoulos, il semble impossible de corriger le problème sur les sites ayant déjà migré (?) mais il est certainement possible d'empêcher qu'il se produise sur les sites qui n'ont pas encore fait leur migration.

Pour voir les dates modifs :
SELECT DATE_FORMAT(date_modif, "%Y %m %d") AS LADATE, count(*) as c FROM spip_articles group by LADATE ORDER BY c DESC

"Chez moi", ayant fait la mise à jour à ne sais quelle date exactement, il y a actuellement un millier environ de #DATE_MODIF qui ont la même valeur de jour, "2019-09-26".
Avec SELECT id_article, date_modif, titre FROM spip_articles where DATE_FORMAT(date_modif, "%Y %m %d") = "2019 09 26" ORDER BY spip_articles.date_modifDESC je vois que les horaires des date_modif sont répartis sur 1 minute 30, entre "17:55:54" et "17:57:20". Les autres dates (à peu près autant) se répartissent entre la création du site bien longtemps avant, et aujourd'hui. Les articles dont la date_modif a été actualisée sont en particulier les premiers créés (petit id_article).
Je fais l'hypothèse qu'il y a eu un timeout (max_execution_time = 180s) qui a empêché la mise à jour des #DATE_MODIF des autres articles. Je me souviens en effet qu'il y avait eu des symptomes inquiétants lors de la mise à jour, mais j'ai oublié lesquels car tout s'était bien passé à peu près tout seul au final. Mon site n'a d'ailleurs pas été perturbé, probablement car il n'a pas l'usage des #DATE_MODIF.

Cf https://discuter.spip.net/t/155347 Lors d'une migration à SPIP 4, il semble que le changement du dossier de rangement des logos provoque une actualisation de la #DATE_MODIF des objets concernés. Comme dit rastapopoulos, il semble impossible de corriger le problème sur les sites ayant déjà migré (?) mais il est certainement possible d'empêcher qu'il se produise sur les sites qui n'ont pas encore fait leur migration. Pour voir les dates modifs : `SELECT DATE_FORMAT(date_modif, "%Y %m %d") AS LADATE, count(*) as c FROM spip_articles group by LADATE ORDER BY c DESC` "Chez moi", ayant fait la mise à jour à ne sais quelle date exactement, il y a actuellement un millier environ de #DATE_MODIF qui ont la même valeur de jour, "2019-09-26". Avec `SELECT id_article, date_modif, titre FROM spip_articles where DATE_FORMAT(date_modif, "%Y %m %d") = "2019 09 26" ORDER BY `spip_articles`.`date_modif` DESC ` je vois que les horaires des `date_modif` sont répartis sur 1 minute 30, entre "17:55:54" et "17:57:20". Les autres dates (à peu près autant) se répartissent entre la création du site bien longtemps avant, et aujourd'hui. Les articles dont la date_modif a été actualisée sont en particulier les premiers créés (petit id_article). Je fais l'hypothèse qu'il y a eu un timeout (max_execution_time = 180s) qui a empêché la mise à jour des #DATE_MODIF des autres articles. Je me souviens en effet qu'il y avait eu des symptomes inquiétants lors de la mise à jour, mais j'ai oublié lesquels car tout s'était bien passé à peu près tout seul au final. Mon site n'a d'ailleurs pas été perturbé, probablement car il n'a pas l'usage des #DATE_MODIF.
b_b added the
bug
label 6 days ago
b_b added this to the 4.0 milestone 6 days ago
b_b commented 6 days ago
Owner

J'ai regardé vite fait, on n'a pas d'option pour indiquer à logo_modifier() de ne pas toucher à la date de maj de l'objet. Ensuite ça passe par ajouter_documents(), qui passe par ajouter_un_document(), etc. Donc ça demanderait de modifier un paquet de trucs si on prend cette direction.

Le plus simple serait de patcher logo_migrer_en_base() pour qu'il stocke la date_modif de l'objet avant modification et la recolle juste après la modification du logo. À noter que suivant l'objet, le champ ne porte pas le même nom, date_modif pour les articles, date pour les rubriques, etc.

J'ai regardé vite fait, on n'a pas d'option pour indiquer à `logo_modifier()` de ne pas toucher à la date de maj de l'objet. Ensuite ça passe par `ajouter_documents()`, qui passe par `ajouter_un_document()`, etc. Donc ça demanderait de modifier un paquet de trucs si on prend cette direction. Le plus simple serait de patcher `logo_migrer_en_base()` pour qu'il stocke la date_modif de l'objet avant modification et la recolle juste après la modification du logo. À noter que suivant l'objet, le champ ne porte pas le même nom, `date_modif` pour les articles, `date` pour les rubriques, etc.
Owner

Je pense que c'est la meilleure solution aussi, donc quoi ? en ajoutant un champ "date_avant_migration" sur toutes les tables objets ? à chaque fois copier la date dedans, faire la migration, remettre la date dans les bons champs d'origine

Et qu'en est-il du champ #MAJ aussi ? Là aussi faut le remettre avec la même ancienne date non ? Car justement plein d'objets n'ont PAS de "date de modification" vraiment dédiée, en fait c'est que les articles. Et donc pour à peu près tous les autres objets, c'est #MAJ qu'on utilise quand on veut classer par dernière modif ou afficher la dernière fois que ça a été modifié. Donc il faut absolument prendre en compte ça aussi il me semble.

C'est fou que ça n'ait pas été vu avant par les gens qui ont migré… Moi je n'ai encore strictement aucun site en SPIP 4 par migration d'ancien que je maintiens, donc j'ai encore jamais fait de vraie migration. Mais dans quasi TOUS mes sites, ça utilise des classement par date de modif à certains endroits + partout ça affiche toujours la "fraicheur" de chaque contenu en montrant s'il a été modifié ou pas depuis sa publication (et donc ça utilise aussi #MAJ sur certains autres objets qu'article).

Je pense que c'est la meilleure solution aussi, donc quoi ? en ajoutant un champ "date_avant_migration" sur toutes les tables objets ? à chaque fois copier la date dedans, faire la migration, remettre la date dans les bons champs d'origine Et qu'en est-il du champ #MAJ aussi ? Là aussi faut le remettre avec la même ancienne date non ? Car justement plein d'objets n'ont PAS de "date de modification" vraiment dédiée, en fait c'est que les articles. Et donc pour à peu près tous les autres objets, c'est #MAJ qu'on utilise quand on veut classer par dernière modif ou afficher la dernière fois que ça a été modifié. Donc il faut absolument prendre en compte ça aussi il me semble. C'est fou que ça n'ait pas été vu avant par les gens qui ont migré… Moi je n'ai encore strictement aucun site en SPIP 4 par migration d'ancien que je maintiens, donc j'ai encore jamais fait de vraie migration. Mais dans quasi TOUS mes sites, ça utilise des classement par date de modif à certains endroits + partout ça affiche toujours la "fraicheur" de chaque contenu en montrant s'il a été modifié ou pas depuis sa publication (et donc ça utilise aussi #MAJ sur certains autres objets qu'article).
Owner

Pour date_modif pas la peine d'ajouter un champ en base, il faut gérer dans le script de migration en lisant la valeur avant de migrer le logo de l'objet puis en la ré-écrivant après

Utiliser "maj" comme date de modif n'est pas une méthode fiable, car ce champ peut-être modifié à tout moment par mysql sur de simples opérations internes, donc je pense pas qu'on ait à gérer ça.

Pour `date_modif` pas la peine d'ajouter un champ en base, il faut gérer dans le script de migration en lisant la valeur avant de migrer le logo de l'objet puis en la ré-écrivant après Utiliser "maj" comme date de modif n'est pas une méthode fiable, car ce champ peut-être modifié à tout moment par mysql sur de simples opérations internes, donc je pense pas qu'on ait à gérer ça.
b_b commented 6 days ago
Owner

Pour date_modif pas la peine d'ajouter un champ en base, il faut gérer dans le script de migration en lisant la valeur avant de migrer le logo de l'objet puis en la ré-écrivant après

+1 donc

Utiliser "maj" comme date de modif n'est pas une méthode fiable, car ce champ peut-être modifié à tout moment par mysql sur de simples opérations internes, donc je pense pas qu'on ait à gérer ça.

Par contre il ne faudrait pas oublier la date des rubriques car elles peuvent aussi comporter un logo, mais bon pas certain que ça soit vital car la date d'une rubrique bouge souvent elle aussi.

> Pour `date_modif` pas la peine d'ajouter un champ en base, il faut gérer dans le script de migration en lisant la valeur avant de migrer le logo de l'objet puis en la ré-écrivant après > +1 donc > Utiliser "maj" comme date de modif n'est pas une méthode fiable, car ce champ peut-être modifié à tout moment par mysql sur de simples opérations internes, donc je pense pas qu'on ait à gérer ça. Par contre il ne faudrait pas oublier la date des rubriques car elles peuvent aussi comporter un logo, mais bon pas certain que ça soit vital car la date d'une rubrique bouge souvent elle aussi.

Est-ce qu'il y a une raison valable de passer par les API de gestion des documents de SPIP pour déplacer les logos dans cette phase de migration ?

Est-ce qu'il ne serait pas plus simple de déplacer et mettre les entrées qui vont bien en base dans une fonction dédiée ?

Je vois une objection à mes questions : que le schémat de la base change dans une future version de SPIP et qu'il faille penser à changer la fonction d'upgrade en même temps que l'API.

Est-ce qu'il y a une raison valable de passer par les API de gestion des documents de SPIP pour déplacer les logos dans cette phase de migration ? Est-ce qu'il ne serait pas plus simple de déplacer et mettre les entrées qui vont bien en base dans une fonction dédiée ? Je vois une objection à mes questions : que le schémat de la base change dans une future version de SPIP et qu'il faille penser à changer la fonction d'upgrade en même temps que l'API.
b_b commented 6 days ago
Owner

Proposition de patch à l'arrache, même pas testé, juste pour illustrer l'idée...

index dacf183b6c..a4bfe6bcd1 100644
--- a/ecrire/action/editer_logo.php
+++ b/ecrire/action/editer_logo.php
@@ -180,6 +180,9 @@ function logo_migrer_en_base($objet, $time_limit) {
 					$logo = $chercher_logo($id_objet, $_id_objet, $mode);
 					// if no logo in base
 					if (!$logo or count($logo) < 6) {
+						if ($objet == 'article') {
+							$date_modif = sql_getfetsel('date_modif', table_objet($objet), "id_article=$id_objet");
+						}
 						foreach ($formats_logos as $format) {
 							if (@file_exists($d = ($dir . ($nom = $nom_base . intval($id_objet) . '.' . $format)))) {
 								// logo_modifier commence par supprimer le logo existant, donc on le deplace pour pas le perdre
@@ -189,6 +192,9 @@ function logo_migrer_en_base($objet, $time_limit) {
 								break;
 							}
 						}
+						if ($date_modif) {
+							sql_updateq(table_objet($objet), "date_modif=$date_modif", "id_article=$id_objet");
+						}
 					}
 					$deja[$id_objet] = true;
 				}
Proposition de patch à l'arrache, même pas testé, juste pour illustrer l'idée... ```diff index dacf183b6c..a4bfe6bcd1 100644 --- a/ecrire/action/editer_logo.php +++ b/ecrire/action/editer_logo.php @@ -180,6 +180,9 @@ function logo_migrer_en_base($objet, $time_limit) { $logo = $chercher_logo($id_objet, $_id_objet, $mode); // if no logo in base if (!$logo or count($logo) < 6) { + if ($objet == 'article') { + $date_modif = sql_getfetsel('date_modif', table_objet($objet), "id_article=$id_objet"); + } foreach ($formats_logos as $format) { if (@file_exists($d = ($dir . ($nom = $nom_base . intval($id_objet) . '.' . $format)))) { // logo_modifier commence par supprimer le logo existant, donc on le deplace pour pas le perdre @@ -189,6 +192,9 @@ function logo_migrer_en_base($objet, $time_limit) { break; } } + if ($date_modif) { + sql_updateq(table_objet($objet), "date_modif=$date_modif", "id_article=$id_objet"); + } } $deja[$id_objet] = true; } ```
Sign in to join this conversation.
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.