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é.
Discussions par date d’activité
10 discussions
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
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.
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é.
Cordialement
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 ?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,
Que doit-on chercher dans tmp/log ?
Ou ailleurs ?
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.
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.
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.
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
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 :
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.
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
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
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
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
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
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
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 :
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
#SET
?#TRIRUB_ARTICLES
et#TRIRUB_ARTICLES_INVERSE
?{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 :
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
#GET{par}
me renvoie bien « titre » si j’ai coché « par titre » dans le plugin pour le rubriqueMais si la boucle
me classe bien les articles par titre
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 :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
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 danstri_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.phpPar 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
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 :
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.
Suivre les commentaires : |