Advanced Custom Fields s’est imposé comme un standard de fait dans l’écosystème WordPress pour ajouter des champs personnalisés. Mais cette extension, aussi pratique soit-elle, n’est pas toujours nécessaire : l’API native de WordPress, avec register_meta() et les métaboxes classiques, couvre très bien des besoins simples, sans dépendance externe ni poids supplémentaire sur l’administration.
Cet article compare les deux approches sur des critères concrets, pour aider à trancher selon le contexte réel d’un projet plutôt que par habitude.
Déclarer un champ avec l’API native
La fonction register_meta() enregistre un champ personnalisé de façon structurée, avec un type de donnée défini et, si besoin, une exposition automatique dans l’API REST :
add_action( 'init', function() {
register_meta( 'post', 'reference_produit', array(
'type' => 'string',
'single' => true,
'show_in_rest' => true,
'sanitize_callback' => 'sanitize_text_field',
'auth_callback' => function() {
return current_user_can( 'edit_posts' );
},
) );
} );Cette déclaration seule ne crée aucune interface dans l’administration : elle ne fait qu’enregistrer proprement le champ auprès de WordPress. Pour l’éditeur classique, une métabox reste nécessaire pour permettre sa saisie visuelle.
Ajouter une métabox pour la saisie
add_action( 'add_meta_boxes', function() {
add_meta_box(
'reference_produit_box',
'Référence produit',
'afficher_champ_reference',
'produit'
);
} );
function afficher_champ_reference( $post ) {
$valeur = get_post_meta( $post->ID, 'reference_produit', true );
wp_nonce_field( 'sauvegarde_reference', 'reference_nonce' );
printf(
'<input type="text" name="reference_produit" value="%s" class="widefat" />',
esc_attr( $valeur )
);
}
add_action( 'save_post', function( $post_id ) {
if ( ! isset( $_POST['reference_nonce'] ) || ! wp_verify_nonce( $_POST['reference_nonce'], 'sauvegarde_reference' ) ) {
return;
}
if ( isset( $_POST['reference_produit'] ) ) {
update_post_meta( $post_id, 'reference_produit', sanitize_text_field( $_POST['reference_produit'] ) );
}
} );Cette approche demande davantage de code qu’ACF pour un champ simple, mais reste totalement transparente : aucune dépendance, aucune structure de données propriétaire à maintenir, un contrôle total sur chaque étape.
Ce qu’ACF apporte concrètement
Advanced Custom Fields prend tout son sens dès que les besoins se complexifient : des champs répétables, des groupes de champs conditionnels (affichés seulement si une autre valeur est cochée), des relations entre contenus, ou une galerie d’images dédiée. Recréer ces comportements avec l’API native demande un volume de code bien plus important, avec un risque d’erreur plus élevé.
L’interface visuelle de configuration des groupes de champs est aussi un vrai atout pour une équipe qui doit itérer rapidement sur la structure des contenus sans repasser systématiquement par un développeur.
Tableau comparatif
| Critère | API native (register_meta) | Advanced Custom Fields |
|---|---|---|
| Dépendance externe | Aucune | Une extension à maintenir |
| Champ simple (texte, nombre) | Rapide à mettre en place | Rapide, avec interface visuelle |
| Champs répétables ou conditionnels | Développement conséquent | Natif et bien documenté |
| Autonomie de l’équipe éditoriale | Limitée sans interface dédiée | Bonne, via l’interface de configuration |
| Exposition API REST | Native avec show_in_rest | Nécessite un réglage ou du code additionnel |
| Portabilité entre projets | Totale, code source uniquement | Dépend de la présence de l’extension |
Un critère souvent négligé : l’exposition en API REST
Sur un projet headless ou consommant l’API REST de WordPress depuis un frontend séparé, l’API native a un avantage réel : register_meta() avec show_in_rest à true expose le champ automatiquement, sans configuration supplémentaire. Avec ACF, cette exposition demande un réglage explicite ou un filtre dédié pour apparaître correctement dans les réponses de l’API.
Comment trancher en pratique
- Un ou deux champs simples, sur un projet sans dépendance à ajouter : l’API native suffit largement
- Une structure de champs complexe, avec des répéteurs ou des relations, sur un projet où l’équipe éditoriale doit rester autonome : ACF apporte une vraie valeur
- Un projet déjà équipé d’ACF pour d’autres besoins : rester cohérent avec l’existant plutôt que mélanger les deux approches sans raison
Installer ACF pour un unique champ texte, c’est ajouter une dépendance entière à maintenir pour un besoin que quinze lignes de code natif auraient couvert tout aussi bien.
En résumé
Ni l’API native ni ACF ne sont une solution universellement supérieure : le choix dépend du volume et de la complexité réelle des champs nécessaires, ainsi que de l’autonomie attendue de l’équipe éditoriale. Sur un projet simple, l’API native évite une dépendance pour un gain de temps marginal ; sur un projet aux besoins structurants et évolutifs, ACF reste souvent le choix le plus pragmatique.
