Depuis plus de 10 ans, j’ai utilisé ACF pour gérer les champs personnalisés dans mes projets WordPress. Mais avec l’arrivée de Gutenberg, du Full Site Editing et de nouveaux besoins techniques, il est temps pour moi de tourner la page. Je vous explique pourquoi je bascule vers CMB2 et ce que ça change dans ma façon de travailler.
Pourquoi ce changement ?
En 2010, pour afficher les post meta, je faisais encore mes meta box à la main.
En retombant sur un article de Justin Tadlock (2011), j’ai réalisé le chemin parcouru.
Dès 2011, je suis passé sur WPAlchemy — WordPress Meta Box PHP Class (par Dimas).
Puis est arrivé ACF.
C’est Amaury qui m’en a parlé en premier, et c’est vite devenu mon outil central :
- Créer des métas pour des contenus sur mesure
- Construire des répéteurs et des flexibles pour imaginer des pages uniques
À l’époque, j’ai toujours préféré ça à Visual Composer et aux autres constructeurs.
Les limites rencontrées avec ACF
Sur un gros projet WordPress, j’ai pris conscience de deux limites :
- toutes les metas s’enregistrent, remplies ou pas
- tout est doublé (et ça, je le savais depuis longtemps)
Résultat : 45 000 entrées × 40 metas doublées = explosion des données.
Autre situation : un client voulait un projet sans dépendance ACF.
Oui, on peut embarquer ACF, mais ce n’est pas pensé pour ça. Et avec la version gratuite, les limites deviennent vite un mur.
La découverte de CMB2
Grâce à une vidéo de Brian Coords, j’ai redécouvert CMB2.
Quelques points forts qui m’ont convaincu :
- soutenu par de nombreux développeurs très talentueux
- projet mature et stable
- intégrable partout
- tout généré en code (gain de vitesse énorme)
- personnalisation infinie
- tous les champs nécessaires déjà là
- surtout : ça repose sur les fonctions natives de WordPress (pas de surcouche comme ACF)
Pourquoi je bascule sur CMB2
Aujourd’hui, avec mes projets 100% Gutenberg + React, ACF n’a plus vraiment sa place.
Je base désormais mes projets sur CMB2.
Article publié initialement sur LinkedIn