Trois valeurs à retenir avant même la quatrième : local, development, staging, et enfin production, qui reste la valeur par défaut si la constante n’est pas définie. C’est l’ensemble complet des valeurs prédéfinies reconnues par WP_ENVIRONMENT_TYPE, introduite dans WordPress 5.5 en août 2020, sans qu’aucune extension supplémentaire ne soit nécessaire pour en profiter.
Pour un projet headless qui expose une API REST consommée par plusieurs fronts, cette constante permet d’adapter le comportement de certaines routes selon qu’elles tournent sur un environnement de préproduction interne ou sur la production réellement publique, sans dupliquer de configuration ailleurs.
Définir la constante dans wp-config.php
define( 'WP_ENVIRONMENT_TYPE', 'staging' );Cette ligne se place avant l’appel à require_once ABSPATH . 'wp-settings.php', comme toute constante de configuration classique. Une bonne pratique consiste à faire dépendre sa valeur d’une variable d’environnement système plutôt que de la coder en dur, pour éviter d’avoir à modifier ce fichier entre chaque environnement.
define( 'WP_ENVIRONMENT_TYPE', getenv( 'WP_ENV' ) ?: 'production' );Lire la valeur courante côté PHP
La fonction wp_get_environment_type() retourne la valeur effective, en tenant compte du repli automatique vers production si la constante n’a pas été définie ou contient une valeur non reconnue :
function api_get_donnees_sensibles( $request ) {
if ( 'production' === wp_get_environment_type() ) {
return new WP_Error( 'rest_forbidden', 'Non disponible en production.', array( 'status' => 403 ) );
}
// Données de debug réservées aux environnements non-production
return rest_ensure_response( api_construire_donnees_debug() );
}Un cas d’usage concret pour une API REST
Sur un projet où l’API REST expose, en plus des routes standards, quelques routes de diagnostic destinées uniquement aux développeurs, la vérification de l’environnement permet de désactiver ces routes de diagnostic dès que le code tourne en production, sans devoir maintenir une configuration séparée dans un fichier annexe.
- Routes de debug actives uniquement en
localoudevelopment - Journalisation plus verbeuse en
stagingpour valider un comportement avant bascule - Repli automatique vers
productionqui protège contre un oubli de configuration
Utiliser la constante dans un filtre plutôt que dans chaque route
Plutôt que de répéter la même vérification dans chaque callback de route, un filtre appliqué globalement sur rest_pre_dispatch permet de centraliser la logique de blocage des routes de diagnostic, en s’appuyant sur un simple préfixe de namespace pour les identifier :
add_filter( 'rest_pre_dispatch', function( $result, $server, $request ) {
$route = $request->get_route();
if ( 0 === strpos( $route, '/diagnostic/' ) && 'production' === wp_get_environment_type() ) {
return new WP_Error( 'rest_forbidden', 'Route désactivée en production.', array( 'status' => 403 ) );
}
return $result;
}, 10, 3 );Cette centralisation évite d’oublier la vérification sur une nouvelle route de diagnostic ajoutée plus tard par un autre développeur, qui n’aurait pas forcément connaissance de cette convention si elle n’était répétée que localement dans chaque callback.
Le piège d’une valeur mal orthographiée
Une faute de frappe dans la valeur de la constante, par exemple producton au lieu de production, ne déclenche aucune erreur visible : wp_get_environment_type() retombe silencieusement sur production puisque la valeur fournie ne correspond à aucune des valeurs reconnues. Ce comportement protège par défaut, mais peut aussi masquer une erreur de configuration qui serait plus utile à détecter explicitement.
Une constante d’environnement qui échoue silencieusement vers la valeur la plus prudente reste préférable à une constante qui échouerait vers la moins prudente, mais elle demande tout de même une vérification lors du déploiement.
En résumé
WP_ENVIRONMENT_TYPE offre un mécanisme natif, disponible depuis WordPress 5.5, pour adapter le comportement d’une API REST selon l’environnement qui l’exécute, sans dépendre d’une extension tierce ni d’un fichier de configuration additionnel. Cette notion ne traite pas la gestion des secrets d’API, qui reste un sujet distinct nécessitant ses propres mécanismes de protection.
