WordPress 4.4, publiée en décembre 2015, marque une étape moins connue que la sortie ultérieure de la version 4.7 : c’est elle qui introduit dans le cœur les fondations de l’API REST, sans pour autant y inclure encore les routes de contenus elles-mêmes. Cette distinction, souvent oubliée, explique certains comportements que des développeurs découvrent encore aujourd’hui sur des installations anciennes jamais entièrement mises à jour dans leurs habitudes de configuration.
Le plugin WP REST API, développé séparément pendant plusieurs années, servait de terrain d’expérimentation avant cette intégration progressive. Comprendre ce qui distinguait ce plugin de l’API native actuelle aide à interpréter certains réglages hérités que l’on retrouve encore, par habitude, dans des projets démarrés à cette époque et maintenus depuis.
Ce que WordPress 4.4 a réellement ajouté
Cette version a intégré l’infrastructure : la classe WP_REST_Server, le mécanisme de routage via register_rest_route(), et le point d’entrée /wp-json/. Elle n’a en revanche pas intégré les routes exposant les articles, les pages ou les utilisateurs, qui demeuraient à cette date la responsabilité exclusive du plugin distinct, toujours nécessaire pour quiconque souhaitait consommer du contenu WordPress via une API structurée.
L’arrivée des routes de contenus avec WordPress 4.7
Il faut attendre WordPress 4.7, publiée en décembre 2016, pour voir les routes de contenus rejoindre définitivement le cœur du logiciel. Le plugin WP REST API original a alors basculé vers un rôle de rétrocompatibilité, avant d’être définitivement retiré du répertoire officiel des extensions, sa mission ayant été remplie.
Les traces qui subsistent aujourd’hui
Sur un projet dont l’historique remonte à cette période de transition, plusieurs habitudes de configuration héritées de cette époque continuent parfois d’apparaître dans le code, sans justification technique actuelle :
- Des appels à
add_action( 'rest_api_init', ... )conditionnés par une vérification de l’existence de la classeWP_REST_Server, devenue superflue depuis que cette classe fait partie intégrante du cœur. - Des extensions tierces qui référencent encore, dans leur documentation, une dépendance au plugin WP REST API original, alors que cette dépendance n’a plus lieu d’être depuis WordPress 4.7.
- Des vérifications de version minimale fixées à 4.4 dans certains fichiers d’en-tête d’extension, sans tenir compte du fait que les routes de contenus n’existaient pas encore à cette version précise.
Pourquoi cette distinction reste utile aujourd’hui
Un développeur qui intervient sur un projet ancien et rencontre une référence à cette période gagne à comprendre cette chronologie précise : elle explique pourquoi certaines vérifications de compatibilité, écrites à l’époque, portent sur la présence de classes internes plutôt que sur un simple numéro de version, une pratique de prudence qui avait du sens quand l’API elle-même était encore en cours de stabilisation.
// Pratique héritée de la période de transition, devenue inutile
if ( class_exists( 'WP_REST_Server' ) ) {
add_action( 'rest_api_init', 'projet_enregistrer_routes' );
} else {
add_action( 'plugins_loaded', 'projet_enregistrer_routes' );
}Sur toute installation WordPress récente, largement postérieure à la version 4.7, cette vérification de compatibilité ne sert plus à rien : elle peut être simplifiée en un simple add_action( 'rest_api_init', 'projet_enregistrer_routes' ), sans condition préalable.
Une leçon sur la durée de vie du code
Cet exemple illustre une réalité fréquente dans l’écosystème WordPress : du code écrit pour gérer une période de transition technique continue parfois de vivre bien après que cette transition s’est achevée, simplement parce que personne n’a eu l’occasion de le retirer une fois devenu superflu.
Une vérification de compatibilité ajoutée par prudence à un instant donné mérite d’être réévaluée régulièrement : ce qui protégeait contre une version instable hier peut devenir du code mort qui complique la lecture aujourd’hui.
En résumé
La distinction entre WordPress 4.4 et WordPress 4.7 dans l’histoire de l’API REST n’est pas qu’une curiosité historique : elle explique concrètement certains réglages et vérifications encore présents dans du code hérité. Repérer ces traces permet de les simplifier en toute confiance sur un projet dont l’exigence de compatibilité minimale dépasse largement cette période de transition aujourd’hui révolue.
