Mon starter kit WordPress (un thème FSE sur Bedrock et un ensemble de mu-plugins maison) a beaucoup changé ces dernières semaines : passage d’ACF Pro à Modern Fields Pro (par Maxime Bernard-Jacquet), découpage en paquets Composer indépendants, et un premier site multisite migré avec succès. Voici le retour d’expérience.
Pourquoi passer à Modern Fields
ACF Pro reste un outil solide, largement adopté et bien documenté. Le choix de migrer ne vient pas de ses défauts, mais de ce que Modern Fields apporte dans un thème FSE.
Avec Modern Fields, le formulaire d’un groupe de champs est construit avec des blocs. Dans mon kit, chaque groupe est donc décrit en simple balisage de blocs, comme un pattern : un bloc copié depuis l’éditeur de groupes se colle tel quel dans le fichier, sans syntaxe intermédiaire. N’importe quel bloc FSE peut servir dans un groupe, et les mêmes réglages (espacements, mise en page) s’y appliquent.
C’est la continuité du reste de la stack FSE : moins de concepts à maîtriser pour intervenir sur un projet.
Comment le starter kit est organisé
Un dossier par groupe
Chaque groupe de champs a son dossier : sa déclaration, son contexte PHP (les valeurs dynamiques, les choix d’une liste) et son balisage de blocs. Les groupes d’un bloc vivent avec le bloc, les autres dans la configuration du thème :
config/
├── default/mf/ ← groupes fournis par le kit
│ └── <groupe>/
│ ├── group.php ← déclaration (emplacement, titre)
│ ├── context.php ← valeurs dynamiques, choix
│ └── fields.twig ← balisage de blocs du formulaire
└── customer/mf/ ← surcharges du projet client
blocks/
└── <bloc>/
├── block.json
└── mf/<groupe>/ ← groupes propres au blocLa configuration par défaut est surchargeable par projet : un site client modifie, étend ou désactive un groupe dans son propre dossier, sans toucher au socle commun.
Une synchronisation maîtrisée
Les fichiers sont compilés puis synchronisés avec Modern Fields depuis l’administration ou en ligne de commande, et automatiquement à chaque déploiement. Jamais pendant une visite : la synchronisation est une opération de déploiement, pas l’effet de bord d’une requête. Écrire en base au chargement d’une page coûterait en performance et en cohérence.
Une couche d’accès aux champs commune
Le thème ne lit jamais les champs directement avec les fonctions de Modern Fields ou d’ACF Pro : il passe par une couche commune. Le même thème tourne ainsi avec l’un ou l’autre plugin, sans modifier les templates, et les groupes restent déclarés une seule fois. Côté visiteur, rien ne change : le HTML est identique, sans CSS supplémentaire.
L’atomisation en paquets Composer
Le starter kit était un seul dépôt : thème et mu-plugins ensemble. Chaque site en gardait sa copie, et un correctif devait être reporté à la main de projet en projet, ou bien les projets divergeaient.
Le thème et neuf mu-plugins sont désormais des paquets Composer indépendants, chacun dans son dépôt, versionnés par tag et publiés automatiquement par la CI dans un registre privé. Les mu-plugins couvrent des responsabilités distinctes : utilitaires partagés, boîte à outils, formulaires, multilingue, cache de pages, sécurité, multisite, et quelques autres.
Un site déclare les briques dont il a besoin dans son composer.json et les met à jour comme n’importe quelle dépendance. Un correctif est publié une fois, et chaque site le récupère à sa prochaine mise à jour. Le composer.lock, versionné avec le projet, dit exactement quelle version tourne où.
Le test grandeur nature : un multisite associatif
La validation s’est faite sur un multisite existant de trois sites, construit sur l’ancienne version du kit avec ACF Pro. C’est un bon banc d’essai : plusieurs sites, beaucoup de blocs à champs, et un client qui y travaille au quotidien.
Un script de migration convertit les données : le thème devient un thème enfant du kit, et les valeurs des anciens champs ACF sont reprises dans les nouveaux groupes. Il a été rejoué en local jusqu’à un résultat stable, puis appliqué en préproduction. Les pages ont été comparées une à une : même texte avant et après.
Un bonus au passage : sans clé d’API Google, Modern Fields affiche les cartes avec OpenStreetMap. Pas de clé à gérer, pas de dépendance à un service payant.
La migration s’est conclue sans régression visible. Les trois sites tournent sur le nouveau kit en préproduction, où le client poursuit la saisie de ses contenus avant la mise en ligne.
Ce que ça change au quotidien
Les améliorations se propagent autrement. Corriger un mu-plugin ne veut plus dire le reporter dans chaque projet : la correction est publiée une fois, et chaque site la récupère à sa prochaine mise à jour.
Côté champs, composer un groupe directement avec des blocs, puis le coller dans un fichier versionné, est plus fluide qu’une interface séparée. Pour quelqu’un déjà à l’aise avec l’éditeur FSE, la prise en main est rapide.
Le starter kit est désormais un socle commun maintenu à un seul endroit, versionné, installable sur n’importe quel projet Bedrock, et qui ne dépend plus d’un seul plugin de champs.
Vous travaillez sur un thème FSE sur mesure ou vous envisagez de migrer un projet depuis ACF Pro ? Parlons-en : contact@juzed.dev.
Stack : WordPress FSE · Bedrock · Modern Fields Pro · Twig · Composer · GitLab CI/CD · DDEV · OpenStreetMap