affichage des articles selon date de mise à jour et de publication

cpalocpalo Member
novembre 2016 modifié dans Entraide
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

Réponses

  • sur un thème, j'affiche la date de modification si l'article a été mis à jour, sinon rien.
    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.
  • Bonsoir,

    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
  • cpalocpalo Member
    novembre 2016 modifié
    Bonjour,

    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 ?
  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonjour

    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)

  • jol5926jol5926 Member
    novembre 2016 modifié
    Hello,
    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
  • jol5926 a écrit:
    Hello,
    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 ??
    :(
  • cpalocpalo Member
    novembre 2016 modifié
    Bonjour,

    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:
    Publié  le <?php $plxShow->artDate('#num_day #month #num_year(4)'); ?> 
    
    par
    Publié ou mis à jour le <?php $plxShow->artDate('#num_day #month #num_year(4)'); ?>
    
    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:
    [== Indéfini ==]
    $date_creation = plxDate::formatDate($plxMotor->plxRecord_arts->f('date_creation'), '#num_year(4)#num_month#num_day'); 
    $date_update = plxDate::formatDate($plxMotor->plxRecord_arts->f('date_publication'), '#num_year(4)#num_month#num_day');
        if($date_update!=$date_creation) {
             echo '| créé le ';
    $plxShow->artCreationDate('#num_day #month #num_year(4)');
    									}
    
  • Stéphane a écrit:
    Bonjour

    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

    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 :-)
  • Fogg a écrit:
    Stéphane a écrit:
    Bonjour

    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

    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 ?
  • Selon moi la seule solution qui donnera des performances acceptables serait d'avoir une indexation des articles.
    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...
  • pas beaucoup le temps pour l'instant mais je vais me pencher sur la question d'un plugin.

    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...
  • @fogg : si tu peux aussi ajouter comme valeur de tri le "titre de l'article", ça permettrait de pouvoir les trier par ordre alphabétique. (c'est une fonctionnalité qui me manque dans PluXml)
  • PierrePierre Member
    novembre 2016 modifié
    Le problème remonte à un point que j'adresse depuis des mois, celui de permettre d'extraire les données sans toujours les afficher immédiatement.

    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.

    [== Indéfini ==]
    		<h3>
    			DERNIERS ARTICLES MIS A JOUR
    		</h3>
    		
    		<?php 
    		$limite=3;
    		while($plxShow->plxMotor->plxRecord_arts->loop()){
    			$matrice[$plxShow->plxMotor->plxRecord_arts->f('date_update')] = '<a href="index.php?article'.$plxShow->plxMotor->plxRecord_arts->f('numero').'">'.$plxShow->plxMotor->plxRecord_arts->f('title').'</a>'; 
    		}
    		krsort($matrice);
    		echo '<ul class="lastart-list unstyled-list">';
    		foreach ($matrice as $key => $chaine) {
    			if($limite > 0)	echo '<li>'. $chaine .'<li/>';	
    			$limite=$limite-1;
    		}
    		echo '</ul>';
    		?>
    
    

    (désolé, j'ai dû corriger une coquille)
  • Pour utiliser les feuilles de style, j'ai converti ma simple liste produite pour la faire correspondre à une liste affichée dans la sidebar. Ainsi, au cas où la fonction était insérée dans un thème qui a adapté les feuilles de style par défaut, tout pourra correspondre. La seule exception est le titre qui ne fait pas partie du dictionnaire, il faudra y faire un ajout si votre site est multilingue.
Connectez-vous ou Inscrivez-vous pour répondre.