Sage WordPress : comprendre le thème de départ de Roots

Sage est un thème de départ pour WordPress, développé par Roots, l’organisation à qui l’on doit aussi Bedrock. Il ne se voit pas : aucun visiteur ne sait qu’un site repose dessus. Il change en revanche la façon dont le thème est écrit, compilé et maintenu. Voici ce qu’il contient, ce qu’il apporte au développeur et au client, ses limites, et la façon dont je m’en sers sur mes projets WordPress.

Sage WordPress : un thème de départ, pas un thème prêt à l’emploi

Un thème de départ, ou « starter theme », ne fournit aucun design. Vous ne l’installez pas pour obtenir un site : le développeur part de lui pour écrire un thème sur mesure. Sage apporte l’ossature et l’outillage, le reste se construit à partir des maquettes.

Sage 11, la version actuelle, réunit quatre briques :

• Blade, le moteur de gabarits du framework PHP Laravel, à la place des fichiers PHP classiques d’un thème WordPress ;
• Acorn, la bibliothèque de Roots qui apporte à WordPress des fonctionnalités de Laravel ;
• Vite, qui compile le CSS et le JavaScript et applique les modifications à chaud dans le navigateur pendant le développement ;
• Tailwind CSS, fourni par défaut et remplaçable par une autre approche CSS.

Sage 10 compilait ses fichiers avec Bud, Sage 11 est passé à Vite. Si un tutoriel parle de Bud, il décrit la version précédente.

Ce que Sage change pour le développeur WordPress

Dans un thème classique, la logique finit dans un fichier functions.php qui grossit avec le projet, et les gabarits mêlent requêtes et HTML. Sage sépare les rôles :

• app/ contient le code PHP : fournisseurs de services, « View Composers », filtres et initialisation du thème, chargés automatiquement selon la convention PSR-4 ;
• resources/views/ contient les gabarits Blade : mises en page, composants et fragments réutilisables ;
• resources/css/ et resources/js/ contiennent les sources, pour le site comme pour l’éditeur de blocs ;
• public/ reçoit les fichiers compilés, que l’on ne modifie jamais à la main.

Le fichier functions.php existe toujours, mais il se limite à démarrer Acorn. Les « View Composers » préparent les données d’une vue en dehors de celle-ci : le gabarit ne fait plus qu’afficher. Pour qui connaît l’architecture MVC, le terrain est familier.

Sage prépare aussi le terrain pour l’éditeur de blocs. À chaque compilation, un fichier theme.json est généré à partir de la configuration Tailwind CSS : les couleurs, les polices et les tailles du site sont proposées dans Gutenberg, sans double saisie.

La contrepartie est une marche à franchir : Composer, Node.js, la ligne de commande et la syntaxe Blade. Un thème Sage ne s’affiche pas tant que ses fichiers n’ont pas été compilés.

Ce que Sage change pour le client

Rien dans l’administration : vous gérez vos contenus dans WordPress comme sur n’importe quel site, avec l’éditeur Gutenberg et les blocs prévus pour vous. Les effets sont indirects.

• Un thème qui ne contient que votre site. Pas d’options ni de fonctionnalités embarquées « au cas où », comme dans un thème du commerce.
• Un code qu’un autre développeur peut reprendre. La structure est conventionnelle et documentée par Roots : un développeur qui connaît Sage sait où chercher, sans dépendre de mes habitudes.
• Des évolutions plus simples. Un composant Blade ou un bloc se modifie à un seul endroit.

Un point à connaître avant de vous engager : la mise à jour de Sage lui-même, comme celle de Bedrock, ne relève pas de la maintenance courante. Dans mon contrat de maintenance, elle fait l’objet d’un devis séparé, parce qu’elle peut demander des modifications de code.

Sage et Bedrock : qui fait quoi

Les deux outils viennent de Roots et se complètent, sans se recouvrir.

• Bedrock organise le projet WordPress entier : le cœur de WordPress et les extensions gérés comme des dépendances Composer, la configuration par environnement dans un fichier .env et une racine web isolée du reste du projet.
• Sage ne s’occupe que du thème, rangé dans le dossier des thèmes de Bedrock.

Sage s’installe aussi sur un WordPress classique : Bedrock n’est pas obligatoire. Mais les deux reposent sur Composer et sur la même façon de travailler, avec un code versionné et des environnements séparés. En pratique, je les utilise ensemble. Je détaille le premier dans mon article sur Bedrock et l’architecture moderne de WordPress.

Quand il vaut mieux ne pas utiliser Sage

Sage n’est pas la bonne réponse à tous les projets. Voici quatre situations où un autre choix est plus raisonnable.

• Un tout petit site sans évolution prévue. Un blog personnel ou une page unique n’ont pas besoin de cet outillage.
• Un site monté avec un constructeur de pages. Si vous tenez à Elementor ou à Divi pour composer vos pages vous-même, Sage n’apporte rien : son intérêt est un thème écrit en code.
• Une équipe qui ne pratique ni Composer ni la ligne de commande. Si le site doit être repris par un intégrateur habitué aux thèmes classiques, un thème sur mesure classique, bien structuré, sera plus simple à faire vivre.
• Un hébergement sans accès SSH ni déploiement automatisé. Le thème doit être compilé et ses dépendances installées avant la mise en ligne. Sans outil pour le faire, chaque mise à jour devient une manipulation manuelle.

Un dernier piège concerne les projets qui adoptent Sage à moitié. Un fichier header.php classique posé à côté des mises en page Blade finit toujours en désordre : si vous choisissez Sage, suivez sa logique jusqu’au bout.

Comment j’utilise Sage sur mes projets WordPress

J’associe Bedrock et Sage sur la majorité de mes projets. Le site que vous lisez tourne sur Sage 11, avec Vite, Blade et Acorn. Ma méthode tient en trois principes.

• Un bloc, un module. Chaque bloc Gutenberg créé avec ACF Pro a son gabarit Blade dans resources/views/blocks/, sa feuille de style et, si besoin, son fichier JavaScript. Seuls les fichiers des blocs présents sur la page sont chargés.
• Un CSS écrit pour le projet. Du CSS sur mesure en méthode BEM quand le projet le permet, Tailwind CSS quand le budget impose d’aller plus vite. J’explique ce choix dans mon article sur Tailwind CSS et WordPress.
• Un code versionné et déployé automatiquement. Git et un déploiement continu, sans transfert de fichiers à la main.

C’est avec cette base que j’ai créé des sites WordPress sur mesure pour le Groupe Webedia, avec une intégration HTML et SCSS en Blade et un déploiement par GitLab CI/CD.

Le point de départ reste le même : des maquettes Figma ou équivalent et un cahier des charges. Je suis développeur, pas designer. Sage me sert à traduire ces maquettes en gabarits, ce qui est l’objet de ma prestation d’intégration web, et à livrer un site complet dans le cadre d’une création de site WordPress. La méthode pas à pas est décrite dans mon guide pour créer un thème WordPress sur mesure.

Où j’interviens

Basé près de Lille, j’interviens à distance partout en France et à l’international, et sur place à Lille et dans les Hauts-de-France. Vous avez un site WordPress sur mesure à développer, ou un thème Sage existant à faire évoluer ? Décrivez-moi votre projet : maquettes disponibles, échéance et budget envisagé.