El guardado puede fallar antes de salir del navegador, en una capa de seguridad o proxy, durante la validación PHP o al escribir en MySQL. La interfaz también puede confirmar el cambio mientras una caché persistente sigue sirviendo el valor anterior.
Haz un único cambio controlado y sigue su recorrido. No edites repetidamente contenido real mientras desconozcas el estado final de la base de datos.
Define qué escrituras fallan
Prueba un borrador, un ajuste inofensivo del núcleo y la opción afectada del plugin. Anota URL, rol, hora, mensaje del navegador y respuesta HTTP.
Compara:
petición REST del editor de bloques
POST clásico o administrativo
petición admin-ajax
escritura de metadatos de medios
escritura programada o en segundo planoUsa un borrador controlado y no expongas contenido sin publicar en los registros.
Inspecciona la petición del navegador
Abre la pestaña Red y envía una sola vez. Si la petición no sale, puede existir un error JavaScript o de validación. Un 403 apunta a nonce, permisos o cortafuegos; un 500, a PHP; una respuesta JSON puede identificar validación o base de datos.
Lee el cuerpo sin publicar nonces, cookies ni valores del formulario. Empieza por el primer error de la consola.
No desactives la seguridad del navegador ni todos los plugins solo para activar el botón.
Comprueba permisos y nonces
Confirma que el usuario tiene la capacidad requerida para el tipo de entrada o página de ajustes. Los editores de roles y plugins de membresía pueden cambiar capacidades.
Las cookies y nonces caducan; inicia sesión de nuevo en un entorno limpio. Si el fallo vuelve enseguida, revisa dominio canónico, HTTPS y caché en vez de ampliar su duración.
No omitas current_user_can() ni la verificación de nonces en producción.
Relaciona registros PHP y MySQL
Busca la misma hora en WordPress, PHP y MySQL. Revisa tabla o disco lleno, deadlock, modo de solo lectura, columna ausente o error fatal dentro de un hook de guardado.
La validación propia puede rechazar el valor intencionadamente. Un error explicativo no es igual que una escritura fallida.
Protege los registros: las opciones pueden contener claves API o datos personales.
Revisa estados de solo lectura y bloqueos
Una base gestionada puede entrar en solo lectura durante failover, promoción de réplica o protección del almacenamiento. Confirma que WordPress conecta con el primario escribible.
Examina esperas y deadlocks de InnoDB. Una petición puede revertirse aunque la conexión siga sana. Identifica la importación, copia o transacción competidora y mantén cortos los hooks propios para no retener bloqueos durante llamadas remotas.
Verifica la escritura directamente
Después de hacer copia, lee la entrada u opción mediante la API de WordPress o una consulta exacta de solo lectura. No tomes como autoridad lo mostrado en pantalla.
$value = get_option( 'example_option', null );
error_log( 'Option type: ' . gettype( $value ) );Registra tipo o presencia, no el valor secreto. Retira el diagnóstico.
Comprueba caché de objetos y página
Una caché persistente puede devolver opciones antiguas después de escribir, especialmente si varias webs comparten un prefijo incorrecto. Vacía únicamente la caché pertinente mediante controles compatibles.
Compara lectura directa y API de WordPress en staging. Confirma que todos los nodos usan Redis o Memcached de forma coherente.
La administración y REST no deben quedar en una caché pública de página.
Revisa hooks de guardado y esquema
Los plugins pueden interceptar save_post, callbacks REST o saneamiento de opciones. Un callback puede recurrir, provocar un error fatal o devolver el valor anterior.
Busca en código propio y en la pila PHP. En HPOS o tablas personalizadas, confirma que terminaron las migraciones del esquema.
No edites núcleo ni archivos del proveedor; corrige código mantenido o actualiza el componente.
Repara y verifica persistencia
Corrige el permiso, nonce o dominio, cortafuegos, PHP, MySQL, caché o callback demostrado. Guarda un valor controlado, recarga en otra petición y confirma el dato en la base.
Prueba revisiones, autoguardado, tareas y otro rol. El mantenimiento recurrente debería alertar por errores de escritura y respuestas REST 4xx o 5xx; el cambio está reparado cuando persiste entre cachés, procesos y sesiones.