Evolution #2173

Date de création / publication

Ajouté par Julien - il y a plus de 6 ans. Mis à jour il y a environ un mois.

Statut:NouveauDébut:15/07/2011
Priorité:NormalEchéance:
Assigné à:-% réalisé:

0%

Catégorie:base de données
Version cible:3.2
Resolution:

Description

Sur la table articles, le champ 'date' est utilisé pour fixer la date de création puis de publication chaque fois que l'article passe en statut 'publie'. Le fait qu'il n'y ait qu'un seul champ dans la base pour gérer ces 2 aspects est dommage.
Exemple : dans le cadre d'un site collaboratif, si un auteur souhaite faire quelques retouches sur son article. Un administrateur peut lui repasser en 'redac'. Mais lorsqu'il le re-publiera, la date de publi sera de nouveau fixée à la date du jour. Et son article se retrouvera à la une alors que cela n'est pas forcément bienvenue sur certains types de site.

L'idée est que si on avait un champ pour la date de création et un champ pour la date de publi, il deviendrait possible de mettre en place dans la configuration une option du genre :
- à chaque publication, mettre à jour la date de publication (Fonctionnement actuel)
- à chaque publication, ne mettre à jour la date de publication que s'il elle n'existe pas (impossible aujourd'hui : il y a toujours une date)

de plus, conserver la date de création pourrait sans doute avoir d'autres usages.

Historique

#1 Mis à jour par cedric - il y a plus de 6 ans

  • Version cible changé de 3.0 à 3.1

#2 Mis à jour par Stanislas _ il y a presque 6 ans

On peut ajouter qu'une date de création distincte de la date de publication permettrait également de pouvoir fixer la date de publication avant d'effectuer l'action de publication. Devoir publier un article avant de pouvoir modifier la date pour que la publication s'effectue dans le futur est contre-intuitif.

#3 Mis à jour par Valéry - il y a plus de 5 ans

Je confirme l'intérêt de cette demande. La date de publication est aussi souvent utilisée pour gérer l'ordre d'affichage et certains webmestres la modifient pour repasser un article en page d'accueil. Du coup on perd toute information sur la date de création de l'article. Date de rédaction antérieure pourrait être utilisée mais son mode de saisie manuel fait qu'il ne l'est pas (et dans l'absolu il correspond aussi à une autre info).

#4 Mis à jour par Julien - il y a plus de 5 ans

ahhh, changer la date de publi pour repasser en page d'accueil... Je crois que c'est qqch d'assez fréquent ! J'ai vu des webmestres jouer avec ça aussi ! C'est parfois justifié cependant. Et si un article en ligne subit un gros lifting, on peut avoir envie de le remettre à la une.

Je me demande s'il faudrait pas profiter de ce changement potentiel, pour mettre en place également une date de 1ère publication.
La date de publication actuelle devenant du coup la date de "dernière publication". Et c'est bien ce dont on dispose aujourd'hui, ça, ça ne bougerait pas.
Cela permettrait de conserver à coup sur l'information de 1ere mise en ligne, qu'on n'a pas aujourd'hui.

Date de création et de 1ere publication seraient 2 dates automatiquement renseignées et non modifiables.

et +1 @Stanislas.

#5 Mis à jour par Valéry - il y a plus de 5 ans

+1 @Stanislas aussi naturellement : la manipe traumatise les utilisateurs soumis à des circuits de validation stricts ou a des dates d'embargo.

"Date de création et de 1ere publication" : la distinction des deux est subtile, n'est-ce pas un besoin beaucoup plus marginal ?

#6 Mis à jour par Julien - il y a plus de 5 ans

En effet... Si on dispose d'une date de création distincte de la date de dernière publication, trier les articles publiés par date de création peut sans doute revenir sensiblement au même et convenir. En tout cas, pour mes cas personnels, ça me suffirait je pense :-)

Encore que, en cas de tri par date de création, on risque de ne jamais voir passer "A la une" un article dont l'auteur aura pris une semaine ou 2 pour la rédaction... (car sa date de création serait plus ancienne que la plus ancienne actuellement à la une). Et le courroux des webmestres risquerait de pleuvoir ! La nuance va se trouver la je pense. non ?

#7 Mis à jour par cedric - il y a plus de 4 ans

  • Version cible changé de 3.1 à 3.2

Je repousse, mais je crois que tout ça pourrait etre dans un plugin dans un premier temps, pour tester le concept

#8 Mis à jour par tcharlss (*´_ゝ`) il y a 5 mois

Je reporte ici le ticket #3966 qui fait doublon : l'idée pourrait être étendue à tout type de contenu.


Il n'y a pas longtemps j'ai eu besoin de faire des statistiques éditoriales : on voulait connaître l'évolution du nombre d'articles publiés chaque année.
Mais les données ne sont pas fiables : les utilisateurs avaient pour habitude de faire des « remises en avant » en changeant la date de publication de vieux articles pour les refaire apparaître en page d'accueil. Donc un article écrit en 2014 mais remis en avant en 2017 se retrouve compté comme ayant été publié en 2017.

Et c'est valable pour tout les objets éditoriaux en fait : on ne conserve pas leur date de création / 1ère publication.
Certains objets ont une date de publication, mais elle peut être changée. Et d'autres objets n'ont tout simplement pas de date (hormis maj).

Donc je me demandais s'il ne serait pas pertinent d'avoir cette information de façon générique pour tous les objets éditoriaux, un champ date_creation par exemple qui serait rempli soit à la création, soit à la 1ère publication, et qui ne bougerait pas ensuite.

Ci-dessous, un tableau récapitulatif de ce qu'on a actuellement pour les principaux objets.

Objet Champ de date Date pérènne ?
Articles date Non : peut être modifiée manuellement
Brèves date_heure Non : peut être modifiée manuellement
Rubriques date Oui
Auteurs X X
Mot-clé X X
Groupe de mots-clés X X
Document date Oui
Forum date_heure oui
Pétition X X

#9 Mis à jour par nico d_ il y a 4 mois

J'avais pensé traiter ça sur une table pour un dév en cours avec deux champs en DEFAULT CURRENT_TIMESTAMP :

`date_creation` DATETIME DEFAULT CURRENT_TIMESTAMP,
`maj` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

(c) chez moi ça marche, du coup ça me paraissait une solution propre et généralisable, mais le serveur de prod est en Mysql 5.1 et ça ne marche qu'à partir de Mysql 5.6.5 :
https://stackoverflow.com/questions/4897002/mysql-current-timestamp-on-create-and-on-update
Du coup, pas utilisable en natif pour SPIP...

J'ai fait autrement et rapidement (directement dans le formulaire_traiter), mais j'aurais pu faire plus propre et passer par le pipeline pre_insertion en renseignant automatiquement date_creation dans $flux['data'].

Mais je me dis que ça pourrait faire l'objet d'un plugin, qui ajouterait donc des champs date_creation à toutes les tables déjà existantes qui n'en ont pas (auteurs, mots etc + objets persos), et qui utiliserait ce pipeline pour renseigner les date de création automatiquement si le champ existe dans la description de la table $flux['args']['table'] de l'objet inséré.

Ça ressemblerait aux behaviors des ORM, comme Propel / Timestampable :
http://propelorm.org/Propel/documentation/07-behaviors.html
http://propelorm.org/Propel/behaviors/timestampable

A tester...

#10 Mis à jour par b b il y a 4 mois

Bonne idée que de tester ça par le biais d'un plugin dans un premier temps, puis de l'intégrer dans le core par la suite, si c'est jugé nécessaire/utile. C'est ce qu'on a tendance à faire depuis un moment :) gogogo !

#11 Mis à jour par nico d_ il y a 4 mois

Ouais, je goerai dès que j'aurai cinq minutes :D

#12 Mis à jour par b b il y a 4 mois

no hurry mignon :)

#13 Mis à jour par tcharlss (*´_ゝ`) il y a 4 mois

Cool, super idée nicod_
Pour ma gouverne, comment tu comptes faire pour ajouter ce champ quand on installe des nouveaux plugins ?

Il reste la question de la date de 1ère publication, un article pouvant rester en gestation très longtemps avant d'être publié. Pour gérer ce cas, on pourrait considérer que la date de création d'un objet ayant un statut de publication correspond à la date de la 1ère publication (quand il y a $flux['args']['table']['statut']['publie']).

Concrètement quelque chose comme ça : dans pre_insertion, ne remplir date_ceation que si l'objet ne possède pas de statut de publication, et dans objet_instituer remplir date_creation si ce champ est vide et si l'objet est publié.

#14 Mis à jour par nico d_ il y a 4 mois

Pour ma gouverne, comment tu comptes faire pour ajouter ce champ quand on installe des nouveaux plugins ?

C'est une très bonne question :)
Je ne vois pas de pipelines adhoc pour l'instant, ça serait surement un truc "bourrin" : lancer un test d'upgrade dans prefixe_options.php (dans le privé uniquement).

Il reste la question de la date de 1ère publication,

Ça je sais pas, comme ça a déjà été dit ça parait marginal comme utilisation, en tout cas pas lié au besoin d'une date de création, quel que soit le statut ou pas à la création.
Et ce que tu décris me parait compliqué, ça fait un comportement dérogatoire...
A gérer dans un autre plugin si besoin, je pense, avec une date_premiere_publication ?
Mais concrètement, tu en aurais réellement besoin ?

#15 Mis à jour par nico d_ il y a 4 mois

ça serait surement un truc "bourrin" : lancer un test d'upgrade dans prefixe_options.php (dans le privé uniquement)

Compositions fait ça en appelant sa fonction compositions_check_upgrade() depuis le formulaire de configuration, moins bourrin ^^
Mais bon, ça ferait juste une boucle sur lister_tables_objets_sql(), et un sql_alter() si le champ n'existe pas. Pas bien méchant non plus.

#16 Mis à jour par tcharlss (*´_ゝ`) il y a 4 mois

Ça je sais pas, comme ça a déjà été dit ça parait marginal comme utilisation, en tout cas pas lié au besoin d'une date de création, quel que soit le statut ou pas à la création.
Et ce que tu décris me parait compliqué, ça fait un comportement dérogatoire...
A gérer dans un autre plugin si besoin, je pense, avec une date_premiere_publication ?
Mais concrètement, tu en aurais réellement besoin ?

C'est vrai que c'est dérogatoire, donc pas idéal. Je cherchais une solution pour éviter d'ajouter un nouveau champ juste pour ça (date_publication_initiale ou je ne sais quoi).
Moi je n'en ai l'utilité que pour faire des statistiques éditoriales dans un plugin (combien d'articles publiés par an etc.). Mais ça pourrait effectivement être géré dans ce plugin puisque c'est un besoin marginal.
Passons !

#17 Mis à jour par cam.lafit - il y a 4 mois

Yop

Vu les échanges date_publication et date_creation sont 2 concepts
différents donc 2 plugins/fonctionnalités différentes

Autre approche possible avoir une notion de type de date et avoir
publication, creation, ... comme type. Dans ce cas cela pourrait être
une table de jointure sur tous objets ce qui évite la structure de
tables présente ou à venir.

#18 Mis à jour par nico d_ il y a 4 mois

Non, date_publication c'est le "date" actuel (même si c'est un mot mysql réservé, c'est une norme / habitude), on y touche pas.
Et on a déjà la date de mise à jour ("maj" par habitude) en DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP.
Ça marche très bien, on ajoute juste date_creation.

Et non, les jointures c'est pas la joie dans les squelettes, on sait jamais trop comment ça marche.
Les champs de date de création (et de mise à jour) doivent être directement dans les tables des enregistrements.
En plus, on peut vouloir savoir aussi quand un spip_documents_liens (au hasard) a été créé.
C'est comme ça que fonctionnent les behaviors des ORM, c'est le plus simple et le plus logique.

Ne passons pas à côté des choses simples ^^

#19 Mis à jour par Julien - il y a environ un mois

Ci-dessous, ce que j'ai utilisé sur des objets éditoriaux maison et pour lesquelles j'ai les colonnes suivantes :
  • date_crea (création)
  • date_fpubli (1ere publication)

Pipeline "pre_insertion" :

// Fixer la date de création sur certains objets.
$objets_date_crea = ['spip_butternuts', 'spip_potimarrons', 'spip_citrouilles'];
if (in_array($flux['args']['table'], $objets_date_crea)) {
    $flux['data']['date_crea'] = date('Y-m-d H-i-s');
}

Pipeline "post_edition" :

// Changement de statut
if ($flux['args']['action'] == 'instituer') {

    // Fixer la date de premiere publication sur certains objets.
    $objets_date_fpubli = ['spip_butternuts', 'spip_potimarrons', 'spip_citrouilles'];
    if (in_array($flux['args']['table'], $objets_date_fpubli)) {

        // Si l'objet passe en statut publié.
        if ($flux['data']['statut'] == 'publie' and $flux['args']['statut_ancien'] != 'publie') {

            // La date de première publication est-elle déjà fixée ?
            $table = $flux['args']['table'];
            $primary = id_table_objet($table);
            $id_objet = intval($flux['args']['id_objet']);

            $notFixed = sql_countsel($table, "$primary = $id_objet and date_fpubli like '0000-00-00%'");
            // Si non, on la fixe.
            if ($notFixed) {
                $flux['data']['date_fpubli'] = $flux['data']['date'];

                $data = array('date_fpubli' => $flux['data']['date_fpubli']);
                sql_updateq($table, $data, "$primary=$id_objet");
            }
        }
    }
}

#20 Mis à jour par nico d_ il y a environ un mois

Salut,

oui, c'est l'idée.
En fait il faudrait généraliser ça dans un plugin, qui crée automatiquement les champs date_creation et date_publication sur toutes les tables principales, et avec effectivement un traitement comme celui là dans les pipelines.
L'idée est là, le code est pas énorme, y'a plus qu'à :)

Formats disponibles : Atom PDF

Ajouter une image à partir du presse-papier (Taille maximale: 1,25 Mo)