23-07-2017, 09:39 PM
La pagination du plugin wordpress (catlist) fonctionne simplement en créant une liste de lien, vers chaque page. Sur Mantis aussi je crois. La liste est souvent tronquée après la page 3 voire 4 (personne ne va au-delà, la page 2 n'est parfois même pas nécessaire) car cela signifie surtout que tu n'as pas su servir à l'utilisateur ce qu'il cherchait (ie: dans un moteur de recherche ou un champ de recherche quelconque, l'utilisateur va plutôt affiner ses paramètres de recherche que browser page à page, sauf éventuellement s'il n'y a que 2 pages).
Du coup, si je devais la faire (vu que je n'ai pas eu à la coder: Mantis est out-of-the-box et le plugin catlist aussi), je la ferai simplement de la même façon: ma procédure SQL me renverrait mes lignes de données, plus un resultset donnant ou bien le nombre de page, ou bien l'existence d'une page 2 (ou d'une page 3), suivant si je décide de faire une pagination classique ou un simple indicateur "page suivante/précédente".
Côté PHP, j'aurai alors juste à renvoyer les ancres "a" correspondant à ces pages. D'autres solutions consistent juste à renvoyer le nombre total de lignes matchées par la requête (SQL_CALC_FOUND_ROWS) et le code PHP (ou JS) se charge de construire les liens correspondant à coup de modulo.
Dans certains cas (genre pour Iamanoc), j'ai purement viré la pagination (osef un peu de l'historique, et si on le voulait, alors je pars du principe qu'on veut en faire tout l'historique: je ferai alors une page "archive" qui donnera la totalité de tous les messages postés). Si je devais remettre la pagination, alors je la baserai sur les IDs (façon twitter, "messages suivants/précédents", qui seraient donc des liens générant une requête type "WHERE id < $_GET['idMax']" [Nota: le premier qui met littéralement ça dans son code mangera "La sécurité pour les nuls"... littéralement!]).
Du coup, si je devais la faire (vu que je n'ai pas eu à la coder: Mantis est out-of-the-box et le plugin catlist aussi), je la ferai simplement de la même façon: ma procédure SQL me renverrait mes lignes de données, plus un resultset donnant ou bien le nombre de page, ou bien l'existence d'une page 2 (ou d'une page 3), suivant si je décide de faire une pagination classique ou un simple indicateur "page suivante/précédente".
Côté PHP, j'aurai alors juste à renvoyer les ancres "a" correspondant à ces pages. D'autres solutions consistent juste à renvoyer le nombre total de lignes matchées par la requête (SQL_CALC_FOUND_ROWS) et le code PHP (ou JS) se charge de construire les liens correspondant à coup de modulo.
Dans certains cas (genre pour Iamanoc), j'ai purement viré la pagination (osef un peu de l'historique, et si on le voulait, alors je pars du principe qu'on veut en faire tout l'historique: je ferai alors une page "archive" qui donnera la totalité de tous les messages postés). Si je devais remettre la pagination, alors je la baserai sur les IDs (façon twitter, "messages suivants/précédents", qui seraient donc des liens générant une requête type "WHERE id < $_GET['idMax']" [Nota: le premier qui met littéralement ça dans son code mangera "La sécurité pour les nuls"... littéralement!]).