Ya he publicado una noticia de prueba y ha vuelto a dar el validation_failed. Lee ahora el log de diagnóstico que genera tu mu-plugin y dime qué campo(s) concreto(s) llegaron vacíos con required=SI. Ese es el campo que dispara el fallo.

a encontrado otra confirmación importante: el fields=false de la URL no significa nada — es un bug/limitación de esta versión de JFB, que lanza el validation_failed sin pasar el array de errores calculado. Por eso era literalmente imposible ver el campo culpable desde el navegador. Confirma que no era cosa tuya: la información no estaba disponible ahí.

Está creando el snippet como un mu-plugin (~/web/…/wp-content/mu-plugins/lynx-jfb-diagnostic-log.php) enganchado al hook real jet-form-builder/validate-field, que sí se dispara por cada campo. Esto es un enfoque limpio: registrará en el log qué campo está required, si llega vacío, su valor y sus errores. Cuando publiques una noticia, el log te dirá exactamente qué campo dispara el fallo.

Un detalle técnico que vale la pena que sepas: lo está poniendo en mu-plugins (must-use plugins), no en Code Snippets. Eso es buena idea para un diagnóstico — es un archivo aparte, fácil de borrar después, y no toca tu configuración de Code Snippets. Cuando termine el diagnóstico, ese archivo se borra y listo.

Este comando es una edición de archivo (crea/modifica el mu-plugin de diagnóstico). Como es un archivo de diagnóstico nuevo y aislado que solo escribe en un log (no toca el formulario, ni la BD, ni nada del sitio), es seguro aprobarlo. Solo observa y registra.

Apruébalo. Luego Claude Code te dirá que publiques una noticia para capturar el envío. Cuando lo hagas:

Crea una noticia nueva, rellénala entera (todos los campos, para que el log capture el estado real).
Publícala (fallará, como siempre).
Claude Code leerá el log y te dirá qué campo exacto llegó vacío y disparó el validation_failed.
Ese será el momento de la verdad: el nombre del campo culpable, por fin, con certeza.

Apruébalo, publica una noticia de prueba cuando te lo pida, y cuéntame qué campo aparece en el log. Mi apuesta sigue siendo subtítulo, contenido o fecha — uno de los tres que tu JS no validaba. Con ese dato, el arreglo final es trivial. Vas a cerrarlo ya.
ha dado el mismo error al publicar, que le digo a Code
 
No hace falta que le digas nada especial — el snippet de diagnóstico está precisamente para eso: que aunque el error siga saliendo (que saldrá, no lo hemos arreglado aún), quede registrado en el log qué campo lo causó. El error al publicar es lo esperado; lo que importa ahora es leer el log.

Dile a Claude Code exactamente esto:

 
Ya he publicado una noticia de prueba y ha vuelto a dar el validation_failed. Lee ahora el log de diagnóstico que genera tu mu-plugin y dime qué campo(s) concreto(s) llegaron vacíos con required=SI. Ese es el campo que dispara el fallo.
Con eso, Claude Code irá a leer el archivo de log que su snippet acaba de escribir y te dirá el campo culpable con nombre y apellidos.

Un detalle por si acaso: pregúntale también dónde está guardando el log, por si quieres verlo tú mismo. Normalmente será algo como wp-content/debug.log o un archivo propio tipo lynx-jfb-diag.log. Si Claude Code no encuentra nada en el log, puede ser que el snippet necesite un ajuste (a veces el hook no captura a la primera), y él mismo lo corregirá.

Pásale ese mensaje y deja que lea el log. Cuando te diga el campo que falló, cuéntamelo — ahí tendremos por fin la certeza absoluta de cuál es, y el arreglo definitivo (ajustar la lista SIEMPRE_REQUERIDOS del JS o la config de obligatorios en JFB) será cosa de un momento.
 
 
 
 
 
 
¿Quieres recibir una notific