Ajouter un 2eme champ DATE pour les MAJ

Je tiens un blog dans lequel j'ai des articles qui subissent des Mises A Jour (MAJ), et ces "anciens" articles ne remontent pas en page d'accueil car leur date de création est trop ancienne pour s'afficher sur ma home avec les 8 derniers articles et du coup les MAJ de ces articles passent inaperçues.

L'idée serait d'avoir un 2eme champ date dans lequel je pourrais renseigner la date de mise à jour. Ma home prendrait, du coup, les 8 derniers articles à date de création et de MAJ ou je pourrais faire un bloc "MAJ" avec les 3 derniers articles mis à jour par exemple.. Ce serait intéressant qu'en pensez vous ?

merci par avance pour celui et celle qui va développer ce plugin.
«134

Réponses

  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonjour
    J'ai pris note de ta demande.
    A étudier...

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • merci Stéphane c'est très gentil. Penses tu que cela puisse se faire via un plugin ?
  • StéphaneStéphane Member, Former PluXml Project Manager
    ça me semble jouable si ce qui suit répond à ton besoin:
    - avoir un nouveau champ de saisie pour saisir la date de mise à jour de l'article.
    - si et seulement si cette date en renseignée, on change la date de création de l'article (la date stockée dans le nom du fichier xml) par la date de mise à jour.
    - on peut stocker l'ancienne date de création dans un nouveau tag xml dans le fichier xml de l'article pour garder la date initiale de création de l'article.


    - de cette façon, l'article remontera tout seul sur la home, puisque on a changé la date dans le nom du fichier (idem dans les flux rss)
    - coté performance on reste sur le fonctionnement de base de PluXml: on prend la date dans le nom du fichier. pas besoin d'aller parser le fichier xml pour récupérer la date de mise à jour.
    - afficher la date de création de l'article, oblige de parser le fichier xml, ce que l'on fait que lors de l'affichage complet de l'article (mode article). cette info (date de création) ne pourrait etre affichée qu'à ce moment là.


    Voilà, comment je vois la chose ;)

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • ça va remettre en cause pas mal de choses en fait, car ensuite les ALLarchive vont être classées avec les dates de MAJ (c'est dommage) ainsi que dans les catégories. Il faut que je regarde si je peux fonctionner comme ça.

    Le "nouveau tag xml" sera utilisable pour l'affichage uniquement ou aussi pour du classement ? Si je veux tous les articles créés un mois en particulier, je pourrai ?

    Et si on gardait la date de création comme tel mais que l'on créait le nouveau champ xml pour la date de MAJ et que cette date de MAJ était utilisée pour afficher les articles en questions dans une catégorie "MAJ". Mes articles auraient 2 catégories dont une (MAJ) juste pour l'affichage en homepage. Qu'en penses tu ?
  • StéphaneStéphane Member, Former PluXml Project Manager
    L'idéal bien sur est de ne pas toucher à la date de création contenu dans le nom du fichier.
    Le seul inconvénient en stockant la date de mise à jour dans le fichier xml de l'article, est qu'il va falloir lire tous les fichiers xml de tous les articles pour la récupérer et l'afficher en fonction de tes critères. Coté perfs c'est pas terrible. ça peut passer si tu n'as pas beaucoup d'articles, mais si tu as un blog conséquent ça pourra détériorer les temps de réponses.
    Après on peut imaginer une solution alternative c'est de stocker dans un unique fichier l'id des articles qui sont mis à jour avec la date de mise à jour et uniquement ceux là. L'idée est de faire une seule lecture de ce fichier pour savoir tout de suite si un article a été mis à jour. On regarde dans ce fichier (que l'on charge préalablement en mémoire) si l'id d'un article est présent. Si oui alors ça veut dire qu'il a été mis à jour et on a donc sa date de maj en correspondance. Si l'id de l'article n'est pas présent, c'est que c'est un article original.
    C'est surement la meilleure solution technique, qui reste aussi faisable sous forme de plugin je pense.

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • ta dernière idée semble intéressante en effet. Pourrait on classer par date du coup et n'afficher que les 3 derniers admettons ?
    Aussi, que se passera-t-il si je fais une 2eme MAJ sur un article (une MAJ de MAJ en somme) ?

    Mais cette solution me semble bien.
  • StéphaneStéphane Member, Former PluXml Project Manager
    Puisque la date de maj est stockée dans ce fameux fichier, tu peux faire un tri pour ressortir les 3 dernieres maj sans souci.
    Pour la maj de la maj, on écrase l'ancienne date. on garde toujours la derniere mise à jour.
    Je ne pense pas qu'il soit nécessaire d'avoir l'historique des mises à jour. Sauf si c'est besoin, dans quel cas faudra faire les devs en conséquences.

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • alors moi ça me va, pas besoin de stocker d'historique. Merci de te pencher sur ma demande (une fois encore !).

    Du coup je pourrai utiliser le titre, la date de création, la date de MAJ, et un champ perso en + pour l'affichage ? (j'ai un champ dans lequel je colle l'url de "l'image à la une" pour la home, les catégories... - voir www.sapinrisien.fr - )
  • Je me permets de me joindre à la conversation pour savoir si Stéphane va développer le plugin en question. Si ce n'est pas le cas, maintenant que le plus gros est fait, je veux bien m'y coller si ça vous dit.
  • intéressant ça d'avoir un fichier perso qui classe selon des paramètres ... :D
  • StéphaneStéphane Member, Former PluXml Project Manager
    Jerry Wham a écrit:
    Je me permets de me joindre à la conversation pour savoir si Stéphane va développer le plugin en question. Si ce n'est pas le cas, maintenant que le plus gros est fait, je veux bien m'y coller si ça vous dit.
    Ce n'est pas prévu. Vacances obligent :)

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Je vais donc m'y mettre de ce pas. Pour moi les vacances c'est pas encore :(
  • @Jerry Wham : merci beaucoup de regarder ça et de le développer si vite. J'adore cette communauté.
  • Jerry WhamJerry Wham Member
    août 2012 modifié
    Bon j'ai quasiment fini.

    Pour résumer, j'ai un fichier (que j'ai nommé 0000.maj.xml) dans le dossier articles (mais sa localisation est paramétrable), qui contient les articles et leur date de modification (une balise article ayant un numéro et une balise maj enfant d'article).


    Lorsque le fichier est enregistré, la date de modification et la date de mise à jour sont les mêmes. Si le fichier est modifié, seule la date de mise à jour change.


    C'est elle qui est prise en compte lors de l'affichage en mode "home", "article" ou "catégorie", c'est à dire que la date de création est remplacée par la date de mise à jour. Mais l'information de première publication n'est pas perdue et peut être affichée par l'intermédiaire d'un hook du plugin.


    [del]Dans les pages autres (allarchives, sitemap, feed), je n'ai pas modifié la date de publication. Est-ce nécessaire ? Qu'en pensez-vous ?[/del]


    SapinTremblant, peux-tu me dire si c'est ce que tu attendais ?
  • tout d'abord merci d'avoir réalisé ma demande si rapidement.

    en revanche je ne suis pas sur d'avoir tout saisi. Dans ton mode de fonctionnement, la home va afficher inévitablement tous les articles par rapport à cette nouvelle date. Il va donc mélanger les articles sans et avec MAJ. Je ne peux pas faire 2 blocs différenciés c'est ça ?

    tu dis : "Mais l'information de première publication n'est pas perdue et peut être affichée par l'intermédiaire d'un hook du plugin." ne peut-on pas faire l'inverse ? à savoir que la date de base soit la date de création et que la date de modification soit celle que l'on appelle via le plugin ?

    De cette manière je pourrais faire un second bloc dans lequel je ne présenterais que les articles mis à jour. Ou alors que les 2 solutions soient possibles et paramétrables afin de s'adapter à chacun.

    A toi de me dire.
  • Jerry WhamJerry Wham Member
    août 2012 modifié
    SapinTremblant a écrit:
    tout d'abord merci d'avoir réalisé ma demande si rapidement.

    en revanche je ne suis pas sur d'avoir tout saisi. Dans ton mode de fonctionnement, la home va afficher inévitablement tous les articles par rapport à cette nouvelle date. Il va donc mélanger les articles sans et avec MAJ. Je ne peux pas faire 2 blocs différenciés c'est ça ?
    Oui c'est bien ça.
    SapinTremblant a écrit:
    tu dis : "Mais l'information de première publication n'est pas perdue et peut être affichée par l'intermédiaire d'un hook du plugin." ne peut-on pas faire l'inverse ? à savoir que la date de base soit la date de création et que la date de modification soit celle que l'on appelle via le plugin ?

    De cette manière je pourrais faire un second bloc dans lequel je ne présenterais que les articles mis à jour.
    Si l'on fait ça, l'article mis à jour ne sera pas pris dans la boucle des posts et restera dans les choux.
    Il faudrait alors que je fasse une méthode du plugin pour faire une boucle sur les articles mis à jour. [del]Je vais voir si c'est possible[/del].


    EDIT : c'est possible. Par contre, les articles sont en double (dans la boucle de mise à jour et dans la boucle standard). Est-ce génant ?

    SapinTremblant a écrit:
    Ou alors que les 2 solutions soient possibles et paramétrables afin de s'adapter à chacun.

    A toi de me dire.
    A voir en fonction de ce qui est indiqué ci-dessus.
  • Voilà le plugin terminé, du moins dans sa première version.

    Un fichier d'aide est disponible ainsi qu'une page de configuration. Par défaut, la date de publication est remplacée dans la partie publique par la date de mise à jour. Mais ce comportement peut être modifié par la configuration.

    Stéphane, si tu passes par là, pourrais-tu jeter un oeil et me dire ce que tu penses du code et s'il y a des parties qui peuvent être améliorées.

    Merci pour vos retours.

    Enjoy :p
  • StéphaneStéphane Member, Former PluXml Project Manager
    Salut Jerry

    La gestion du hook plxAdminEditArticle me gène énormément car tu reprends le code de la fonction initiale editarticle de plxAdmin. S'il y a des évolutions dans PluXml (ex ajout d'un champ xml dans le fichier des articles) ton plugin va venir perturber le fonctionnement de PluXml. Pas bien...

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Jerry WhamJerry Wham Member
    août 2012 modifié
    Merci Stéphane pour ton retour.

    Pour tout te dire, ça me gène également. [del]Je préfèrerai utiliser le hook plxAdminEditArticle mais ça ne fonctionnait pas[/del] (EDIT : faites comme si j'avais rien dit...). Idéalement, il aurait fallu un hook après la génération du fichier xml d'un article.


    Comme je le disait, c'est une première version. Je vais essayer de l'améliorer.
  • Voici la correction.

    Stéphane, vois-tu autre chose qui pourrait-être modifié ?
  • Tout d'abord, merci à vous 2 pour cette réactivité. je vais tester ce plugin très vite histoire de mieux me rendre compte de ses possibilités.

    Je vous tiens au courant
  • août 2012 modifié
    Installé : parfaites les options, du coup les 2 options sont possibles, c'est super.

    En revanche j'ai une erreur lorsque je tente d'accéder à un article.
    Fatal error: Call to undefined method plxDate::date2Array() in /homepages/0/d148894308/htdocs/SAPINrisien/core/admin/article.php(165) : eval()'d code on line 4
    

    Mon pluxml est en version 5.1.5
  • Ah oui, il faut utiliser la 5.1.6 car les fonctions de date ont été modifiées.
  • ah merde, j'aurai du commencer par la. Bon eh bien il va falloir que j'update alors. mais le chantier va être un peu plus long du coup.
  • StéphaneStéphane Member, Former PluXml Project Manager
    Meme remarque pour le hook plxFeedDemarrageBegin
    Dans le hook AdminIndexPrepend, inutile de déclarer une instance de plxMotor. Tu peux utiliser plxAdmin car c'est une classe dérivée de plxMotor (idem AdminArticleParseData).
    Coté sécurité: attention tu permets de paramétrer l'emplacement du fichier 0000.maj.xml. c'est toujours dangereux car on peut le mettre dans un endroit mal choisit.
    Voilà. Sinon le code est propre, facile à lire et à comprendre car il suit bien la philosophie de PluXml. Well done ;)

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Jerry WhamJerry Wham Member
    août 2012 modifié
    Ok, c'est noté.

    Donc il faut mieux ne pas laisser le choix pour le fichier 0000.maj.xml. Je vais supprimer l'option.


    Pour les instances de plxMotor, je les ai appelées car j'avais des soucis pour récupérer les paramètres du plugin. [del]Je vais voir si je peux les enlever.[/del] C'est corrigé.


    Pour le hook plxFeedDemarrageBegin, si je ne mets pas le code là où il est situé, les modifications ne sont pas prises en compte, de même si j'utilise plxFeedDemarrageEnd. Je sèche un peu je dois dire. Un peu d'aide ne serait pas de refus pour le coup.


    Je publierai la mise à jour lorsque j'aurai résolu le problème du hook pour les flux rss.
  • Voilà la version corrigée.


    J'ai supprimé le contenu de la méthode plxFeedDemarrageBegin par une variable qui m'indique si je suis dans un flux rss. Si c'est le cas, l'article est parsé en conséquence par la méthode plxMotorParseArticle puisque les articles passent par plxMotor avant d'être affichés.


    J'ai supprimé l'option permettant de choisir l'emplacement du fichier 0000.maj.xml, et les appels aux instances de plxMotor qui n'avaient pas lieu d'être.


    Je crois qu'on est bon là, non ?

    Enjoy :p
  • août 2012 modifié
    Bon je viens de passer mon site en 5.1.6 pour utiliser le plugin. Il fonctionne mais je lui trouve un problème : la date de mise à jour s'ajoute automatiquement à chaque enregistrement d'un article. Ce que je n'avais pas précisé c'est que je souhaitais la renseigner à la main en fait pas à chaque ouverture ou enregistrement mais vraiment lorsque je fais une mise à jour importante sur un article. Afin de ne remonter en home que les MAJ majeure. Donc si je pouvais supprimer cet enregistrement auto à la date du jour mais me permettre de mettre ma date, ce serait parfait.

    La date de MAJ ne s'enregistre que si les champs sont renseignés. Ce qui fait que sur mes 30 articles, il n'y en a que 3 avec MAJ pour le moment. Pour moi cela devient pertinent de les pousser en home.

    En attendant c'est super bien fait. Merci encore.
  • et si tu changeais simplement la date de création et 'pi vouala ?
  • @danielsan : merci pour l'idée ! Mais c'est exactement ce que je veux éviter afin de garder l'historique des articles et pouvoir les ranger. Donc je souhaite 2 dates. La date de MAJ ne doit pas garder d'historique mais juste sa dernière date de MAJ.

    Voila tu sais tout.
Connectez-vous ou Inscrivez-vous pour répondre.