%s
', __( 'Renseignez votre clé API caisse dans les réglages de Mon Extension pour activer la synchronisation.', 'mon-extension' ) ), 'test' => 'mon_extension_cle_api', ); } return array( 'label' => __( 'Clé API caisse configurée', 'mon-extension' ), 'status' => 'good', 'badge' => array( 'label' => __( 'Mon Extension', 'mon-extension' ), 'color' => 'blue', ), 'description' => sprintf( '%s
', __( 'Une clé API est configurée.', 'mon-extension' ) ), 'test' => 'mon_extension_cle_api', ); } ``` Le tableau retourné doit respecter une structure précise : `label`, `status` (`good`, `recommended` ou `critical`), `badge`, `description` en HTML, et un identifiant `test` unique. C'est cette structure que l'écran utilise pour afficher la bonne couleur et le bon regroupement. ## Un test asynchrone pour les vérifications réseau Vérifier que le serveur de caisse répond nécessite une requête HTTP sortante, potentiellement lente. Exécuter cette vérification en direct ralentirait le chargement de tout l'écran Santé du site, y compris pour les autres tests. WordPress permet de déclarer ce type de test comme asynchrone : il est exécuté séparément via une requête REST déclenchée par JavaScript une fois la page chargée. ``` add_filter( 'site_status_tests', function( $tests ) { $tests['async']['mon_extension_connexion_caisse'] = array( 'label' => __( 'Connexion au logiciel de caisse', 'mon-extension' ), 'test' => 'mon_extension_connexion_caisse', 'has_rest' => true, 'async_direct_test' => 'mon_extension_test_connexion_caisse', ); return $tests; } ); function mon_extension_test_connexion_caisse() { $reponse = wp_remote_get( 'https://api.caisse-exemple.fr/statut', array( 'timeout' => 5 ) ); if ( is_wp_error( $reponse ) || 200 !== wp_remote_retrieve_response_code( $reponse ) ) { return array( 'label' => __( 'Connexion au logiciel de caisse indisponible', 'mon-extension' ), 'status' => 'critical', 'badge' => array( 'label' => __( 'Mon Extension', 'mon-extension' ), 'color' => 'red' ), 'description' => '' . esc_html__( 'Le serveur du logiciel de caisse ne répond pas. Vérifiez le pare-feu sortant.', 'mon-extension' ) . '
', 'test' => 'mon_extension_connexion_caisse', ); } return array( 'label' => __( 'Connexion au logiciel de caisse opérationnelle', 'mon-extension' ), 'status' => 'good', 'badge' => array( 'label' => __( 'Mon Extension', 'mon-extension' ), 'color' => 'blue' ), 'description' => '' . esc_html__( 'La connexion fonctionne.', 'mon-extension' ) . '
', 'test' => 'mon_extension_connexion_caisse', ); } ``` Le drapeau `has_rest` indique à WordPress de router ce test vers l'API REST plutôt que de l'exécuter en direct. C'est indispensable pour tout appel réseau ou toute opération qui peut prendre plusieurs secondes. ## Enrichir les informations de débogage L'onglet « Informations » de l'écran Santé du site génère un rapport texte que les utilisateurs copient-collent dans un ticket de support. Le filtre `debug_information` permet d'y ajouter une section propre à l'extension, avec les données réellement utiles au diagnostic : ``` add_filter( 'debug_information', function( $infos ) { $infos['mon-extension'] = array( 'label' => __( 'Mon Extension', 'mon-extension' ), 'fields' => array( 'version' => array( 'label' => __( 'Version installée', 'mon-extension' ), 'value' => MON_EXTENSION_VERSION, ), 'derniere_sync' => array( 'label' => __( 'Dernière synchronisation', 'mon-extension' ), 'value' => get_option( 'mon_extension_derniere_sync', __( 'jamais', 'mon-extension' ) ), ), ), ); return $infos; } ); ``` ## Ce que ça change côté support Depuis que cette extension expose ses propres tests, les tickets de support arrivent avec un rapport qui indique directement si la clé API est absente, si la connexion réseau échoue, ou si la synchronisation n'a jamais tourné. Le premier échange de diagnostic, qui prenait auparavant plusieurs allers-retours, disparaît presque totalement. ## En résumé L'écran Santé du site n'est pas réservé au cœur de WordPress : c'est une extension prévue pour accueillir les diagnostics propres à chaque extension installée. Un test direct pour les vérifications rapides, un test asynchrone dès qu'un appel réseau est en jeu, et une section dans `debug_information` pour le rapport de support — ces trois ingrédients suffisent à transformer un support flou en diagnostic exploitable dès le premier message.