[Retrouvez vos statistiques de participation en LAN]

[Aurelienazerty]

Aurelienazerty a mis une breve ici

[djip]

C'est totalement inutile et donc génialement indispensable !

[Arken]

Depuis le temps que j'attendais ça, merci

[Aurelienazerty]

Information importante que j'avais oublié de préciser : le nombre de LAN est également visible sur la page de la liste des membres : memberlist.php ou des groupes (par exemple la team-azerty)

Pas de tris possible malheureusement, et pourtant, j'ai essayé en rajoutant un listener sur l'event core.core.memberlist_modify_memberrow_sql et rajouter

Code : Tout sélectionner

, (SELECT COUNT(*) FROM lan_inscription li WHERE li.user_id = u.user_id) AS nb_lan

sur le $event['sql_select']. Mais étrangement, ça ne remontait l'info que pour la vu groupe (alors que ça passait bien sur l'event) et pour le tri ça merdait complètement, car le order_by est utilisé par la suite, mais sans reprendre les ajouts dans le $event['sql_select'], donc forcément le champ était inconnu.

Le code est en commentaire pour le moment, on verra si c'est corrigé dans de futures versions de phpBB.

[Aurelienazerty]

Grace à Claude Sonnet 5, le tri est maintenant possible : memberlist.php?mode=&sk=lan&sd=d#memberlist

Pour ceux que ça intéresse, voici ce qui bloquait et comment c'est réglé :

• Le ORDER BY est construit avant que l'événement de l'extension ne se déclenche. Ce que j'avais bien identifié à l'époque : sort_key_sql n'est lu par le cœur qu'avant le déclenchement de core.memberlist_modify_sql_query_data, donc y ajouter une clé lan ne suffit pas. Il faut carrément réécrire $event['order_by'] soi-même dans le listener, en remplaçant la colonne de tri par défaut par la mienne.
• Le tri utilise une requête « allégée » qui ne contient pas mon sql_select. C'est le vrai piège que je n'avais pas vu : pour trier, phpBB fait d'abord une requête minimale du type SELECT u.user_id FROM ... ORDER BY ... LIMIT juste pour récupérer les ID dans le bon ordre, avant d'aller chercher les données complètes dans une deuxième requête. Cette première requête ne reprend pas les colonnes ajoutées via sql_select, donc trier sur l'alias nb_lan échouait (colonne inconnue). La solution : ne pas trier sur l'alias, mais répéter directement la sous-requête (SELECT COUNT(*) FROM lan_inscription li WHERE li.user_id = u.user_id) dans le ORDER BY. Une sous-requête corrélée fonctionne très bien dans un ORDER BY, même sans être présente dans le SELECT.
• Il n'existe aucun lien de tri généré automatiquement pour une colonne d'extension. Les liens sk=a, sk=d, etc. des colonnes natives (pseudo, date d'inscription, messages...) sont codés en dur dans memberlist.php. Il a donc fallu générer le lien de tri à la main dans le listener (via append_sid()) et l'injecter dans le template memberlist_body_memberlist_after.html.

Le tout reste dans l'extension, sans toucher au cœur de phpBB — donc ça survit aux mises à jour.

EDIT : le tri est encore perfectible.
EDIT 2 : C'est corrigé