Date de création / publication #2173

Closed
opened 12 years ago by julienlfy · 29 comments

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.

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.
Owner

Version cible mise à 3.1

**Version cible mise à 3.1**

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.

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.

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).

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).
Poster

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.

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.

+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 ?

+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 ?
Poster

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 ?

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 ?
Owner

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

Je repousse, mais je crois que tout ça pourrait etre dans un plugin dans un premier temps, pour tester le concept **Version cible mise à 3.2**
Owner

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 |

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 |
Owner

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

``date_creationDATETIME 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...

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...
b_b commented 5 years ago
Owner

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 !

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 !
Owner

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

Ouais, je goerai dès que j'aurai cinq minutes :D
b_b commented 5 years ago
Owner

no hurry mignon :)

no hurry mignon :)
Owner

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é.

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é.
Owner

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 ?

> 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 ?
Owner

ç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.

> ç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.
Owner

Ç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 !

> Ç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 !
Owner

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.

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.
Owner

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 ^^

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 ^^
Poster

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");
            }
        }
    }
}
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"* : <pre> // 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'); } </pre> Pipeline *"post_edition"* : <pre> // 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"); } } } } </pre>
Owner

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'à :)

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'à :)
Owner

Voilà un plugin qui crée un champ 'date_creation' sur tous les objets, et qui insère la date depuis le pipeline post_insertion().
A tester.

https://zone.spip.org/trac/spip-zone/changeset/108458

Voilà un plugin qui crée un champ 'date_creation' sur tous les objets, et qui insère la date depuis le pipeline post_insertion(). A tester. https://zone.spip.org/trac/spip-zone/changeset/108458
b_b commented 5 years ago
Owner

Statut changé à En cours

**Statut changé à En cours**
Owner

J'ai ajouté la doc du plugin : https://contrib.spip.net/ecrire/?exec=article&id_article=4967

Pas encore publiée, mais je propose de fermer ce ticket dès qu'elle le sera, et de continuer la discussion sur le forum du plugin sur contrib.
Statut changé à Résolu

J'ai ajouté la doc du plugin : https://contrib.spip.net/ecrire/?exec=article&id_article=4967 Pas encore publiée, mais je propose de fermer ce ticket dès qu'elle le sera, et de continuer la discussion sur le forum du plugin sur contrib. **Statut changé à Résolu**
b_b commented 5 years ago
Owner

Super, merci pour le plugin et la doc. On pourra passer le ticket à "Fermé" + fixed une fois la doc en ligne.

Super, merci pour le plugin et la doc. On pourra passer le ticket à "Fermé" + fixed une fois la doc en ligne.
Owner

Voilou, c'est publié : https://contrib.spip.net/Date-de-creation

La discussion continue donc là bas si besoin.
Statut changé à Fermé

Voilou, c'est publié : https://contrib.spip.net/Date-de-creation La discussion continue donc là bas si besoin. **Statut changé à Fermé**
Collaborator

je reprend ce dossier. Suite discussion ici

spip-contrib-extensions/formidable#32

  • Rasta
  • Maricmat
  • Nico
  • Moi-même

sommes plutot partisant de mettre les fonctionnalités de date_creation dans le core

`nicod_ estce que tu serais prêt à faire le PR qu'il faut ?

je reprend ce dossier. Suite discussion ici https://git.spip.net/spip-contrib-extensions/formidable/issues/32 - Rasta - Maricmat - Nico - Moi-même sommes plutot partisant de mettre les fonctionnalités de date_creation dans le core `nicod_ estce que tu serais prêt à faire le PR qu'il faut ?
Owner

Ok `maieul, je m'en occupe dès que j'ai cinq minutes.

Ok `maieul, je m'en occupe dès que j'ai cinq minutes.
Owner

On se limiterait donc à une date_creation, pas de date de première publication ?

La date de création est affichée dans le formulaire dater (avec des constantes pour la masquer), et elle est créée dynamiquement dans les tables des objets qui n'en ont pas.
On est d'accord là dessus ?

Sujet connexe : j'ai souvent éprouvé ce manque aussi dans les tables de liaisons (spip_*_liens), il m'arrive souvent d'ajouter une date_creation et maj pour mes besoins, ne serait ce que de suivi historique.

Pensez vous que ce serait utile aussi ?

On se limiterait donc à une date_creation, pas de date de première publication ? La date de création est affichée dans le formulaire dater (avec des constantes pour la masquer), et elle est créée dynamiquement dans les tables des objets qui n'en ont pas. On est d'accord là dessus ? Sujet connexe : j'ai souvent éprouvé ce manque aussi dans les tables de liaisons (spip_*_liens), il m'arrive souvent d'ajouter une date_creation et maj pour mes besoins, ne serait ce que de suivi historique. Pensez vous que ce serait utile aussi ?

Pour les liens, ça peut être sympa aussi, au moins un "maj" (car dans l'immense majorité des cas pour les liens, ya quasi aucun champ donc "maj" est la création). Mais peut-être dans une autre PR.

Pour les liens, ça peut être sympa aussi, au moins un "maj" (car dans l'immense majorité des cas pour les liens, ya quasi aucun champ donc "maj" est la création). Mais peut-être dans une autre PR.
Sign in to join this conversation.
No Milestone
No project
No Assignees
10 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.