Pourquoi ce projet ?
En maintenance de sites WordPress, la première difficulté n’est pas de corriger un bug : c’est de comprendre où et comment il s’est produit, souvent à partir d’une description du type « ça ne marche pas ». WBugBoard est né de ce constat.
Le problème
Un formulaire de contact classique donne un texte libre, sans contexte technique. Reconstituer l’environnement d’un bug après coup — page concernée, navigateur, résolution d’écran — fait perdre du temps, ou rend parfois le bug impossible à reproduire.
La solution
WBugBoard ajoute un widget de signalement directement sur le site, qui capture automatiquement l’URL de la page, le user agent, la langue du navigateur et la résolution d’écran au moment de la création du ticket, en plus de la description donnée par l’utilisateur.
Fonctionnalités
- Création de tickets avec niveaux de priorité et statuts
- Widget de signalement front-end pour les utilisateurs connectés
- Commentaires sur chaque ticket
- Notifications par email, configurables séparément pour l’équipe et l’utilisateur
- Contrôle d’accès par rôle WordPress
- Interface d’administration dédiée pour l’équipe support
Architecture technique
Le plugin stocke les tickets, commentaires et priorités dans trois tables SQL dédiées avec des clés étrangères vers la table des utilisateurs WordPress, plutôt que d’utiliser un Custom Post Type — un choix qui simplifie les jointures entre un ticket et son auteur. L’interface est développée en Vue.js 3, et les échanges passent par l’API REST native de WordPress.
Choix techniques
Chaque route d’écriture vérifie un nonce WordPress en plus du contrôle de capacité utilisateur. L’accès au widget front-end est limité à une liste de rôles configurable, pour ne pas exposer un canal de signalement à n’importe quel visiteur anonyme.
Difficultés rencontrées
Publier sur le répertoire officiel wordpress.org impose des contraintes qu’un plugin interne n’a pas : compatibilité annoncée avec une plage de versions WordPress précise, passage par la revue du répertoire avant publication, et une discipline de version stricte — chaque changement de comportement doit être documenté publiquement dans le changelog.
WBugBoard est né d’un besoin rencontré en développement WordPress sur mesure : un outil métier pour suivre des anomalies, pas un simple formulaire de contact.
