Le composant WP_List_Table, utilisé depuis des années pour tous les tableaux d’administration de WordPress, fonctionne, mais son code est verbeux et son rendu reste figé dans une esthétique d’un autre temps : pas de vue en grille, pas de filtre rapide sans rechargement de page, pas de personnalisation des colonnes visibles par l’utilisateur. Le paquet @wordpress/dataviews, utilisé en interne par WordPress pour des écrans comme la bibliothèque de médias ou la gestion des pages, est désormais disponible pour les auteurs d’extensions qui veulent un tableau d’administration à la hauteur des standards actuels.
Cet article construit, étape par étape, un écran d’administration listant des « missions » d’une extension de gestion de prestataires, avec filtre par statut, tri par date, et action de suppression, sans dépendre de l’éditeur de site.
Étape 1 : préparer les dépendances
DataViews est un composant React fourni par le paquet @wordpress/dataviews, à charger via wp_enqueue_script() avec les dépendances habituelles de l’écosystème Gutenberg :
add_action( 'admin_enqueue_scripts', function( $hook ) {
if ( 'toplevel_page_mon-extension-missions' !== $hook ) {
return;
}
wp_enqueue_script(
'mon-extension-missions',
plugins_url( 'build/missions.js', __FILE__ ),
array( 'wp-dataviews', 'wp-element', 'wp-components', 'wp-api-fetch', 'wp-i18n' ),
MON_EXTENSION_VERSION,
true
);
wp_enqueue_style( 'wp-components' );
wp_enqueue_style( 'wp-dataviews' );
} );
Étape 2 : exposer les données via l’API REST
DataViews consomme des données, il ne les stocke pas : il faut un point d’accès REST qui renvoie la liste des missions avec ses champs de tri et de filtre.
add_action( 'rest_api_init', function() {
register_rest_route( 'mon-extension/v1', '/missions', array(
'methods' => 'GET',
'callback' => 'mon_extension_rest_lister_missions',
'permission_callback' => function() {
return current_user_can( 'manage_options' );
},
) );
} );
function mon_extension_rest_lister_missions( $requete ) {
global $wpdb;
$missions = $wpdb->get_results(
"SELECT id, titre, statut, prestataire, date_prevue FROM {$wpdb->prefix}mon_extension_missions ORDER BY date_prevue DESC",
ARRAY_A
);
return rest_ensure_response( $missions );
}
Étape 3 : définir les champs côté JavaScript
DataViews sépare clairement la définition des champs (leur type, comment les trier, comment les afficher) de la configuration de la vue (quelles colonnes visibles, quel tri par défaut, quel filtre actif). C’est cette séparation qui rend le composant flexible :
import { DataViews } from '@wordpress/dataviews/wp';
import { useState, useEffect } from '@wordpress/element';
import apiFetch from '@wordpress/api-fetch';
const champs = [
{ id: 'titre', label: 'Mission', enableSorting: true },
{
id: 'statut',
label: 'Statut',
elements: [
{ value: 'a_faire', label: 'À faire' },
{ value: 'en_cours', label: 'En cours' },
{ value: 'terminee', label: 'Terminée' },
],
},
{ id: 'prestataire', label: 'Prestataire' },
{ id: 'date_prevue', label: 'Date prévue', enableSorting: true },
];
function EcranMissions() {
const [ missions, setMissions ] = useState( [] );
const [ vue, setVue ] = useState( {
type: 'table',
perPage: 20,
sort: { field: 'date_prevue', direction: 'desc' },
fields: [ 'titre', 'statut', 'prestataire', 'date_prevue' ],
} );
useEffect( () => {
apiFetch( { path: '/mon-extension/v1/missions' } ).then( setMissions );
}, [] );
return (
<DataViews
data={ missions }
fields={ champs }
view={ vue }
onChangeView={ setVue }
getItemId={ ( item ) => String( item.id ) }
actions={ [
{
id: 'supprimer',
label: 'Supprimer',
callback: ( items ) => {
items.forEach( ( item ) =>
apiFetch( { path: `/mon-extension/v1/missions/${ item.id }`, method: 'DELETE' } )
);
},
},
] }
/>
);
}
Ce que DataViews gère automatiquement
Une fois cette structure en place, plusieurs comportements fonctionnent sans code additionnel : le tri par colonne cliquable, le filtre par statut avec un menu déroulant généré à partir des elements déclarés, la pagination, la recherche textuelle, et le choix des colonnes visibles par l’utilisateur via un menu de configuration intégré au composant. C’est précisément ce qui, avec WP_List_Table, demandait d’écrire chaque comportement à la main.
Vue en grille pour les contenus visuels
Un atout de DataViews sur des données comportant des visuels (une galerie de prestataires avec photo, par exemple) : changer type: 'table' en type: 'grid' dans l’objet vue bascule instantanément l’affichage en cartes, sans réécrire la logique de données.
Limites à connaître
- DataViews reste un composant relativement récent, son API a évolué depuis son introduction et continue d’évoluer : vérifier la version du paquet chargée par le cœur WordPress avant de s’appuyer sur des options avancées.
- Le composant ne gère pas la persistance des données lui-même : toute la logique de lecture, filtre et écriture reste à la charge de l’extension via l’API REST.
- Un utilisateur avec JavaScript désactivé ne verra rien : contrairement à
WP_List_Table, DataViews dépend entièrement du rendu côté client.
Sur ce projet de gestion de prestataires, le gain le plus apprécié par le client n’est pas visuel mais fonctionnel : ses équipes peuvent désormais choisir elles-mêmes les colonnes affichées selon leur rôle, sans qu’on ait eu à coder cette option.
Notre verdict
Pour un nouvel écran d’administration de données tabulaires, DataViews mérite d’être préféré à WP_List_Table dès que le projet peut se permettre une dépendance à React et à une API REST dédiée. Le résultat est plus riche pour l’utilisateur final et le code à écrire côté extension est nettement plus court, à condition d’accepter de sortir du confort du PHP procédural pour l’écran concerné.
