Pourquoi j'ai migré mon site de WordPress vers Statamic

J'ai migré ce site de WordPress vers Statamic après cinq ans, et la raison tient en une image. Personnaliser WordPress, c'est comme opérer un patient : chaque modification oblige à inciser quelque chose qui n'a jamais été conçu pour être ouvert, puis à recoudre en espérant que rien ne réagisse. Personnaliser Statamic, c'est comme avoir une fermeture éclair sur ce même corps. On l'ouvre, on change ce qu'il faut, on la referme, et elle s'ouvre de la même façon la fois suivante.

Cet article s'adresse aux développeurs Laravel qui choisissent un CMS pour leur propre site ou pour celui d'un client. Si vous n'avez jamais ouvert un éditeur de code, c'est la partie sur les cas où WordPress reste le bon choix qui vous concerne.

Pourquoi personnaliser WordPress ressemble à de la chirurgie

WordPress est un moteur de blog qui s'est étendu à tout le reste, et il s'est étendu par l'extérieur. Un champ personnalisé, un nouveau type de contenu, un cache, un menu d'administration réorganisé : rien de tout cela n'est le travail de la plateforme. Chaque besoin arrive donc sous forme d'extension écrite par une équipe différente, ou de code ajouté au functions.php d'un thème et accroché au cycle de vie de quelqu'un d'autre.

Chacune de ces modifications est une incision. Le site fonctionne, mais il tient grâce à des points de suture que vous n'avez pas tous faits vous-même, et chaque mise à jour du cœur, du thème ou d'une extension est une occasion pour l'un d'eux de lâcher. Mon propre site était réalisé avec Divi, et le problème n'a jamais été l'apparence des pages. C'est que chaque modification que je voulais vraiment se trouvait sous l'éditeur de pages, là où il n'a pas été conçu pour me laisser entrer.

Statamic a intégré les extensions de WordPress dans une seule plateforme

La première chose que j'ai remarquée dans Statamic, c'est le nombre d'extensions de mon ancienne liste dont je n'avais plus besoin, parce que leur fonction était déjà là. On dirait que quelqu'un a pris chaque pièce sur mesure qu'un site WordPress sérieux finit par accumuler, et l'a intégrée dans un seul produit, avec un seul back-office.

Les champs personnalisés. Sous WordPress, ils viennent d'une extension comme ACF, avec ses propres groupes de champs, ses propres écrans et ses propres règles de stockage. Dans Statamic, ils sont au cœur du produit : chaque type d'entrée a un blueprint, la liste des champs qu'il possède réellement, choisis parmi plus de 40 types de champs. Vous le composez dans le back-office ou l'écrivez en YAML, et dans les deux cas c'est un fichier dans votre dépôt.

Le cache. WordPress a besoin d'une extension de cache, avec sa propre page de réglages et ses propres règles de purge. Statamic intègre un cache statique : activez-le dans un fichier de configuration et les pages sont livrées en HTML statique. Enregistrer une entrée vide le cache de sa page, et quelques lignes de configuration indiquent quelles pages de liste vider en même temps.

Le menu d'administration. Réorganiser, renommer ou masquer des éléments du menu d'administration de WordPress, c'est encore une extension. Dans Statamic, c'est un réglage dans les préférences du back-office lui-même.

Un seul style pour tous les écrans. C'est ce qui m'a le plus marqué. Chaque extension WordPress apporte son propre écran d'administration, son propre vocabulaire, ses propres bannières et sa propre idée de l'endroit où ranger les réglages, si bien que le tableau de bord finit par ressembler à une douzaine de produits qui partagent une barre latérale. Dans Statamic, un addon ou un champ sur mesure utilise les composants du back-office lui-même, et donne l'impression d'avoir toujours été là.

Ajouter une collection sur mesure, un jeu d'enfant

Imaginons que vous vouliez un nouveau type de contenu : des articles, des études de cas, des conférences. Sous WordPress, vous enregistrez un custom post type, en code ou via une énième extension :

add_action('init', function () {
    register_post_type('article', [
        'label' => 'Articles',
        'public' => true,
        'has_archive' => true,
        'rewrite' => ['slug' => 'articles'],
        'supports' => ['title', 'editor', 'thumbnail'],
        'show_in_rest' => true,
    ]);
});

Cela vous donne un titre et un éditeur. Les champs qui font d'un article un article viennent toujours d'une extension de champs personnalisés, ou de meta boxes et d'un traitement d'enregistrement que vous écrivez vous-même, et les templates sont trouvés via la hiérarchie de noms de fichiers de WordPress.

Dans Statamic, la même collection tient dans un court fichier YAML :

title: Articles
template: articles/show
taxonomies:
  - tags
route: '/articles/{{ slug }}'
date: true
sort_dir: desc

Ses champs sont décrits dans un blueprint, juste à côté :

title: Article
tabs:
  main:
    sections:
      -
        fields:
          -
            handle: title
            field:
              type: text
          -
            handle: excerpt
            field:
              type: textarea
          -
            handle: content
            field:
              type: bard

D'ailleurs, les fichiers YAML de la collection et de son blueprint sont créés automatiquement quand vous passez par le back-office : vous n'avez pas à les écrire vous-même.

Ajoutez un template de liste et un template de détail, et c'est terminé. La route, les champs et les templates vivent tous dans des fichiers que vous pouvez lire, comparer et relire dans une pull request. Ce site fait tourner cinq collections de contenu de cette façon (réalisations, articles, blog, médias et produits), chacune avec ses propres champs, et en ajouter une ne prend que quelques minutes.

La mise en forme se travaille comme dans n'importe quelle application Laravel

Un thème WordPress se met en forme à travers un thème parent, un thème enfant, l'outil de personnalisation, le panneau CSS de l'éditeur de pages et, trop souvent, une modification faite directement sur le serveur en production. Savoir lequel l'emporte demande une expérience que vous préféreriez consacrer au site.

Un site Statamic est une application Laravel : le mettre en forme, c'est du développement Laravel. Les templates sont des fichiers dans resources/views, écrits en Antlers ou en Blade, et ce site utilise Tailwind et Vite comme n'importe quel autre projet Laravel. Je modifie un template en local, je vois le résultat immédiatement, je le commite et je déploie. Quand une page a besoin d'une vraie logique, c'est un contrôleur et éventuellement une classe de service, exactement comme partout ailleurs dans Laravel.

Quand WordPress reste le bon choix

WordPress est simple pour quelqu'un qui n'écrit pas de code, et il faut le lui reconnaître. Installez-le, choisissez un thème et commencez à écrire, ou prenez un éditeur de pages et glissez vos sections en place. On trouve un hébergement pour WordPress partout, et à petit prix. Si c'est votre cas, vous n'avez pas besoin de Statamic, et cet article ne prétend pas le contraire.

Mais si vous êtes développeur Laravel et que vous voulez un CMS qui vous donne le sourire chaque fois que vous l'ouvrez pour le personnaliser, plutôt qu'un CMS qui vous donne des maux de tête et vous fait perdre votre temps, Statamic s'impose sans hésiter.

Ce que j'aimerais voir changer chez Statamic : des fonctions Pro vendues à l'unité

Statamic Core est gratuit et couvre l'essentiel de ce dont un site comme celui-ci a besoin. Il a deux limites qui comptent : un seul compte administrateur et un seul formulaire. Tout le reste passe par Statamic Pro qui, au moment où j'écris, coûte 349 $ par site la première année, puis 99 $ par an en option pour les mises à jour. Pro regroupe les utilisateurs illimités avec rôles et permissions, les révisions, les API REST et GraphQL, le multi-site et le multilingue, la marque blanche et l'intégration Git.

C'est ce regroupement qui pose problème à mon avis, parce qu'un vrai projet a rarement besoin de tout :

• Sur un site, j'ai seulement besoin du multilingue.

• Sur un autre, j'ai seulement besoin de plusieurs utilisateurs avec des permissions.

• Sur un autre encore, j'ai seulement besoin de plus d'un formulaire.

À chaque fois, le client paie Pro en entier pour débloquer une seule de ses fonctions, et pour un petit client ce prix peut suffire à faire partir le projet sur autre chose que Statamic.

Statamic vend déjà une fonction payante à l'unité : SEO Pro est un addon séparé, à 75 $ en paiement unique par site. J'aimerais que les fonctions Pro suivent le même modèle : le multilingue, les utilisateurs et permissions, et les formulaires, chacun disponible comme addon à part entière, avec la licence Pro complète réservée aux projets qui utilisent vraiment tout ce qu'elle contient.

Statamic vs WordPress : mon verdict

Après cinq ans sur WordPress, la chirurgie ne me manque pas. Avec Statamic, chaque personnalisation passe par une fermeture prévue pour s'ouvrir, et la refermer ne laisse rien à cicatriser. Si vous êtes développeur Laravel et que vous choisissez un CMS, essayez-le d'abord sur votre propre site : Core est gratuit, et Pro l'est aussi pendant le développement.

L'histoire complète de la refonte, de Divi aux champs et aux fonctionnalités du site aujourd'hui, est dans l'étude de cas de ce site. Et si vous voulez un site Statamic ou Laravel, ou migrer un site WordPress, c'est exactement ce que je propose.