Comment ajouter une colonne personnalisée à la liste des articles ?

Le tableau des articles de WordPress affiche par défaut le titre, l'auteur, les catégories, les mots clés, les commentaires et la date. C'est suffisant pour un blog de trente articles et très insuffisant dès qu'un site en compte quinze cents. Ajouter une colonne personnalisée dans la liste des articles transforme cet écran en véritable outil de travail : on y affiche le nombre de mots, la présence d'une image à la une, la longueur de la méta description, la date de dernière modification réelle ou n'importe quelle donnée propre au projet. L'opération tient en une trentaine de lignes, ne demande aucune extension, et son intérêt vient surtout de ce qu'elle permet ensuite, à savoir trier et filtrer sur cette donnée pour repérer d'un coup d'œil les contenus qui demandent une intervention.

Déclarer et remplir la colonne

Le mécanisme repose sur deux points d'accroche complémentaires, l'un qui déclare les colonnes existantes, l'autre qui produit le contenu de chaque cellule. Cette symétrie est la même partout dans WordPress, et se retrouve pour les pages, les types de contenu personnalisés, les utilisateurs et les taxonomies, ce qui rend l'apprentissage rentable. Elle s'inscrit dans les usages courants d'administration de WordPress que nous documentons régulièrement.

Le filtre qui déclare les colonnes

Le premier point d'accroche reçoit un tableau associatif dont les clés sont les identifiants de colonnes et les valeurs les intitulés affichés. Y ajouter une entrée suffit à faire apparaître une colonne, placée en fin de tableau. L'identifiant doit être unique et préfixé par un trigramme propre au projet, faute de quoi une extension installée plus tard peut le réutiliser et écraser silencieusement l'affichage. L'intitulé, lui, doit être court : la largeur des colonnes se partage automatiquement, et un intitulé long réduit d'autant la place laissée au titre de l'article, qui reste la colonne la plus utile.

Choisir la position plutôt que de subir la fin de ligne

Ajouter simplement une entrée place la colonne tout à droite, souvent après la date, ce qui n'est pas l'endroit le plus lisible. Insérer la colonne à une position précise demande de reconstruire le tableau en le parcourant et en insérant la nouvelle entrée après une clé donnée. Cette manipulation tient en cinq lignes et change nettement le confort d'usage, en particulier quand la colonne ajoutée sert de critère de tri principal : on la veut alors juste après le titre, à portée de regard.

L'action qui remplit les cellules

Le second point d'accroche est appelé pour chaque ligne et pour chaque colonne, avec l'identifiant de la colonne et celui de l'article. Il n'attend aucune valeur de retour et doit afficher directement son contenu. Le réflexe indispensable est d'échapper toute valeur affichée, y compris celles qui proviennent de la base et semblent inoffensives : un champ personnalisé rempli par un import ou par une extension peut parfaitement contenir du balisage. L'échappement à l'affichage est la règle générale de WordPress, et le tableau d'administration n'y fait pas exception.

Afficher une information, pas une donnée brute

Une colonne utile affiche une information lisible en une fraction de seconde, pas une valeur brute qu'il faut interpréter. Un nombre de mots gagne à être accompagné d'un repère visuel quand il passe sous un seuil, une méta description absente doit se voir immédiatement, une image à la une manquante mérite un signe plutôt qu'un texte. Une pastille colorée, un point ou un tiret suffisent, à condition de ne jamais reposer sur la seule couleur : un intitulé ou un attribut de titre reste nécessaire pour rester accessible.

Les colonnes qui ne doivent pas exister

Toute donnée n'a pas sa place dans ce tableau. Une colonne dont le contenu demande une requête par ligne, une colonne qui affiche un texte long, une colonne dont l'information n'est utile qu'une fois par an alourdissent l'écran pour tout le monde et tous les jours. La discipline consiste à se limiter à trois colonnes ajoutées au maximum, et à supprimer celles qui ne servent plus. Les options d'écran de WordPress permettent par ailleurs à chaque utilisateur de masquer les colonnes qui ne l'intéressent pas, ce qui règle les désaccords d'usage sans code supplémentaire.

Traduire et rester compatible

Les intitulés de colonnes doivent passer par les fonctions de traduction de WordPress, même sur un site monolingue, parce que rien ne garantit que le site le restera et parce que c'est le seul moyen de conserver une cohérence si l'administration est affichée dans une autre langue par un utilisateur. Le domaine de traduction doit correspondre à celui déclaré par l'extension qui porte le code. C'est un détail de deux caractères qui, oublié, produit des colonnes en français au milieu d'une interface en anglais, ce qui est exactement le genre d'incohérence dont personne ne comprend l'origine six mois plus tard.

Rendre la colonne triable

Une colonne qui ne se trie pas ne sert qu'à regarder. Le tri est ce qui la transforme en outil, puisqu'il permet de faire remonter les articles les plus courts, les plus anciennement modifiés ou ceux dont la métadonnée manque. Le mécanisme demande deux ajouts supplémentaires, dont le second est le plus délicat, et sa mise en place suit la même logique que les tâches d'entretien décrites dans notre article sur la manière de programmer une tâche récurrente propre avec l'API Cron de WordPress.

Déclarer la colonne comme triable

Un filtre dédié reçoit la liste des colonnes triables et attend qu'on y ajoute l'identifiant de la colonne, associé à une clé de tri. Cette déclaration se contente de rendre l'en tête cliquable et d'ajouter le paramètre correspondant à l'adresse ; elle ne trie rien par elle même. C'est la source de confusion la plus fréquente : la colonne devient cliquable, l'ordre ne change pas, et on cherche l'erreur dans la déclaration alors qu'elle se trouve dans l'étape suivante.

Intervenir sur la requête principale

Le tri effectif se produit en modifiant la requête de l'écran d'administration, avant son exécution. Trois précautions s'imposent : vérifier qu'on se trouve bien dans l'administration, vérifier qu'il s'agit de la requête principale et non d'une requête secondaire déclenchée par une extension, et vérifier que le paramètre de tri correspond bien à celui que l'on a déclaré. Sans ces trois contrôles, la modification s'applique à des requêtes qu'elle n'aurait pas dû toucher, ce qui produit des effets à distance particulièrement difficiles à relier à leur cause.

Trier sur une métadonnée sans perdre de lignes

Trier sur une donnée stockée en métadonnée demande de la joindre à la requête, opération qui a une conséquence rarement anticipée : les articles dépourvus de cette métadonnée disparaissent purement et simplement de la liste. Or ce sont souvent exactement ceux que l'on cherche. La solution consiste à demander explicitement une jointure qui conserve les lignes sans valeur, en combinant dans la requête la condition d'existence et la condition d'absence, de manière à ce que les deux populations restent affichées.

Le tri numérique contre le tri alphabétique

Les métadonnées sont stockées sous forme de texte, ce qui fait qu'un tri naïf classe la valeur cent avant la valeur vingt. Il faut donc préciser le type de comparaison attendu, numérique ou décimal selon les cas, sans quoi le résultat semble aléatoire. Ce détail explique la majorité des tris qui paraissent fonctionner sur une page et se révèlent faux dès qu'on regarde de près, et il est d'autant plus vicieux que l'ordre obtenu peut sembler correct sur un petit échantillon.

Conserver un ordre secondaire stable

Quand plusieurs articles partagent la même valeur, l'ordre entre eux dépend de la base et peut varier d'une page à l'autre, ce qui produit des doublons entre pages et des articles jamais affichés. Déclarer un second critère de tri, la date ou l'identifiant, garantit un ordre total et supprime ce comportement. C'est le même raisonnement que pour une pagination publique, où l'absence d'ordre déterministe produit exactement les mêmes symptômes et se diagnostique très mal.

Restreindre l'affichage selon le rôle

Certaines colonnes n'ont de sens que pour une partie de l'équipe. Une colonne technique affichant une directive d'indexation ou un identifiant interne encombre l'écran d'un rédacteur et lui pose des questions auxquelles il n'a pas à répondre. La déclaration de la colonne peut donc être conditionnée à une capacité de l'utilisateur courant, ce qui est plus fiable que de raisonner par nom de rôle, les rôles étant fréquemment redéfinis par les extensions. On teste la capacité qui correspond réellement à l'action concernée, jamais un rôle nommé en dur.

Étendre la mécanique au reste de l'administration

Une fois la colonne en place sur les articles, la même mécanique se transpose presque à l'identique ailleurs, et c'est ce qui rend l'investissement rentable. Les points d'accroche changent de nom mais pas de logique, et un site un peu construit finit par disposer d'une petite panoplie d'écrans adaptés à ses propres usages.

Les pages et les types de contenu personnalisés

Les pages disposent de leurs propres points d'accroche, distincts de ceux des articles, et chaque type de contenu personnalisé possède les siens, construits sur le même modèle avec l'identifiant du type dans le nom. Écrire une fonction générique qui prend le type en paramètre, puis l'accrocher aux types voulus, évite de dupliquer trois fois le même code. Cette généralisation demande dix minutes de plus au moment de l'écriture et fait gagner beaucoup de temps le jour où un nouveau type de contenu arrive dans le projet.

Les utilisateurs et les taxonomies

La liste des utilisateurs accepte les mêmes ajouts, ce qui permet d'afficher le nombre d'articles publiés, la date de dernière connexion si elle est enregistrée, ou le rôle réel quand plusieurs extensions en ajoutent. Les listes de catégories et de mots clés fonctionnent également ainsi, avec une particularité : la fonction de remplissage y attend une valeur de retour au lieu d'un affichage direct, ce qui provoque une cellule vide chez qui applique la recette des articles sans lire la documentation.

Les actions groupées, prolongement naturel

Une fois les bonnes lignes affichées et sélectionnées, la suite logique est de pouvoir agir dessus en masse. WordPress permet d'ajouter des entrées au menu des actions groupées et de traiter la sélection, ce qui ouvre la porte à des opérations d'entretien utiles : recalculer une métadonnée, marquer des contenus à réviser, réattribuer un auteur. La prudence commande de ne jamais y placer d'action destructrice sans confirmation, et de traiter les identifiants reçus comme des données à valider, la sélection pouvant être manipulée.

Les vues enregistrées, qui manquent à WordPress

Le dernier manque de cet écran est l'impossibilité de mémoriser une combinaison de tri et de filtres. La solution la plus simple ne demande aucun code : la combinaison se retrouve intégralement dans l'adresse, qu'il suffit d'enregistrer en favori. Un lien vers cette adresse peut aussi être ajouté au menu d'administration, ce qui donne à l'équipe éditoriale un accès direct aux listes de travail utiles, par exemple les articles sans image à la une triés du plus ancien au plus récent.

Filtrer et surveiller les performances

Le tri répond à la question de l'ordre, le filtre répond à celle de la sélection, et les deux se combinent. C'est aussi le moment où les questions de performance apparaissent, car un écran d'administration lent est un écran que personne n'utilise, et un site à fort volume ne pardonne pas les requêtes coûteuses.

Ajouter un filtre au dessus du tableau

WordPress prévoit un point d'accroche pour insérer des contrôles au dessus de la liste, à côté des filtres natifs de date et de catégorie. Un simple menu déroulant y trouve sa place, dont la valeur sélectionnée est lue ensuite dans la modification de requête. La bonne pratique est de conserver la valeur choisie dans le menu après rechargement, sans quoi l'utilisateur ne sait plus quel filtre est actif, et de prévoir systématiquement une entrée qui remet le filtre à zéro.

Le coût réel d'une colonne calculée

Une colonne dont la valeur se calcule à l'affichage déclenche ce calcul pour chaque ligne, donc vingt fois par page par défaut. Un comptage de mots sur le contenu reste acceptable, une requête supplémentaire par ligne ne l'est pas. La règle est de ne jamais interroger la base dans la fonction d'affichage : si la donnée demande une requête, elle doit être calculée à l'enregistrement de l'article et stockée en métadonnée, ce qui la rend au passage triable et filtrable sans effort.

Précharger les métadonnées

WordPress charge en une seule requête toutes les métadonnées des articles affichés, à condition que la requête n'ait pas été configurée pour l'éviter. Une colonne qui lit une métadonnée ne coûte donc rien de plus, puisque la valeur est déjà en mémoire. En revanche, une colonne qui lit une donnée sur un objet lié, un terme de taxonomie ou un utilisateur par exemple, déclenche une requête par ligne si le préchargement correspondant n'a pas été demandé. C'est la cause la plus fréquente d'un écran d'administration devenu lent après l'ajout d'une colonne.

Mesurer plutôt que supposer

Le nombre de requêtes et le temps de génération de l'écran se mesurent directement, et cette mesure doit être faite avant et après l'ajout. Passer de quarante à quatre cents requêtes est parfaitement possible avec une colonne mal écrite, et le symptôme ne se manifeste que sur un site chargé, donc en production. Un écran d'administration qui met plusieurs secondes à s'afficher fait perdre bien plus de temps qu'il n'en fait gagner, ce qui annule complètement l'intérêt de la colonne.

Où placer ce code

Ces ajouts n'ont rien à faire dans le fichier de fonctions d'un thème, qu'un changement d'apparence emporterait avec lui : ce sont des fonctionnalités d'administration, pas de présentation. Le bon emplacement est une extension propre au site, de quelques fichiers, activée en permanence et versionnée avec le reste du projet. Cette séparation est la même que celle recommandée pour les snippets ajoutés au fichier functions.php, et elle évite la perte silencieuse de fonctionnalités lors d'une refonte graphique.

Documenter les colonnes ajoutées

Un tableau d'administration enrichi devient très vite une interface propre au site, que personne d'extérieur ne comprend sans explication. Une note de quelques lignes dans le dépôt, indiquant à quoi sert chaque colonne, d'où vient sa donnée et quand elle est recalculée, suffit à rendre l'ensemble reprenable. Cette note évite surtout le scénario classique où une colonne affiche une valeur devenue fausse depuis un changement d'extension, sans que personne ne sache dire d'où elle sortait ni s'il est prudent de la retirer.