Vous avez un bon vieux blog WordPress mais :
- vous souhaitez découplé votre back et votre front pour pouvoir vous amuser avec les différents frameworks js
- vous trouvez que les thèmes wordpress deviennent de grosses usines gaz difficilement maintenable
- vous souhaitez vous débarrasser de votre vieux client ftp et passer à un workflow moderne
- vous êtes un sentimental et n’êtes pas prêt à vous débarrasser complètement de wordpress
- vous avez la grosse flemme de gérer la migration de l’ensemble de vos articles vers un autre CMS
alors il est peut être pertient de passer votre CMS préféré en mode : HEADLESS !!! (à prononcer en imitant la voix off des bandes annonces des films d’action des années 90)
C’est quoi un CMS Headless ?
Un CMS (Content Management System ou Système de gestion du contenu) est – comme son nom l’indique vachement bien – un outil qui permet de créer, stocker et gérer du contenu. Habituellement -et comme son nom ne l’indique pas du tout – un CMS s’occupe également de l’affichage de ce contenu via des thèmes ou des templates.
Un CMS headless, c’est tout pareil qu’un CMS sauf qu’il abandonne totalement la partie affichage. A la place il fournit une API qui va permettre de récupérer le contenu pour l’afficher dans une application front à part.
Initialement, WordPress est un CMS classique mais depuis 2016, API REST de WordPress permet de récupérer le contenu.
L’API REST de WordPress
Pour activer l’API REST de WordPress, il suffit de… bah de ne rien faire en fait ! L’API REST de votre installation wordpress répondra à une URL de type :https://nomdedomaine/wp-json/wp/v2/[endpoint de la ressource]
(la liste des endpoints disponibles se trouve dans la doc wordpress).
Par exemple, requête cURL suivante affichera tous les articles de ce blog : curl -X GET http://wp-api.julienbruneel.fr/wp-json/wp/v2/posts
Si une erreur 404 est renvoyée…
Si une erreur 404 est renvoyée, il s’agit sans doute d’une mauvaise configuration des permaliens ou de votre fichier de configuration apache .htaccess. On trouvera une liste des erreurs courantes concernant l’API REST de WordPress ici.
Et si on veut utiliser GraphQL ?
Pour certaines raisons, il se peut que nous voulions utiliser GraphQL pour récupérer notre contenu.
Dans ce cas il va nous falloir disposer d’une API GraphQL nous retournant les données de WordPress. Pour cela, il existe un plugin Wordrpess qui va se charger de mettre à disposition cette API : WPGraphQL. Une fois l’extension installée, nous avons accès, dans l’administration WordPress, à un nouvel onglet GraphQL qui permettra notamment d’avoir accès aux paramètres graphQL et à l’interface graphiQL IDE.
Et le thème dans tout ça ?
C’est vrai ça ! Normalement qui dit WordPress dit thème ! Or dans notre contexte, WordPress ne sera qu’un back office qui n’affichera rien par lui même. Dans l’absolu, on pourrait donc très bien ne pas se soucier du thème qui est activé et tout se passerait souvent très bien. Mais la plupart des thèmes WordPress possèdes différentes fonctions qui modifient le comportement du back office en ajoutant certaines fonctionnalités : post thumbnails, custom post types… I
Si on veut faire les choses proprement, il est plus pertinent de se créer un thème « blanc », qui n’affichera rien. Pour ce faire il suffit d’ajouter un fichier functions.php vide ainsi qu’un fichier style.css avec les informations concernant le thème, par exemple :
/*
Theme Name: Jbee minimal blank theme
Description: A blank theme to use WordPress as headless CMS.
Author: Julien Bruneel
Author URI: https://www.julienbruneel.fr
Version: 1.0.0
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
*/
On peut également se procurer un thème blanc existant comme par exemple celui-ci qui intègre une redirection systématique de l’url wordpress vers l’url de votre site statique.
function.php file ou plugin ?
Il est fréquent d’ajouter des fonctionnalités de WordPress via le fichier function.php du thème : types de contenus personnalisés, modification des taxonomies, images mise en avant dans les articles… Cela pouvait en effet avoir du sens de considérer que l’on y faisait avait vocation à être utilisé et affiché par le thème. En headless, il semble plus cohérent d’ajouter ces fonctionnalités via une extension afin d’avoir un maximum de modularité.