Plutôt que de coder à la main un formulaire, sa validation, sa sécurisation par nonce et sa sauvegarde en base, WordPress fournit un jeu de fonctions standard qui, assemblées correctement, produisent un écran cohérent avec le reste de l’administration : mêmes styles, mêmes messages de confirmation, même comportement clavier.
Les briques de l’API des réglages
Tout commence par register_setting( $groupe, $nom_option ), qui déclare l’option et, si besoin, une fonction de nettoyage via l’argument sanitize_callback. Vient ensuite add_settings_section() pour regrouper des champs sous un même titre, puis add_settings_field() pour chaque champ individuel. Le formulaire lui-même est rendu par les fonctions settings_fields( $groupe ) et do_settings_sections( $page ), encadrées d’un simple <form method="post" action="options.php">.
Exemple minimal
<?php
add_action( 'admin_init', function () {
register_setting( 'mon_groupe', 'ma_cle_api' );
add_settings_field(
'ma_cle_api', 'Clé API',
function () {
echo '<input type="text" name="ma_cle_api" value="' .
esc_attr( get_option( 'ma_cle_api' ) ) . '">';
},
'ma-page', 'section_generale'
);
} );
Pièges fréquents
- Oublier
settings_fields()supprime le nonce et la vérification de sécurité : la sauvegarde échoue silencieusement. - Un écran de réglages doit être rattaché à un menu via
add_options_page()ou équivalent, sinon il reste accessible uniquement par URL directe. - Ne réinventez pas ce mécanisme avec un formulaire artisanal enregistrant directement
$_POSTdansupdate_option(): vous perdez la validation, l’échappement et la compatibilité avec les futurs outils d’export de réglages.