affichage des articles selon date de mise à jour et de publication
Bonjour,
Par défaut Pluxml affiche les articles par date de publication.
On peut maintenant indiquer une date de mise à jour d'un article.
Je voudrai donc modifier l'affichage des articles par date de publication s'ils n'ont pas été mis à jour et sinon par date de mise à jour.
Une condition du tri de cette manière :
dateTri =
if dateMiseAJour n'existe pas, datePublication
ifelse dateMiseAJour
Cordialement
Par défaut Pluxml affiche les articles par date de publication.
On peut maintenant indiquer une date de mise à jour d'un article.
Je voudrai donc modifier l'affichage des articles par date de publication s'ils n'ont pas été mis à jour et sinon par date de mise à jour.
Une condition du tri de cette manière :
dateTri =
if dateMiseAJour n'existe pas, datePublication
ifelse dateMiseAJour
Cordialement
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
https://github.com/nIQnutn/PluXml-W3css/blob/master/article.php
il y a eu une discussion sur le forum avec plusieurs solutions si ça ne t'aide pas suffisament.
bon courage pour la retrouver.
J'ai cette discussion ( puisque j'y ai participé aussi ) et ce que tu proposes je le fais dans mes thèmes, et dans un de mes thèmes dans la sidebar j'ai aussi la liste des cinq derniers articles mis à jour.
Mais là ce que je cherche à faire, c'est modifier l'affichage par défaut en mode blog des articles : ceux-ci s'affichent par ordre de publication, et si l'un d'entre eux est mis à jour il apparaîtra toujours par rapport à sa date de publication et non pas par rapport à sa date de mise à jour.
Cordialement
http://forum.pluxml.org/viewtopic.php?pid=47654#p47654 billet 67
Une solution ne pourrait-elle pas consister à trier les articles affichés sur la homepage à partir de ce critère artUpdateDate ?
Ce genre de critère demande de modifier le coeur de PluXml avec un impact sur les performances, car la date de publication est stockée dans le nom du fichier (facile à lire), alors que la date de mise à jour est dans le contenu du fichier. Cela demanderait donc de lire le contenu de tous les fichiers pour récupérer l'info et appliquer les critères de tri, ce qui va être très consommateur de cpu car les opérations de lecture des fichiers c'est ce qui est le plus pénalisant
Consultant PluXml
Ancien responsable du projet (2010 à 2018)
Je m'intègre à votre discussion.
J'aurais aimé affiché sur la home page, la liste des 5 derniers articles mis à jour, sur le même principe que dans la sidebar "derniers articles".
J'ai essayé et cela ne fonctionne pas, il faut dire que je suis loin d'être compétent dans ce domaine.
Quelqu'un pourrait-il m'aider en me donnant le code à insérer sur la page ?
Merci de votre aide.
Jol
Hello,
Personne ne peut m'aider ??
J'ai trouvé une petite astuce, certes pas très "propre" ni "user-friendly" mais ça me dépanne.
Dans l'administration d'un article , je saisis la date de mise à jour dans l'input "date de création" et non pas dans celui prévu à cet effet "date de modication" ( qui se remplit d'ailleurs automatiquement chaque fois que l'on enregistre l'article) : ainsi les articles sont toujours triés selon ce critère , qui est devenu soit la date de première publication soit la date de modification( si on en saisit une..)
Je l'accorde pas très "correct".
Dans le thème , je vais modifier la ligne correspondante: par De même le thème m'affichait: Publié le .... | Modifié le... ( seulement s'il y avait une date de mise à jour différente)
Je voudrais maintenant : Publié ou mis à jour le .. | Crée le... ( seulement si la date de publication est différente d ela date de création)
du genre:
Oui c'est vrai mais pour autant, le besoin reste aussi tout à fait légitime...
Par exemple, dans une catégorie dont les articles sont en fait des événements, on peut utiliser la liste comme un calendrier qui reprend toutes les infos.
Souvent les utilisateurs sont demandeurs de ce genre de calendrier qui est en fait une liste (imprimer un événement à la fois n'est pas toujours pertinent).
On a alors besoin, évidemment, de trier par date. Le fait de trier par date de modification est alors un moyen facile de contourner le problème.
Car sinon on doit ajouter un champ (et champArt n'est plus maintenu) et après c'est très difficile voire impossible de trier sur ce nouveau champ.
Alors que la date de modification peut être changée manuellement. Modifier la date de création, cela peut se faire aussi mais je trouve qu'on perd alors une information significative, à savoir depuis quand un événement est créé. En effet on a parfois des événements qui reviennent chaque année, on conserve le même article parce que le contenu est similaire.
Il y a par ailleurs des solutions de tris sur des attributs xml et je trouve que ce serait sympa de l'implémenter.
Quitte à prévenir sur l'impact des performances... si vraiment c'est très lent...
(avouons que peu de nos sites ont des centaines et des centaines d'articles)
merci :-)
Hello,
je suis d'accord avec tes explications. C'est pour cela que je cherche un moyen d'afficher sur la home page les 5 derniers articles mis à jour dans le même principe que "les derniers articles" dans la sidebar.
Mais je ne sais pas comment faire ?
Autrement dit, un fichier supplémentaire qui contient la clé d'article et la valeur que l'on veut trier.
Du coup on peut lire uniquement ce fichier et retrouver les X valeurs qui sont les premières selon le tri en question.
Je pense que c'est un gros boulot qui mériterait d'être inclus dans le core Pluxml, si on veut faire ça soi-même ça va prendre un peu de temps et sans assurance que l'on respecte le mode de fonctionnement de Pluxml...
avec les hooks disponibles on doit pouvoir ajouter une écriture dans un fichier d'index au moment de la sauvegarde d'un article, et une lecture au moment de la récupération de la liste des articles...
Par exemple, dans la demande présente, il faut recopier le code des fonctions d'affichage pour "attraper" la totalité des articles (sans les afficher), effectuer le fameux tri, puis finalement afficher selon le format voulu. Le problème de performance mentionné plusieurs fois ici est toujours présent, bien que réduit par la légèreté de la matrice. J'ai ajouté une variable $limite pour ne pas allonger la liste dans les cas où beaucoup d'articles auraient été modifiés.
(désolé, j'ai dû corriger une coquille)