Tri des articles par rubrique

Quand on veut afficher les articles dans un ordre différent selon les rubriques, par exemple des actualités par date anti-chronologique, un glossaire par ordre alphabétique, et d’autres rubriques par numéro d’article, il faut définir tous ces cas particuliers dans les squelettes.

Ce plugin permet de simplifier tout cela et de définir dans l’espace privé le tri des articles, rubrique par rubrique.

Dans l’espace privé

La page de configuration du plugin permet de choisir un mode de tri général, qui s’applique par défaut à toutes les rubriques :

Pour modifier le mode de tri sur une rubrique en particulier, on le choisit simplement en cliquant sur « Changer » :

Les articles sont alors affichés dans cet ordre dans l’espace privé.

Dans les squelettes

Pour reproduire le tri des articles dans l’espace public, il suffit d’utiliser le critère {tri_rubrique} dans les boucles d’articles, à la place de tout autre critère de tri :

<BOUCLE_articles(ARTICLES){id_rubrique}{tri_rubrique}>

Un même squelette affichera donc, selon la rubrique en cours, les articles dans l’ordre choisi dans l’espace privé.

Trier par rang

Si le plugin Rang est installé et activé sur les articles, il est pris en compte et le tri par rang est proposé.

NB : ce plugin surcharge un squelette de l’espace privé : /prive/objets/liste/articles.html

Discussion

10 discussions

  • 7

    Bonjour,
    suite à une mise à jour des plugins metasplus, saisies et tri_par_rubrique,
    j’ai un énorme bug qui m’a planté mon serveur, par une explosion du fichier error_log...
    avec une infinité (180Go) de :
    PHP message : PHP Warning : array_pop() expects parameter 1 to be array, int given in /home/...../public_html/plugins/auto/tri_par_rubrique/v
    1.4.9/tri_par_rubrique_fonctions.php on line 85

    spip 3.2.16, php7.4.33, tri_par_rubrique1.4.9.
    Je ne sais plus la version précédente mais ça marchait...
    Une idée ?
    MErci,
    Sylvain

    • Je suis revenu à la version 1.4.7 et je n’ai plus le problème.
      Sur irc, cy_altern n’a pas réussi à reproduire le bug.

    • Salut,
      tu parles du error_log au niveau système, pas SPIP ? Tu n’avais pas de rotation des logs ?

      Sinon sur ce warning c’est bizarre, ça ressemblerait au problème qu’avait une autre personne, effectivement cette fonction ne reçoit plus un int ($id_rubrique) mais un tableau ($Pile), mais si le cache n’est pas vidé ça peut provoquer des erreurs.

      Pour essayer d’identifier précisément le problème, est ce que tu pourrais stp essayer ceci : faire tourner le site avec la 1.4.7, pour avoir du cache généré, installer la dernière version (1.4.9) puis vider le cache aussitôt installée, et vérifier si tu as toujours ces logs ou pas ?

      Sinon, si tu peux m’indiquer les squelettes que tu utilises, ou me les fournir je peux tester en local.

    • Merci de te pencher dessus !
      Ce sont bien les logs d’apache, pas de spip.
      Il y a en effet un souci de logrotate, mais ça ne faisait pas 24h ; il faut que je regarde cela de plus près.
      Il y avait bien un gros cache (200Mo).
      Je voudrais faire une version de test, mais demain est un jour un peu spécial et ça ne me sera pas possible... j’essaierai bientôt.
      Je t’envoie un lien en mp pour les squelettes (ils utilisent z-core et spip-r-dist).
      Merci !

    • Pareil pour moi, les logs Apache explosent avec la 1.4.9

    • Je n’avais pas eu de retour de Sylvain, mais je pense que ça doit venir du fait que le cache n’est pas à jour.
      Si tu vides le cache depuis l’espace privé, est ce que tu as toujours ces warnings ?

    • Je suis repassé en 1.4.7 à la lecture des commentaires.
      Je vais tester de remettre la 1.4.9 en vidant le cache pour voir si le comportement est différent.

    • bonjour,
      par erreur (oubli), j’ai mis à jour le plugin en 1.4.9 dans le cadre d’une migration, et... re-bug.
      Evidemment, il faudrait que je fasse évaluer spip (v2.4.9), mais ce n’est pas possible.
      Attention donc à cette version pour spip 2.4.
      En revenant à la 1.4.7 ça fonctionne (bien, d’ailleurs !).

    Répondre à ce message

  • Hello

    Petit problème de chaîne de langue avec la version 1.5.0
    Si on a choisi par défaut le tri « par numéro dans le titre (10. ) », quand on veut changer le tri dans une rubrique, on voit ceci
    par défaut (tri_par_rubrique:tri_articles_num titre)
    Il manque l’underscore entre num et titre

    Répondre à ce message

  • 13
    Olivier D.

    Bonjour
    Je suis en SPIP 4.0.8 et la mise à jour du plugins Tri par rubrique en version 1.4.8 plante le tri des articles. Est-il possible de retélécharger quelque part la version 1.4.7 ? (il remonte que les anciens articles, pas les nouveaux).
    Merci.

    • Bonjour,
      il est possible de télécharger les versions précédentes ici :
      https://git.spip.net/spip-contrib-extensions/tri_par_rubrique/tags

      Par contre, c’est le deuxième commentaire qui parle d’un problème avec cette version 1.4.8, et j’aimerais comprendre et résoudre le problème s’il est confirmé.
      Est ce que tu as des messages dans les logs ?
      Pourrais tu faire un zip de tmp/log et me le faire parvenir ?
      Ça m’aiderait beaucoup, merci.

    • Olivier Devise

      Bonjour
      Merci pour ce retour rapide.

      Concernant les logs, peux tu m’indiquer où aller les chercher pour que je te les transmette ?

      Je viens de vérifier le fonctionnement, du tri (j’ai coché par date et en sens inverse) mais j’ai également retesté en décochant sens inverse (à chaque fois, il me met bien nouvelle configuration enregistrée). J’avais désactivé le cache pour être sûr de voir les effet. Le tri général ou par rubrique ne me remonte que les articles les plus anciens.

      Quand j’ai fait la mise à jour, j’ai eu une erreur de squelette lié au plugin. Par FTP, j’ai effacé le plugin et je l’ai ré-installé à la main -> plus d’erreur mais un mauvais sens de tri quelque soit le sens coché.

      • Config PHP : 7.3.32
      • J’utilise HTML5up_Editorial pour l’habillage, donc je suis resté dans la branche 4.0 de spip (4.0.8 précisément).
      • Le site en question est le suivant : www.idees-beaumont.org.
        Cordialement
    • Olivier Devise

      Je viens de ré-installer la version 1.4.7, plus d’erreur de tri !
      Il doit y avoir une manière différente de gérer les dates entre les deux versions qui est non compatible avec ma configuration.

    • Avez vous bien vidé le cache ?
      Cf l’autre message sur ce forum de Michel Suquet, sur le même sujet.

      Et est ce que le plugin HTML5up_Editorial utilise bien {tri_rubrique} dans ses squelettes ?

    • Michel Suquet

      Bonjour,

      suite à la mise à jour en 1.4.8, j’ai sans doute le même problème mais dans la partie publique uniquement : j’ai configuré le tri par date de publication en sens inverse, ce qui est bien réalisé dans la partie privée mais pas dans la partie publique.

      J’ai vidé le cache sans que cela change la situation.

      Cordialement,

    • Michel Suquet

      Que doit-on chercher dans tmp/log ?

      Ou ailleurs ?

    • Olivier Devise

      Pour répondre :
      -  Cache : oui, comme indiqué précédemment, j’ai vidé le cache puis je l’ai même désactivé. Avec la version 1.4.8, le tri s’effectue toujours du plus ancien au plus récent !
      -  HTML5up_Editorial : oui, il utilise Tri_Rubrique dans les squelettes. Si Tri_Rubrique n’est pas installé, j’ai une erreur lié à son absence qui est remonté par le plugins HTML5up_Editorial.
      -  et pour finir, la ré-installation de la version 1.4.7 supprime tous pb et le tri du plus récent au plus ancien refonctionne.

    • Michel Suquet

      nous aussi sommes revenu à la version 1.4.7 en attendant de trouver quel est le bug : le tri refonctionne.

    • Je viens de retester avec la version 1.4.8

      -  Avec les squelettes dist, en remplaçant {!par date} par {tri_rubrique} sur la liste d’articles du squelette rubrique.html,
      -  Avec mon squelette zboot, qui utilise {tri_rubrique},
      -  Sur SPIP 3.2.16 et 4.1.5

      et tout fonctionne bien comme prévu.

    • Michel Suquet

      comment expliquer qu’avec 1.4.7 cela fonctionne sur nos sites mais pas avec 1.4.8 (sur la partie publique) ? Quels sont les changements ? À part le changelog, je n’ai pas vu.

    • Je suis en train de tester avec HTML5UP Editorial et là je reproduis le problème.
      Je regarde.

    • Je pense avoir identifié le problème : erreur de logique de ma part, ça ne fonctionnait plus s’il n’y avait pas une boucle RUBRIQUES englobante.

      Je viens de publier un correctif, la version 1.4.9 devrait apparaitre sous peu dans SVP, sinon elle est disponible par git ou bien ici :
      https://git.spip.net/spip-contrib-extensions/tri_par_rubrique/tags

      Merci de me confirmer que ça corrige bien le souci.

    • Michel Suquet

      je viens de mettre à jour en 1.4.9 sur un site de test et cela fonctionne.

      Merci pour la correction ! Super :-)

      Je vais voir sur 2 autres sites à mettre à jour.

    Répondre à ce message

  • 2
    Michel Suquet

    Bonjour,

    sur le site de l’apmep, nous avons mis à jour le plugin Tri des articles par rubrique de 1.4.7 à 1.4.8 et il est devenu injoignable (erreur 503).

    Temporairement, en attendant de comprendre le problème, nous sommes revenu à la version 1.4.4 du plugin.

    Voyez-vous quel changement entre les versions 4.1.7 et 4.1.8 a pu causer le problème ? Est-ce un problème de compatibilité avec un autre plugin ?

    Élément lors de l’indisponibilité du site :

    Nov 29 08:12:03 ns3082433 ool web20[4086]: PHP Warning:  array_pop() expects parameter 1 to be array, int given in /var/www/clients/client3/web20/web/plugins/auto/tri_par_rubrique/v1.4.8/tri_par_
    rubrique_fonctions.php on line 88

    Notre site est en spip 3.2.16.

    Cordialement,

    Michel Suquet

    • Je viens de retester la version 4.1.8 sur un SPIP 3.2.16, et ça fonctionne bien.
      J’avais bien testé les dernières modifs car j’ai encore des sites en SPIP 3 qui utilise le plugin.

      Ce warning n’explique pas une erreur 503 du serveur.
      Par contre, il pourrait être dû à des fichiers en cache (avez vous bien vidé le cache ?), ou bien à une surcharge de la fonction critere_tri_rubrique_dist() ailleurs dans le site.
      Cette fonction appelle calculer_tri_rubrique() qui a changé de signature, elle ne reçoit plus l’id_rubrique mais la Pile du contexte.

    • Michel Suquet

      Bonjour,

      on a vidé les caches et mis à jour vers la version 1.4.8 (depuis la 1.4.4) et cette fois, pas de problème.

      Cordialement,

      Michel Suquet

    Répondre à ce message

  • 1

    Bonjour

    Peut-on utiliser le tri_par_rubrique dans la page sommaire ?
    si oui, comment l’activer

    A+

    • je complète :

      Comment activer le tri par date de modification ?
      Est-ce la même chose que par mise_a_jour ?

    Répondre à ce message

  • 21

    Bonjour,
    Cela ne semble pas fonctionner chez moi...
    Je suis sous SPIP 3.2.8, j’ai vidé le cache et rafraîchi mon écran !

    • Le plugin n’agit que sur l’espace public.

      C’est vrai que ce serait cool qu’il agisse aussi sur l’espace privé.

    • Bonjour et merci pour la piste, mais toujours rien :
      www.patcatnats.fr/spip.php?rubrique74

    • Le plugin n’agit que sur l’espace public.

      Si si, il agit bien dans le privé aussi, quand on modifie le tri sur une rubrique en particulier, la page se recharge avec le nouveau tri.
      Je viens de retester sur SPIP 3,2,9 avec tous les plugins à jour.

      Une piste : peut être un autre plugin qui surcharge /prive/objets/liste/articles.html ?
      Peux tu ajouter un var_mode=inclure sur la page de la rubrique (dans le privé) pour voir quel fichier est appelé ?

    • Ah oui, en effet, c’est mon plugin escal qui surcharge le fichier /prive/objets/articles.html

      Je vais repartir de celui de ton plugin.

    • Bonjour,
      N’ayant jamais ce genre de manip je me suis intéressé à l’article https://www.spip.net/fr_article4453.html#var_mode-inclure et cela donne çà (voir fichier sur mon site : http://www.patcatnats.fr/IMG/pdf/_patcatnat_s_accueil.pdf)
      Merci
      Patrice

    • Nickel, ma surcharge (affichage des mots-clés associés) fonctionne que le plugin « tri des articles par rubriques » soit activé ou non.

      Par contre le choix « par numéro dans le titre » na classe pas comme dans le public.
      Public : 10 puis 20 puis 100
      Privé : 10 puis 100 puis 20

    • Patrice il faudrait que tu fasses un var_mode=inclure sur une page rubrique, par sur la page d’accueil.

      Mais à priori, il y a des chances que le plugin ’Interface traduction d’objets" surcharge le fichier du plugin « tri des articles par rubriques »

    • Bon j’ai parlé trop vite ...

      Dans le privé j’ai 2 warnings :
      Filtre defaut_tri_par non défini
      Filtre defaut_tri_defined non défini
      alors que le plugin est activé.

    • Il faut copier le fichier des fonctions avec le fichiers articles.html, ces filtres sont définis dedans : /tri_par_rubrique/prive/objets/liste/articles_fonctions.php ou bien /prive/objets/liste/articles_fonctions.php, c’est le même.

    • Bonjour et merci,
      Je ne sais pas si j’ai compris !
      J’ai copier le fichier
      /prive/objets/liste/articles_fonctions.php
      dans
      plugins/auto/tri_par_rubrique-cbd5f-v1.4.4/prive/objets/liste/articles_fonctions.php (j’ai renommé l’ancien (articles_fonctions.php_Old)
      J’ai vidé le cache
      Cela ne fonctionne pas !
      Patrice

    • Hello Patrice

      Nicod s’adressait à moi, je pense, pas à toi.
      Dans ton cas ce qui est étonnant c’est que le dossier s’appelle tri_par_rubrique-cbd5f-v1.4.4 et non pas simplement tri_par_rubrique
      Ce que je tenterais à ta place, c’est de supprimer ce dossier dans ton /plugins/auto puis de réinstaller le plugin via « ajouter des plugins »

    • Bonjour,
      J’ai essayé, mais cela ne fonctionne toujours pas...
      Maintenant la structure est Tri_par_rubrique/v1.4.4/
      Tant pis !
      Merci quand même
      Patrice

    • Bizarre. Essaie de cliquer sur le lien « Titre » en haut de la liste des articles.
      Puis ensuite change le choix de tri.

    • Merci pour la réponse.
      En cliquant sur titre cela me l’a fait en partie privée la 1re fois, puis après les autres modes de tri ne fonctionnent pas.
      çà ne fonctionne pas en partie publique : www.patcatnats.fr/spip.php?rubrique74
      Merci quand même, c’est sympa d’avoir répondu.
      Patrice

    • Hello nicod

      J’ai copié ton fichier /prive/objets/liste/articles.html et ton fichier /prive/objets/liste/articles_fonctions.html dans mon plugin Escal.

      Dans articles.html, j’ai modifié le début ainsi

      [(#PLUGIN{TRI_PAR_RUBRIQUE}|oui)
      #SET{tri_rubrique_champ, #ID_RUBRIQUE|tri_rubrique_champ}
      [(#SET{defaut_tri,#ARRAY{
      	date,#ENV{date_sens,-1},
      	num titre,1,
      	id_article,1,
      	points,-1
      }|defaut_tri_defined})]
      [(#ENV{id_rubrique}|oui)
      	#SET{senstri,#ID_RUBRIQUE|tri_rubrique_sens|?{-1,1}}
      	[(#SET{defaut_tri,#ARRAY{
      		#GET{tri_rubrique_champ},#GET{senstri}
      	}})]
      	[(#GET{tri_rubrique_champ}|setenv{par})]
      	#SET{activer_rang, #VAL{articles}|in_array{#RANG_LISTE_OBJETS|sinon{#ARRAY}}|et{#AUTORISER{publierdans,rubrique,#ENV{id_rubrique}}}|et{#GET{tri_rubrique_champ}|=={rang}} }
      ]
      ]
      [(#PLUGIN{TRI_PAR_RUBRIQUE}|non)
      [(#SET{defaut_tri,#ARRAY{
      	date,#ENV{date_sens,-1},
      	num titre,1,
      	id_article,1,
      	points,-1
      }|defaut_tri_defined})
      ]

      et j’ai modifié ce que je voulais (affichage des mots-clés liés)

      J’ai ensuite rajouté les fonctions tri_rubrique_champ et tri_rubrique_sens de ton fichier tri_par_rubrique_fonctions.php (lignes 100 à 147)
      dans mon fichier articles_fonctions.html car sinon, j’avais des soucis d’affichage,

      Ma question : est-ce que je risque d’avoir des problèmes si le plugin tri_par_rubrique n’est pas installé ? A priori je n’en ai pas rencontré mais difficile de tout prévoir.

    • Arf, quand j’active le plugin, je retrouve les problèmes d’affichage !

    • Tu testes les deux cas donc ça me semble bon, et puis si tu testes avec et sans le plugin tu seras fixé.
      Ceci dit, s’il y a un <utilise nom="tri_par_rubrique"> dans ton paquet.xml, ça devrait être le /prive/objets/liste/articles.html de tri_par_rubrique qui est appelé non ?
      Tu peux tester avec var_mode=inclure

    • Bon, oublie !
      J’ai viré les fonctions tri_rubrique_champ et tri_rubrique_sens et tout me semble ok

    • Enfin presque ... après avoir vidé le cache, j’ai 2 warnings si le plugin est désactivé :
      Filtre tri_rubrique_champ non défini
      Filtre tri_rubrique_sens non défini

      Et bizarrement si je rafraîchis la page, ils disparaissent mais ils réapparaissent dès que je vide le cache.

      Que faire pour éviter ça ?

    • Ah je n’avais pas vu ta réponse 3 messages plus haut.

      Oui, je mets dans mon paquet.html, pas de souci mais je voudrais afficher les mots-clés associés à chaque article donc bien obligé de surcharger ton fichier /prive/objets/liste/articles.html
      Et donc comment éviter ces 2 warnings si ton plugin n’est pas activé ?

    • Hello

      Bon j’ai essayé de copier les fonctions de tri_par_rubrique_fonctions.php dans escal_fonctions.php
      Cela fait bien disparaître les 2 warnings si le plugin n’est pas activé mais si j’active le plugin, j’obtiens une page blanche.

      Et si je ne copie pas ces fonctions, j’ai ces 2 warnings lorsque le plugin n’est pas activé. Je pensais que le test

      [(#PLUGIN{TRI_PAR_RUBRIQUE}|oui) ...

      rendrait l’appel à ces 2 fonctions invisible mais ce n’est pas le cas.

    Répondre à ce message

  • Toutes mes excuses.
    Voila c’est fait : http://www.patcatnats.fr/IMG/pdf/_patcatnat_s_personnages.pdf
    Auparavant j’ai désactivé le plugin « Interface traduction d’objets »
    Merci pour votre patience
    Patrice

    Répondre à ce message

  • 12

    Bonjour,

    j’aurais aimer intégré ça au squelette escal

    Le souci est que le critère tri_rubrique est spécifique au plugin « Tri-des-articles-par-rubrique » ; Si je le mets dans Escal est que le plugin n’est pas installé, ça génère une erreur.

    y aurais t’il une astuce pour faire une condition du genre, si plugin installé on applique ça sinon on applique la règle actuel d’escal

    J’ai bien essayé ça mais je n’y suis pas parvenu ; Difficile de jouer sur les critères de boucle.

    la boucle en question :
    <BOUCLE_articles_rubs(ARTICLES){id_rubrique}{par num titre}{par date}{inverse}{pagination #GET{nbrpag}}>

    • Alors je reviens la dessus, quelquefois que quelqu’un aurais une idée.

      En fait, l’idée serait de remplacer

      {par num titre}{par date}{inverse}

      par

        {tri_rubrique}

      si le plugin « Tri des articles par rubrique » est activé

    • Voilà une piste à tester :

      #SET{par, date}
      #SET{sens, inverse}
      <BOUCLE_rubrique(RUBRIQUES){id_rubrique}>
         #SET{par, #TRIRUB_ARTICLES}
         #SET{sens, #TRIRUB_ARTICLES_INVERSE}
      </BOUCLE_rubrique>
      
      <ul class="liste-items">
      <BOUCLE_articles(ARTICLES){id_rubrique?}{tri #GET{par}, #GET{sens}}>
         <li class="item"><a href="#URL_ARTICLE">#TITRE</a></li>
      </BOUCLE_articles>
      </ul>
    • Hello
      Désolé mais je ne vois pas en quoi ton code répond au problème posé le but étant d’utiliser le critère {tri_rubrique} en lieu et place de
      {par num titre}{par date}{inverse} si et seulement si le plugin est activé.

    • Je t’ai donné une piste qui permet d’éviter d’utiliser le critère {tri_rubrique}, pour que ça ne plante pas quand le plugin n’est pas installé.
      Je ne t’ai pas donné le code tout cuit à copier/coller, mais bon...
      Il suffit de tester si le plugin tri_par_rubrique est actif dans la première boucle.

    • Mais

      • ta première boucle sera toujours valable donc à quoi servent les premiers #SET ?
      • d’où tu sors ces balises #TRIRUB_ARTICLES et #TRIRUB_ARTICLES_INVERSE ?
      • comment le choix du tri fait dans le plugin sera-t-il pris en compte puisqu’on a jamais le critère {tri_rubrique}  ?

      Bref, il y a un truc qui m’échappe (même plusieurs sans doute) !

      Ou alors, c’est que les 2 balises #TRIRUB_ARTICLES et #TRIRUB_ARTICLES_INVERSE sont définies dans le plugin, c’est ça ?

    • Je disais :

      Il suffit de tester si le plugin tri_par_rubrique est actif dans la première boucle.

      <BOUCLE_rubrique(RUBRIQUES){id_rubrique}{si #PLUGIN{tri_par_rubrique}}>
    • Oui, ça je sais faire. Je n’avais juste pas capté que les balises étaient définies dans le plugin.
      Reste que #TRIRUB_ARTICLES_INVERSE renvoie 0 ou 1 et non pas « inverse » ou rien.

    • Bon ça ne fonctionne pas.

      J’ai donc

      #SET{par, date}
      #SET{sens, 1}
      <BOUCLE_rubrique(RUBRIQUES){id_rubrique}{si #PLUGIN{tri_par_rubrique}|oui}>
         #SET{par, #TRIRUB_ARTICLES}
         #SET{sens, #TRIRUB_ARTICLES_INVERSE}
      </BOUCLE_rubrique>

      #GET{par} me renvoie bien « titre » si j’ai coché « par titre » dans le plugin pour le rubrique
      Mais si la boucle

      <BOUCLE_articles_rubs(ARTICLES){id_rubrique?}{tri titre}{pagination #GET{nbrpag}}> 

      me classe bien les articles par titre

      <BOUCLE_articles_rubs(ARTICLES){id_rubrique?}{tri #GET{par}}{pagination #GET{nbrpag}}> 

      me les classe comme si je n’avais pas le critère {tri #GET{par}}

    • Je confirme donc : le critère {par ...} ou {tri ...} n’accepte pas la balise #GET et sans doute pas d’autre balise non plus.
      Ne me reste plus qu’à dupliquer toute ma boucle et son contenu et d’utiliser le critère {si ...}.
      Pas élégant mais ça fonctionne !

    • J’ai testé le code ci dessus, et chez moi ça marche très bien avec {tri #GET{par}}, même si pour être complet il faudrait plutôt utiliser {tri #GET{par}, #GET{sens}}

      Une précision : #TRIRUB_ARTICLES_INVERSE vaut 0 pour un tri normal, et 1 pour un tri inverse, donc pour l’utiliser dans {tri ...} il faut transformer la valeur en 1 ou -1 :

      #SET{sens, #TRIRUB_ARTICLES_INVERSE|?{-1,1}}
    • Oui je n’avais pas mis le #GET{sens} pour simplifier.
      Bon, je me suis replongé dans ce problème et j’ai trouvé ce qui bloquait : l’espace après la virgule dans les #SET

    • Et j’oubliais le principal : merci beaucoup nicod_ !

    Répondre à ce message

  • 2

    Bravo pour ce plugin qui résout le problème pour plusieurs rubriques.

    Quel fichier dois-je surcharger pour faire apparaître sur la page de config d’autres critères de tri, comme date_redac. Si en plus je pouvais passer age_redac<X dans le calcul, ça serait top :)

    Sur cette même page de config, que faire pour avoir 2 critères de tri : par titre_mot, titre avec pour ces mots clés le groupe id_groupe=Y.

    D’avance merci

    • Pour ajouter un autre critère de tri, il suffit de surcharger la fonction filtre_tri_par_rubrique_criteres_dist() qui est dans tri_par_rubrique_fonctions.php, et qui renvoie juste un tableau des critères (champ Mysql / libellé).

      On peut la surcharger en la copiant et en retirant _dist de son nom, en la plaçant dans son propre fichier _fonctions.php

      Par contre, pour {age_redac<X}, ça c’est un critère de sélection, pas de tri, donc à ajouter dans les boucles, en plus de {tri_rubrique}.

    • Merci
      Je vais tester après les vacances
      Bonne année

    Répondre à ce message

  • 1

    Bonjour,

    Merci pour cette contribution. Y-a-t’il une incompatibilité avec SPIP 3.1 ou ce plugin n’a juste pas été testé sur d’autres versions que 3.2 (à première vue cela fonctionne normalement avec 3.1.18).

    • Bonjour,
      il n’y avait pas de volonté de bloquer pour SPIP 3.1, ni d’incompatibilité à priori.
      Le plugin a été testé et fonctionne en 3.1, la nouvelle version 1.2.3 le prend donc en compte.
      La mise à jour devrait arriver sous peu.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom