Quand et quand ne pas utiliser WordPress sans tête

Headless WordPress suscite de plus en plus d'intérêt de la part des développeurs et des sociétés d'hébergement, en particulier au cours des derniers mois. Avec WP Engine lançant son hébergement Atlas et de plus en plus de développeurs préférant les frameworks Javascript pour alimenter le frontend de leurs sites, WordPress sans tête semble offrir le meilleur des deux mondes : une expérience éditoriale familière sur le backend avec la possibilité de choisir une pile technologique moderne sur le front-end.

Cependant, malgré tous les avantages de WordPress sans tête, il existe également certains inconvénients. Tous les environnements d'hébergement ne sont pas configurés pour gérer nativement WordPress sans tête, donc si vous êtes habitué à une configuration WordPress plus traditionnelle, vous devrez peut-être faire preuve de créativité avec votre hébergement.

De plus, comme le frontend et le backend sont séparés, certains des éléments de WordPress qui sont normalement inclus doivent être recréés ou à tout le moins repensés.

Dans cet article, nous examinerons certains des cas d'utilisation où WordPress sans tête brille vraiment, ainsi que certaines des situations dans lesquelles vous voudrez peut-être vous en tenir à une configuration WordPress plus traditionnelle. Et à la fin, j'espère vous donner une meilleure idée de savoir si WordPress sans tête est une bonne option pour votre prochain projet. Plongeons dedans.

Qu'est-ce que WordPress sans tête

Alors qu'une configuration WordPress traditionnelle s'exécute sur un serveur qui fournit à la fois le backend pour les éditeurs et les créateurs de contenu ainsi que le modèle et tout le reste pour que le site Web soit beau sur le frontend, WordPress sans tête est un terme utilisé pour décrire quand le frontend et le backend qui compose un site WordPress sont séparés.

Cela signifie que, bien que l'expérience backend WordPress traditionnelle soit la même, WordPress n'est pas responsable de la diffusion de tout modèle ou contenu lié au thème.

Dans une configuration sans tête, WordPress produit tout le contenu du site via des points de terminaison API (généralement l'API WordPress REST ou WP GraphQL). Ces points de terminaison d'API sont consommés par une interface distincte qui est entièrement responsable de la gestion de l'affichage du contenu.

Dans de nombreux cas, il s'agit d'un site assemblé avec l'un des frameworks Javascript populaires, une application mobile, une application de conversation alimentée par Alexa ou Google Home ou presque n'importe quelle interface pouvant consommer du contenu via une API. Jetez un œil à la vidéo WPCasts ci-dessous pour voir à quoi cela pourrait ressembler.

Cela rend un site WordPress sans tête beaucoup plus flexible en termes de présentation du contenu. Avec une configuration WordPress traditionnelle, vous êtes en grande partie enfermé dans la sortie contrôlée par le thème, mais avec sans tête, vous pouvez produire le même contenu et le présenter à vos utilisateurs finaux de différentes manières car la présentation est contrôlée par la plate-forme qui consomme finalement les points de terminaison de l'API.

Avantages de WordPress sans tête

Headless WordPress continue de gagner en popularité car pour certaines équipes de développeurs et de contenu, il y a certainement de gros avantages à une configuration sans tête.

Différentes équipes peuvent faire ce qu'elles font le mieux

Certaines organisations, même des entreprises de logiciels qui emploient des développeurs, constatent que même si le service marketing souhaite utiliser WordPress pour le site marketing, cela ne chevauche pas les compétences de leurs développeurs existants et ils finissent par sous-traiter ce travail à une agence ou à un indépendant. qui est plus centré sur WordPress.

Cependant, avec une configuration WordPress sans tête, les développeurs internes peuvent choisir d'utiliser le framework frontal de leur choix pour développer le frontend du site, en tirant parti de leurs compétences existantes même s'ils n'ont aucune expérience avec WordPress.

Le travail spécifique à WordPress peut ensuite être externalisé et connecté à l'interface interne via l'API, ce qui permet potentiellement d'économiser sur les coûts de développement du site et de permettre à toutes les connaissances spécifiques à la marque et à l'entreprise qui sont internes de passer sur l'interface. du site où il pourrait y avoir quelque chose de perdu dans la traduction autrement.

Les éditeurs peuvent utiliser le WordPress qu'ils connaissent

Si vous avez une équipe éditoriale ou des créateurs de contenu qui connaissent déjà l'expérience d'édition de WordPress (ce qui est de plus en plus courant à mesure que WordPress prend encore plus de parts de marché), vous n'avez pas à choisir entre laisser votre frontend se tenir à jour avec les toutes dernières technologies et offrant à l'équipe de création de contenu une expérience qui leur est familière.

En utilisant une configuration WordPress sans tête, les créateurs de contenu peuvent continuer à produire du contenu dans l'expérience WordPress qu'ils connaissent, tandis que l'équipe de développement est libre d'utiliser les technologies frontales avec lesquelles elle est la plus à l'aise.

Les API backend peuvent alimenter différentes plates-formes

Lorsque vous travaillez avec une configuration sans tête où WordPress alimente les points de terminaison de l'API au lieu de simplement servir des modèles frontaux, vous avez la possibilité de faire en sorte que ces points de terminaison poussent le contenu vers des interfaces autres qu'un simple site Web.

Les mêmes points de terminaison API qui diffusent votre contenu sur le Web peuvent également alimenter des applications mobiles, s'interfacer avec un autre CMS qui alimente une publication imprimée, être le fournisseur de contenu pour une application vocale avec Alexa ou Google Home et bien plus encore.

Étant donné que de nombreuses interfaces sont configurées pour consommer des API, l'utilisation de WordPress en tant qu'application sans tête élargit vraiment les possibilités d'utilisation et de réutilisation du contenu que vous écrivez déjà dans WordPress.

Inconvénients de WordPress sans tête

Bien qu'il y ait certains avantages à une configuration WordPress sans tête, ce n'est certainement pas pour tout le monde. Si vous êtes habitué à une expérience WordPress plus traditionnelle et que vous ne correspondez à aucune des situations ci-dessus, voici quelques-uns des inconvénients potentiels que vous voudrez prendre en compte avant de vous lancer.

Les plugins ne fonctionnent pas toujours

La plupart des gens ont l'impression de WordPress et de l'écosystème WordPress que si vous avez besoin de fonctionnalités supplémentaires pour votre site, vous pouvez rechercher un plugin qui fournit cette fonctionnalité, l'installer et « ça marche », souvent sans aucun code ou configuration nécessaire.

Cependant, avec une configuration WordPress sans tête, de nombreux plugins ne fonctionnent pas prêts à l'emploi, car ils ne sont pas nécessairement conscients qu'ils doivent fournir leurs fonctionnalités via l'API. Pour certains plugins, ce genre de comportement n'est même pas possible.

Prenez, par exemple, un plugin qui ajoute des liens de partage social en haut de la page de publication unique pour rendre le contenu plus facilement partageable sur les différents réseaux sociaux. Avec une installation WordPress normale, ce plugin pourrait être activé et les icônes de partage social pourraient être facilement injectées automatiquement ou en utilisant un shortcode ou quelque chose et vous seriez prêt.

Cependant, avec une configuration sans tête, ces icônes sociales ne sont pas transmises via la sortie de l'API, car elles n'existent pas dans le contenu de la publication. Et même s'ils étaient en quelque sorte ajoutés à la sortie du point de terminaison de l'API pour un article particulier, ils n'apparaîtraient pas sur l'interface du site à moins que l'interface n'ait été spécialement conçue pour rechercher cette sortie et afficher les boutons. Bien que cela ne soit pas impossible, cela rend de nombreux plugins WordPress plus longs à mettre en œuvre dans une configuration sans tête.

Les équipes familières avec WordPress ne « deviennent » pas toujours sans tête

Si vos développeurs ou votre équipe de développement connaissent déjà une configuration WordPress plus traditionnelle, où la logique d'affichage existe dans le thème et la plupart des personnalisations sont apportées aux fichiers de thème, changer cet état d'esprit pour travailler avec une configuration sans tête peut parfois être difficile.

Même du point de vue du processus de développement, une configuration sans tête nécessite parfois un changement dans la façon dont le contrôle de version est utilisé, la façon dont les déploiements et l'hébergement automatisés sont configurés et gérés, et augmente le besoin de communication, surtout si deux développeurs ou équipes différents travaillent sur le pièces frontend et backend du site. Toutes ces choses sont des tâches que les développeurs avaient l'habitude de travailler tous ensemble dans un thème WordPress plus standard et qui n'avaient peut-être jamais eu à s'en occuper auparavant.

Le débogage peut devenir plus difficile

Tout système, qu'il soit distribué ou plutôt monolithique, peut avoir des bogues qui surviennent au cours de son fonctionnement. L'un des défis des systèmes distribués, cependant, est qu'il y a tellement plus de données et tellement plus de choix que vous devez faire lorsque vous essayez de déboguer un problème. Par exemple, avec une configuration WordPress sans tête, si vous rencontrez un problème avec des publications qui ne se chargent pas dans l'ordre auquel vous vous attendez.

Pour même commencer à déboguer ce problème, vous devez d'abord décider si le problème concerne la partie frontale du site ou le backend. Comme ceux-ci sont probablement hébergés à deux endroits distincts, vous devrez ensuite trouver le fichier journal correct pour le système d'où vous pensiez que le bogue provenait.

S'il y avait un problème sur le backend, par exemple, où il ne fournissait pas les publications correctes via le point de terminaison de l'API. Si vous déboguez un site WordPress normal, vous pouvez essayer de faire echo ou var_dump certaines informations de débogage, puis de voir comment ces informations apparaissent sur le front-end pendant que vous déboguez.

Cependant, avec une configuration sans tête, ces informations n'apparaîtront pas dans votre modèle, mais plutôt dans vos points de terminaison d'API. Et selon la configuration de vos points de terminaison d'API, ce type de débogage peut ne pas fonctionner du tout.

Surtout si le travail de maintenance du front-end du site et du back-end du site est réparti entre deux équipes différentes, le débogage d'une configuration WordPress sans tête est généralement plus difficile et implique plus de communication qu'un site WordPress plus traditionnel. Surtout si vous n'êtes pas aussi expérimenté dans le débogage de systèmes distribués, cela peut être une bonne raison de préférer une configuration plus simple.

WYSIWYG est plus difficile

L'une des principales promesses de l'éditeur de blocs dans WordPress est qu'il rapproche votre expérience WordPress de l'un des idéaux de nombreuses plates-formes CMS - offrant une expérience "Ce que vous voyez est ce que vous obtenez" lorsque le contenu passe de l'éditeur au frontale du site.

Cependant, sur les sites WordPress où le style de bloc dans l'éditeur se trouve dans une base de code distincte de l'affichage frontal, il devient un peu plus difficile de synchroniser ces composants. Lorsque des modifications sont apportées à la base de code frontale, ces modifications doivent également être communiquées et reflétées dans les styles de l'éditeur pour conserver cette expérience WYSIWYG cohérente.

Comme pour certains de nos autres inconvénients de WordPress sans tête notés ci-dessus, cela signifie simplement que plus de communication et d'organisation sont nécessaires pour maintenir les deux bases de code synchronisées et offrir la meilleure expérience à la fois aux créateurs de contenu utilisant le backend, mais aussi aux utilisateurs finaux. l'interface du site.

Alors, quel est le meilleur?

Si vous êtes allé aussi loin, vous pouvez probablement anticiper cette réponse, mais que vous deviez ou non utiliser WordPress sans tête pour votre prochain projet de site dépend vraiment de vous, de l'équipe qui y travaille, de la manière dont le projet est déployé et de nombreux autres facteurs.

Si vous avez une équipe frontend solide qui est à l'aise avec les API et qui est habituée à communiquer les changements et à travailler avec des systèmes plus distribués, il peut être logique qu'elle se concentre sur le frontend du site pendant qu'une équipe distincte travaille sur la partie WordPress réelle. .

Cependant, si vous êtes plutôt un pigiste solo ou si vous n'avez pas beaucoup d'expérience dans les systèmes plus distribués, le contrôle de version, le déploiement, etc., il peut être judicieux de vous en tenir à une configuration WordPress plus traditionnelle.

Headless WordPress peut être un paradigme puissant qui vous permet de tirer parti des technologies modernes et de combler le fossé entre une expérience éditoriale que les créateurs de contenu connaissent bien, tout en pouvant utiliser des technologies plus récentes qui ne sont pas encore arrivées dans l'écosystème WordPress.

Et au fur et à mesure que les outils de développement autour de WordPress sans tête continuent de s'améliorer avec un hébergement spécifique sans tête et d'autres outils conçus pour faciliter le développement dans une configuration sans tête, il ne fera que devenir plus accessible pour davantage de développeurs et de marques.

En bref, WordPress sans tête est là pour rester et, s'il est utilisé correctement, peut être un excellent outil dans votre boîte à outils lors de la création de votre prochain site WordPress.