¿Dónde conviene centralizar la validación de settings?

La validación en servidor dentro de Settings API garantiza consistencia y seguridad.

¿Qué ventaja tiene guardar opciones en un array único (`wpac_settings`)?

Agrupar opciones relacionadas simplifica evolución del plugin y control de versiones de configuración.

Settings API en serio: una pantalla de ajustes clara, segura y mantenible

Construyes la página de configuración de tu plugin con Settings API, validación centralizada y una UX de admin pensada para evitar errores operativos.

¿Cuánto sabes de WordPress Plugin?

📘 Teoría

Arquitectura recomendada para ajustes

Separar render y sanitización evita mezclar HTML con reglas de negocio.

Mantén una clase `SettingsService` responsable de registrar sección, campos y callback de sanitización.

El callback `sanitize_callback` debe ser la puerta de entrada única para validar todo el payload.

Caso real: cuando la validación está repartida por campos sueltos, aparecen inconsistencias y datos inválidos en base de datos.

Una clase para registrar ajustes.
Una función para sanitizar payload completo.
Campos con copy claro y ayudas contextuales.

Registro de opciones con Settings API

No guardes opciones "a mano" si WordPress ya te da un flujo robusto.

Registra el grupo y la opción con `register_setting`, indicando una función de sanitización robusta.

Declara sección con `add_settings_section` y campos con `add_settings_field`, cada uno con su callback de render.

Usa un array de opciones (ej. `wpac_settings`) para mantener coherencia y facilitar migraciones futuras.

Registro base de Settings API

add_action('admin_init', function (): void {
    register_setting('wpac_group', 'wpac_settings', [
        'sanitize_callback' => 'wpac_sanitize_settings',
        'default' => [
            'message' => 'Aviso inicial',
            'tone' => 'info',
        ],
    ]);

    add_settings_section('wpac_main', 'Ajustes principales', '__return_false', 'wpac');

    add_settings_field('message', 'Mensaje', 'wpac_render_message_field', 'wpac', 'wpac_main');
    add_settings_field('tone', 'Tono', 'wpac_render_tone_field', 'wpac', 'wpac_main');
});

UX en admin: menos fricción, menos tickets

La calidad de la interfaz de ajustes impacta directamente en errores de operación.

Añade textos de ayuda concretos debajo de cada campo (qué cambia exactamente y dónde se verá en frontend).

Usa valores por defecto razonables para que el plugin funcione desde el minuto uno, sin exigir configuración compleja.

Muestra mensajes de éxito/error tras guardar para que el usuario entienda qué pasó.

Antipatrón

Panel con campos ambiguos y sin validación visible.

Configuraciones inconsistentes.
Errores repetidos por parte del equipo.
Más soporte interno.

Patrón recomendado

Campos claros + ayudas + validación con feedback.

Menos errores de guardado.
Más autonomía editorial.
Flujo admin más rápido.

Caso real: string vacío que rompía aviso legal

Sin sanitización centralizada, una opción vacía puede romper una sección crítica del sitio.

En un proyecto real, el mensaje legal del footer se guardó vacío por un campo sin validación. Resultado: incumplimiento temporal de política interna.

La solución fue validar en `sanitize_callback` que el mensaje no quedara vacío y aplicar fallback.

Además, se añadió un aviso de admin que explicaba por qué se aplicó valor por defecto.

1 Arquitectura recomendada para ajustes 2 Registro de opciones con Settings API 3 UX en admin: menos fricción, menos tickets 4 Caso real: string vacío que rompía aviso legal

🧪 Aprende probando

Ejemplo Ejemplo guiado: página de ajustes con validación centralizada Registramos opción array, dos campos y una sanitización única para mantener consistencia.

⌄