#DATE dans boucle RUBRIQUES calculer_rubriques_publiees #2570

Closed
opened 11 years ago by JLuc · 7 comments
JLuc commented 11 years ago

calculer_rubriques_publiees ne fait pas bien son travail.

  • calculer_rubriques_publiees a une action erronée car les rubriques sont modifiées successivement si elles sont un article publié, une brève publiée, un site publié, un document publié, ou une rubrique fille publiée. C'est fait dans l'ordre, et une rubrique peut donc être publiée plusieurs fois de suite, c'est le dernier objet dans cette liste qui "publie" la rubrique et lui impose sa date de publication, même si la date de publication déjà enregistrée est plus récente. La date de publication d'une rubrique est donc totalement erronée.

  • calculer_rubriques_publiees n'est pas efficace puisque toutes les rubriques sont testées pour tous ces objets (articles, breves, sites, ...) même si la rubrique a déjà été trouvée comme publiée. Il y a plein de boulot fait pour rien.

Il faudrait si possible affiner les requêtes pour qu'elles ne concernent :

  • que les rubriques pas encore trouvées publiées
  • ou les rubriques dont la date de publication trouvée est antérieure à la date de l'objet considéré

de manière à ce que

  • les rubriques déjà trouvées comme publiées ne soient plus testées
  • la date de publication d'une rubrique soit celle de son objet contenu publié le plus récent

Dans SPIP2 c'est tout à la suite dans la fonction calculer_rubriques dans inc/rubriques.php
Dans SPIP3 c'est toujours appelé dasn inc/rubriques.php et les valeurs de statut_tmp sont successivement écrasées par les fontions prefixe_calculer_rubriques de chacune des extensions déclarant un objet, via le pipeline calculer_rubriques.

calculer_rubriques_publiees ne fait pas bien son travail. - calculer_rubriques_publiees a une action erronée car les rubriques sont modifiées successivement si elles sont un article publié, une brève publiée, un site publié, un document publié, ou une rubrique fille publiée. C'est fait dans l'ordre, et une rubrique peut donc être publiée plusieurs fois de suite, c'est le dernier objet dans cette liste qui "publie" la rubrique et lui impose sa date de publication, même si la date de publication déjà enregistrée est plus récente. La date de publication d'une rubrique est donc totalement erronée. - calculer_rubriques_publiees n'est pas efficace puisque toutes les rubriques sont testées pour tous ces objets (articles, breves, sites, ...) même si la rubrique a déjà été trouvée comme publiée. Il y a plein de boulot fait pour rien. Il faudrait si possible affiner les requêtes pour qu'elles ne concernent : - que les rubriques pas encore trouvées publiées - ou les rubriques dont la date de publication trouvée est antérieure à la date de l'objet considéré de manière à ce que - les rubriques déjà trouvées comme publiées ne soient plus testées - la date de publication d'une rubrique soit celle de son objet contenu publié le plus récent Dans SPIP2 c'est tout à la suite dans la fonction calculer_rubriques dans inc/rubriques.php Dans SPIP3 c'est toujours appelé dasn inc/rubriques.php et les valeurs de statut_tmp sont successivement écrasées par les fontions prefixe_calculer_rubriques de chacune des extensions déclarant un objet, via le pipeline calculer_rubriques.
Owner

Version cible mise à 3.1

**Version cible mise à 3.1**
Poster

A priori la date de publication d'une rubrique est la plus ancienne date de publication d'un des objets contenus.

A priori la date de publication d'une rubrique est la plus ancienne date de publication d'un des objets contenus.
Owner

D'après http://www.spip.net/fr_article904.html#BOUCLE-RUBRIQUES-:

  • #DATE (depuis SPIP 1.4 ) affiche la date de la dernière publication effectuée dans la rubrique et/ou ses sous-rubriques (articles, brèves...).

Donc ton commentaire http://core.spip.org/issues/2570#note-2 est en contradiction avec la doc.

Par ailleurs je constate ce jour que le comportement en SPIP 3 est aussi en contradiction: la date se met à jour lors de la publication d'un article, elle inscrite en base dans spip_rubriques mais elle n'est pas recalculée si on dépublie, déplace, etc.

D'après http://www.spip.net/fr_article904.html#BOUCLE-RUBRIQUES-: - #DATE (depuis SPIP 1.4 ) affiche la date de la dernière publication effectuée dans la rubrique et/ou ses sous-rubriques (articles, brèves...). Donc ton commentaire http://core.spip.org/issues/2570#note-2 est en contradiction avec la doc. Par ailleurs je constate ce jour que le comportement en SPIP 3 est aussi en contradiction: la date se met à jour lors de la publication d'un article, elle inscrite en base dans spip_rubriques mais elle n'est pas recalculée si on dépublie, déplace, etc.
Owner

On en a causé sur irc mais j'ai pas ctrl-c les arguments.

En résumé, soit:

  • on change la documentation (et le comportement historique) de #DATE dans la boucle RUBRIQUES pour adopter la logique "la date de publication d'une rubrique est la plus ancienne date de publication d'un des objets contenus", à l'instar des autres objets (date de mise en ligne donc)
  • on garde le comportement documenté (==> on le rétablit en spip3), mais il faut une API (?) claire pour que les objets/plugins puissent s'y intégrer aisément.

Quoiqu'il en soit, en SPIP 307 le champs date de SPIP_RUBRIQUES est màj en cas de publication mais pas sur les modifs du type dépublication-déplacement-... d'objet.

On en a causé sur irc mais j'ai pas ctrl-c les arguments. En résumé, soit: - on change la documentation (et le comportement historique) de #DATE dans la boucle RUBRIQUES pour adopter la logique "la date de publication d'une rubrique est la plus ancienne date de publication d'un des objets contenus", à l'instar des autres objets (date de mise en ligne donc) - on garde le comportement documenté (==> on le rétablit en spip3), mais il faut une API (?) claire pour que les objets/plugins puissent s'y intégrer aisément. Quoiqu'il en soit, en SPIP 307 le champs date de SPIP_RUBRIQUES est màj en cas de publication mais pas sur les modifs du type dépublication-déplacement-... d'objet.
Owner

Assigné à cedric

**Assigné à cedric**
Owner

Le contenu descriptif de ce ticket qui accuse la fonction calculer_rubriques_publiees est pure calomnie :
la fonction fait parfaitement son travail, que ce soit dans le core, ou dans les appels par pipeline.
Notamment, on balaye en effet un par un les objets editoriaux en cherchant ceux publies dont la date est plus recente que celle de la rubrique, pour mettre à jour cette date de rubrique conformément à la doc, soit la date du dernier objet publié dans la rubrique.
Puis la fonction boucle sur la table des rubriques pour faire remonter la date de publication plus récente d'une sous-rubrique vers ses rubrique mère.
Cf r21719
http://zone.spip.org/trac/spip-zone/changeset/85637
http://zone.spip.org/trac/spip-zone/changeset/85636

Donc maintenant la question qui est posée : le ticket vient-il d'une analyse erronée de la fonction auquel cas il est invalide, ou vient-il d'un dysfonctionnement constaté, auquel cas il reste valide et c'est l'analyse qu'il faut revoir. Mais en tout état de cause, dans ce cas, il serait bien de commencer par dire "1/ je constate tel bug 2/ j'ai enquêté, il me semble que cela vient de là". Là on ne sait pas à quoi s'en tenir.

Le contenu descriptif de ce ticket qui accuse la fonction `calculer_rubriques_publiees` est pure calomnie : la fonction fait parfaitement son travail, que ce soit dans le core, ou dans les appels par pipeline. Notamment, on balaye en effet un par un les objets editoriaux en cherchant ceux publies dont la date est plus recente que celle de la rubrique, pour mettre à jour cette date de rubrique conformément à la doc, soit la date du dernier objet publié dans la rubrique. Puis la fonction boucle sur la table des rubriques pour faire remonter la date de publication plus récente d'une sous-rubrique vers ses rubrique mère. Cf r21719 http://zone.spip.org/trac/spip-zone/changeset/85637 http://zone.spip.org/trac/spip-zone/changeset/85636 Donc maintenant la question qui est posée : le ticket vient-il d'une analyse erronée de la fonction auquel cas il est invalide, ou vient-il d'un dysfonctionnement *constaté*, auquel cas il reste valide et c'est l'analyse qu'il faut revoir. Mais en tout état de cause, dans ce cas, il serait bien de commencer par dire "1/ je constate tel bug 2/ j'ai enquêté, il me semble que cela vient de là". Là on ne sait pas à quoi s'en tenir.
Owner

Par ailleurs la doc http://www.spip.net/fr_article904.html#BOUCLE-RUBRIQUES est explicite:

affiche la date de la dernière publication effectuée dans la rubrique et/ou ses sous-rubriques (articles, brèves...).

Ce qui signifie bien la date de la dernière publication qui a eu lieu, ce qui ne veut pas dire qu'on revient en arrière en cas de dépublication (auquel cas on dirait "la date du plus récent objet publié dans la rubrique") C'est subtil mais correspond à une certaine logique.

Pour finir sur le sujet, la fonction "calculer_rubriques_publiees" n'est appelée que dans 2 scenari : après une restauration de base, ou lors de la réparation de la base, pour tout remettre d'equerre.
Statut changé à Fermé

Par ailleurs la doc http://www.spip.net/fr_article904.html#BOUCLE-RUBRIQUES est explicite: > affiche la date de la dernière publication effectuée dans la rubrique et/ou ses sous-rubriques (articles, brèves...). Ce qui signifie bien la date de la dernière publication qui a eu lieu, ce qui ne veut pas dire qu'on revient en arrière en cas de dépublication (auquel cas on dirait "la date du plus récent objet publié dans la rubrique") C'est subtil mais correspond à une certaine logique. Pour finir sur le sujet, la fonction "calculer_rubriques_publiees" n'est appelée que dans 2 scenari : après une restauration de base, ou lors de la réparation de la base, pour tout remettre d'equerre. **Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.