Ajouter un 2eme champ DATE pour les MAJ
SapinTremblant
Member
dans Entraide
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.
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.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'ai pris note de ta demande.
A étudier...
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
- 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 et développeur de PluXml (2010 à 2018)
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 ?
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 et développeur de PluXml (2010 à 2018)
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.
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 et développeur de PluXml (2010 à 2018)
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 - )
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
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 ?
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.
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 ?
A voir en fonction de ce qui est indiqué ci-dessus.
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
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 et développeur de PluXml (2010 à 2018)
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.
Stéphane, vois-tu autre chose qui pourrait-être modifié ?
Je vous tiens au courant
En revanche j'ai une erreur lorsque je tente d'accéder à un article.
Mon pluxml est en version 5.1.5
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 et développeur de PluXml (2010 à 2018)
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.
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
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.
Voila tu sais tout.