Guía de Solución de Problemas | Field Forge - Campos personalizados, diseñados para la velocidad
Descargar Iniciar sesión

Guía de Solución de Problemas

Esta sección cubre los problemas más comunes que puedes encontrar con Field Forge y cómo resolverlos. Para cada problema, describimos los síntomas, las causas probables y las soluciones paso a paso.

La Ayuda del Tooltip Abre la Página de Inicio en Lugar del Artículo

Síntomas: Al hacer clic en el pequeño icono de ayuda ? en el administrador de Field Forge, se abre la página de inicio de Field Forge o la página de documentación en lugar del artículo específico para esa configuración. Solución: Actualiza Field Forge a la versión actual. Los enlaces de ayuda del administrador ahora dirigen a las URL exactas de la Guía del Usuario o la Guía del Desarrollador. Si una página de administrador en caché aún tiene el enlace antiguo, actualiza la página una vez.

La Desactivación de Forge Suite en un Clon Afecta a Otro Sitio

Síntomas: Clonaste o restauraste un sitio de WordPress, luego hiciste clic en Forge Suite > Desactivar en el clon. Otro sitio que usa la misma licencia parece haber perdido el estado PRO o Connect. Causa: Las versiones anteriores confiaban en el id de instalación de Freemius almacenado en fs_accounts. Una base de datos clonada puede llevar el id de instalación y la URL del sitio original, por lo que incluso una desactivación de Freemius a nivel de instalación puede dirigirse a la instalación remota original. Solución: Actualiza Field Forge a la última versión. Forge Suite ahora compara la URL del sitio de Freemius almacenada con la actual de WordPress site_url() / home_url() antes de cualquier desactivación remota. Si el estado pertenece a otro sitio, omite la llamada remota de Freemius y solo borra el estado de licencia local para la instalación actual de WordPress. Reconecta el clon a través de Field Forge > Licencia > Conectar a Avakode cuando desees que esté licenciado nuevamente.

Los Campos No Se Muestran en el Editor de Publicaciones

Síntomas: Creaste un grupo de campos, pero los campos no aparecen cuando editas una publicación o página. Causas y soluciones posibles:
  1. Las reglas de ubicación no coinciden con la publicación. Abre el grupo de campos y verifica la sección de Reglas de Ubicación. Asegúrate de que las condiciones coincidan con la publicación que estás editando. Por ejemplo, si la regla dice “El Tipo de Publicación es igual a Producto” pero estás editando una Página, los campos no aparecerán.
  2. El grupo de campos está configurado como Inactivo. En la lista de grupos de campos, verifica que la columna Estado muestre “Activo”. Si dice “Inactivo”, abre el grupo de campos y cambia su estado.
  3. Otro plugin está ocultando el metabox. Algunos plugins de creadores de páginas o plugins de limpieza de administración ocultan metaboxes. Verifica las Opciones de Pantalla (esquina superior derecha de la pantalla de edición) y asegúrate de que el metabox de tu grupo de campos esté marcado.
  4. El grupo de campos no tiene campos. Un grupo de campos vacío con cero campos no mostrará un metabox. Abre el grupo de campos y añade al menos un campo.
  5. Problema de caché. Si acabas de crear el grupo de campos, intenta actualizar la página del editor de publicaciones. En algunos entornos de hosting, la caché de objetos puede retrasar la aparición de nuevos metaboxes.

get_field() Devuelve Null

Síntomas: La plantilla de tu tema utiliza get_field('field_name') pero devuelve null o un valor vacío, a pesar de que se ingresaron datos en el editor. Causas y soluciones posibles:
  1. Nombre de campo incorrecto. El nombre pasado a get_field() debe coincidir con el Nombre del campo (slug), no con la Etiqueta. Abre el editor de grupos de campos y verifica la columna Nombre. Por ejemplo, si la etiqueta es “Título Hero” pero el nombre es hero_title, usa get_field('hero_title').
  2. ID de publicación faltante. Si llamas a get_field() fuera del Loop (por ejemplo, en una plantilla de encabezado o pie de página), debes pasar el ID de la publicación explícitamente: get_field('hero_title', $post_id). Sin el segundo parámetro, se predetermina a la publicación actual en el Loop, que puede no existir en tu contexto.
  3. Uso de datos de la página de opciones sin ‘options’. Para los campos de la página de opciones, debes pasar 'options' como segundo parámetro: get_field('site_phone', 'options'). Sin él, Field Forge busca el campo en la publicación actual y no encuentra nada.
  4. Field Forge está desactivado. Si Field Forge no está activo y tu tema no tiene un fallback, get_field() estará indefinido y causará un error fatal (o devolverá null si otro plugin proporciona un stub). Verifica que Field Forge esté activado en Plugins.
  5. Los datos se ingresaron con ACF pero no se migraron. Si los datos fueron guardados originalmente por ACF y no has ejecutado la migración, las tablas de Field Forge estarán vacías. Ve a Field Forge > Migración e importa los valores.
  6. ACF está activo durante una verificación de página de opciones de LangForge. Cuando ACF posee get_field(), Field Forge ahora conecta lecturas de opciones ACF vacías a la misma tabla de opciones de Field Forge consciente del idioma utilizada por la capa de compatibilidad de ACF. Esto está destinado a ventanas de migración/QA donde ACF, Field Forge y LangForge están activos juntos.

Las Ediciones a un Campo Dentro de un Grupo No Se Guardan

Síntomas: Cambias un valor de texto, textarea o WYSIWYG que está dentro de un campo Grupo, haces clic en Actualizar y el valor vuelve al contenido anterior al recargar. Otros campos en la misma publicación se guardan normalmente. Los campos fuera del Grupo se guardan normalmente. Por qué sucede: Esta fue una regresión específica de los Grupos cuyos datos fueron importados de ACF (o migrados de un plugin anterior) y, por lo tanto, se almacenaron jerárquicamente: el grupo en sí ocupa una fila en la tabla de valores de Field Forge y cada subcampo está vinculado por el ID del registro del grupo. Los subcampos del formulario de administración en esa estructura se enviaron bajo una clave POST que el manejador de guardado de Field Forge no leyó, por lo que las ediciones de subcampos se descartaron silenciosamente. Los grupos que nunca fueron tocados por la importación de ACF siguieron funcionando porque usaron la ruta de almacenamiento plana heredada, que el manejador de guardado sí leyó. Lo que hace la versión actual: El manejador de guardado ahora reconoce los subcampos jerárquicos del grupo y los dirige a través del mismo validador + ruta de almacenamiento que cualquier otro campo. La solución cubre texto, textarea, WYSIWYG, número, selección y otros tipos de campo “simples” dentro de Grupos, así como Grupos anidados dentro de Repetidores y diseños de Contenido Flexible. Recuperando ediciones ya perdidas: Las ediciones realizadas antes de la solución nunca se persistieron; no hay registro de ellas para recuperar. Vuelve a ingresar el contenido y haz clic en Actualizar; el valor se guardará correctamente.

Los Valores Acumulan Barras Invertidas en Cada Guardado

Síntomas: Un campo con comillas en su valor (más a menudo un iframe embebido, un bloque WYSIWYG que contiene atributos data-*, o un textarea con HTML sin procesar) comienza a mostrar barras invertidas adicionales cada vez que se guarda la publicación: width="900" se convierte en width=\"900\", luego en width=\\\"900\\\", y así sucesivamente — hasta una docena o más de barras invertidas después de varias rondas de edición. Volver a editar el campo, crear traducciones o usar herramientas de “duplicar publicación” de terceros acelera la acumulación. Por qué sucede: WordPress agrega automáticamente una barra invertida antes de cada comilla en los datos del formulario. El manejador de guardado de Field Forge solía almacenar el valor recibido sin eliminar esas barras añadidas, por lo que cada ronda de guardado preservaba las barras anteriores y añadía una nueva capa encima. Los valores que nunca contenían comillas no se vieron afectados. Lo que hace la versión actual: El manejador de guardado desescapa los datos del formulario entrantes una vez en la parte superior, por lo que el valor almacenado coincide con lo que el usuario realmente escribió. Los guardados futuros ya no añaden barras. Limpiando valores ya corruptos:
  1. Abre cada publicación afectada en el administrador. Si el valor se muestra con barras invertidas visibles antes de las comillas, el contenido almacenado está corrupto.
  2. En el editor de campos, elimina manualmente las barras invertidas y guarda una vez; el valor corregido persistirá en adelante.
  3. Para una reparación masiva en un sitio con muchas filas corruptas, un script de WP-CLI puede iterar stripslashes() sobre los valores en wp_fieldforge_values hasta que el valor se estabilice. Restringe el pase a tipos de campo similares a texto (wysiwyg, textarea, text, url, email) — los identificadores binarios y los valores de color no deben ser tocados. Contacta con soporte si necesitas la consulta exacta.

Migración de ACF Incompleta o Atascada

Síntomas: La barra de progreso de migración se detiene a mitad de camino, o no todas las publicaciones tienen sus datos después de la migración. Causas y soluciones posibles:
  1. Tiempo de espera de PHP. Los sitios grandes pueden alcanzar el límite de tiempo de ejecución de PHP. La migración se ejecuta en lotes de 50 publicaciones para evitar esto, pero los servidores muy lentos pueden seguir agotando el tiempo. Aumenta max_execution_time en tu configuración de PHP (o php.ini) a al menos 300 segundos, luego reinicia la migración.
  2. Límite de memoria. Las publicaciones con muchos campos complejos (repetidores anidados, galerías grandes) pueden consumir una cantidad significativa de memoria. Aumenta memory_limit a al menos 256M en tu configuración de PHP.
  3. ACF fue desactivado antes de que la migración se completara. ACF debe permanecer activo durante todo el proceso de migración porque Field Forge lee datos a través de las funciones de ACF. Reactiva ACF y reinicia la migración.
  4. El procesamiento en segundo plano falló silenciosamente. Verifica la página de estado de migración de Field Forge para mensajes de error. Si el proceso en segundo plano fue interrumpido (reinicio del servidor, mantenimiento de hosting), haz clic en “Reanudar Migración” para continuar desde donde se detuvo.
  5. Se espera migración parcial en Free. La versión gratuita solo migra definiciones de grupos de campos, no valores de campo. Si tus publicaciones tienen los campos correctos pero no datos, actualiza a PRO para migrar valores.
  6. Desajuste de arranque de QA local. En sitios locales de QA de Forge que definen FORGE_SKIP_LICENSE_REVALIDATION, ya sea forge_e2e_plan=pro o un registro de licencia local válido fieldforge_license_data['plan']='pro' desbloquea la migración de valores. La misma constante local también pone a Freemius en modo anónimo para las solicitudes de administración de Field Forge, por lo que un nuevo sitio de QA no debería estar bloqueado por la pantalla de opt-in de Freemius antes de abrir las páginas de Field Forge.

JSON Local No Sincroniza

Síntomas: Tú o tu desarrollador hicieron cambios en archivos JSON, pero los grupos de campos en la base de datos no se actualizan. Causas y soluciones posibles:
  1. JSON local no está habilitado. Ve a Field Forge > Configuración y verifica que la Sincronización de JSON Local esté activada.
  2. Ruta de directorio incorrecta. Field Forge busca archivos JSON en la carpeta fieldforge-json/ dentro de tu tema activo (o la ruta personalizada si está configurada). Verifica que la carpeta exista y contenga archivos .json. La ruta es sensible a mayúsculas y minúsculas.
  3. Permisos de archivo. El servidor web necesita acceso de lectura al directorio JSON. En la mayoría de los hosts, los permisos de 755 para la carpeta y 644 para los archivos son correctos.
  4. Notificación de sincronización desestimada. Cuando Field Forge detecta archivos JSON actualizados, muestra una notificación de sincronización en el administrador. Si alguien desestimó la notificación sin hacer clic en Sincronizar, los cambios no se aplicaron. Ve a Field Forge > Grupos de Campos y busca cualquier notificación de sincronización pendiente.
  5. El tema fue cambiado. Si el tema activo cambió, Field Forge busca en el directorio del nuevo tema. Asegúrate de que los archivos JSON existan en el tema actualmente activo.
  6. Estás importando ACF Local JSON, no sincronizando JSON de Field Forge. Los archivos fuente de ACF pertenecen a acf-json/ y son manejados por la herramienta de migración de ACF. Los propios archivos de sincronización de Field Forge pertenecen a fieldforge-json/.

La Página de Opciones No Aparece

Síntomas: Creaste una página de opciones, pero no aparece en la barra lateral del administrador de WordPress. Causas y soluciones posibles:
  1. PRO no está activado. Las Páginas de Opciones requieren una licencia PRO. Ve a Field Forge > Licencia y verifica que tu licencia esté activa.
  2. Desajuste de capacidad. Si la página de opciones fue creada con una capacidad personalizada, tu cuenta de usuario puede no tenerla. Inicia sesión como Administrador para confirmar que la página existe, luego ajusta la configuración de capacidad si es necesario.
  3. Conflicto de posición del menú. Si otro plugin o elemento del menú ocupa el mismo número de posición, la página de opciones puede estar oculta detrás de él. Intenta cambiar la posición del menú en la configuración de la página de opciones.
  4. Caché. Algunos plugins de caché o cachés de objetos pueden almacenar en caché el menú de administración. Borra tu caché y actualiza el panel de administración.

Los cambios en la página de opciones desaparecen después de guardar

Síntomas: Abres una página de opciones (la configuración del tema “Общие”, una página de opciones personalizada, o cualquier página registrada a través de acf_add_options_page / fieldforge_add_options_page), editas un valor o añades una nueva fila de repetidor, haces clic en Guardar, ves el aviso verde “Opciones guardadas”, y luego al recargar el formulario muestra el valor ANTIGUO de nuevo. La nueva fila de repetidor ha desaparecido, el enlace del mapa cambiado se ha revertido, la página de Política de Privacidad seleccionada está vacía. Por qué sucede (cualquiera de las cuatro causas raíz, todas corregidas juntas en v1.0.10):
  1. La pestaña de idioma traducido leía datos del idioma por defecto. La capa de compatibilidad no respetaba el conmutador de administrador de LangForge ?lf_lang=, por lo que la pestaña EN/UZ mostraba valores RU. Editarlos luego escribía de nuevo en el almacenamiento del idioma por defecto y el idioma traducido permanecía vacío.
  2. Nombres de subcampos compuestos rechazados por la lista blanca de guardado. Subcampos cuyo nombre contenía un guion bajo — map_link, privacy_policy, social_name, social_link — fueron silenciosamente eliminados del procesamiento POST porque la lista blanca dividía el nombre en _ y requería que cada parte fuera un campo registrado. Sus valores nunca llegaron a la base de datos.
  3. El have_rows anidado buscaba almacenamiento bajo el prefijo incorrecto. Un tema que llamaba a have_rows('socials') dentro de have_rows('common', 'option') buscaba claves llamadas solo socials en lugar de common_socials. El frontend renderizaba una sección vacía incluso cuando los datos se guardaban correctamente.
  4. El conteo de filas ocultas no se actualizaba cuando hacías clic en Añadir fila o Eliminar fila. Los datos de la nueva fila se guardaban, pero la entrada de conteo seguía diciendo el número antiguo. Al volver a renderizar, el servidor iteraba para ($i = 0; $i < count) y omitía completamente la nueva fila. La fila permanecía en la base de datos, invisible tanto para el formulario de administración como para el sitio público.
Lo que hace la versión actual: los cuatro errores están corregidos en v1.0.10. Las lecturas y escrituras en las páginas de opciones respetan el idioma activo; los nombres compuestos pasan por la lista blanca mediante coincidencia de prefijo codicioso; las iteraciones anidadas llevan el prefijo del campo padre; Añadir fila / Eliminar fila refluye índices y actualiza la entrada de conteo en vivo, por lo que guardar/recargar siempre refleja lo que enviaste. Si aún ves el síntoma después de actualizar:
  1. Realiza una recarga dura de la página de administración (Cmd+Shift+R / Ctrl+Shift+R) para recoger el nuevo admin.js. El destructor de caché es automático cuando subes el nuevo archivo, pero una caché de navegador obsoleta mantendrá el comportamiento antiguo.
  2. Verifica que el OPcache de tu hosting haya recogido los nuevos archivos PHP. En Hostinger / LiteSpeed hosting compartido, el OPcache puede mantener los antiguos archivos de clase hasta una hora después de la subida. Cambia la versión de PHP en el panel o sube un pequeño script para vaciar.
  3. Si tu sitio utiliza un plugin de traducción diferente a LangForge (WPML, Polylang), el filtro fieldforge/options_post_id conectado por LangForge no se activará. La compatibilidad del plugin de traducción para las páginas de opciones está en la hoja de ruta; por ahora, ACF Pro + el complemento ACFML de WPML es la pila soportada en esos sitios.

Los subcampos de imagen / enlace de página / textarea del repetidor muestran ID numéricos en bruto en el editor

Síntomas: En un campo de Repetidor en la pantalla de edición de publicaciones, columnas como Imagen o Imagen @2x muestran un número simple (800, 2954) en una entrada de texto en lugar de una vista previa de imagen con botones Seleccionar / Eliminar. Una columna de URL / Enlace de página muestra un ID numérico de publicación. Una columna de textarea muestra una entrada de texto de una sola línea que trunca contenido largo. Causa (corregido el 2026-04-24): El renderizador de Repetidor codificó en duro cada subcampo para renderizar como , ignorando el tipo real del subcampo. Los campos de nivel superior de los mismos tipos se renderizaban correctamente a través del renderizador de entrada consciente del tipo — solo la ruta del repetidor omitió el despacho. Solución: Actualiza Field Forge a la última versión. Los subcampos de repetidor ahora despachan al mismo renderizador consciente del tipo que utilizan los campos de nivel superior: los subcampos de imagen regresan con miniaturas de vista previa + botones Seleccionar / Eliminar, los subcampos page_link y post_object se renderizan como listas desplegables de páginas + publicaciones publicadas, los textareas se renderizan como textareas de múltiples líneas. El comportamiento de guardado y el esquema de nombre de entrada HTML permanecen sin cambios, por lo que los valores editados anteriormente siguen siendo.

Repetidor anidado dentro de un Repetidor muestra un número en una entrada de texto

Síntomas: Un Repetidor tiene un subcampo que es a su vez un Repetidor (por ejemplo, un bloque de Premios anual donde cada año contiene una lista de elementos de premio individuales). En la pantalla de edición de publicaciones, las filas exteriores se renderizan correctamente, pero la columna anidada muestra un número simple de un dígito o dos dígitos en una entrada de texto — el número coincide con el conteo de filas internas para esa fila exterior. Hacer clic en el “número” no hace nada, y no hay forma de editar los elementos internos desde el editor. El frontend público se renderiza correctamente porque la ruta de lectura nunca se rompió. Causa (corregido el 2026-04-24): El despachador por fila introducido el 2026-04-24 manejó los tipos de subcampo simples (imagen, textarea, page_link, post_object, etc.) pero aún enrutó los tipos compuestos anidados — Repetidor, Grupo, Contenido Flexible — a través de la entrada de texto de respaldo. La cadena de respaldo convertía el valor de conteo de filas del repetidor anidado, que es cómo apareció el dígito en lugar de la interfaz de usuario real. Solución: Actualiza Field Forge a la última versión. El renderizador de repetidor ahora detecta cuando el tipo de un subcampo es uno de repeater / group / flexible_content y delega al renderizador compuesto compartido con el id de registro anidado que el cargador de valores almacena en cada fila. Los repetidores anidados ahora renderizan sus propias filas con mangos de arrastre, botones de papelera y entradas de subcampo completamente funcionales (imágenes, textareas, etc.), y los grupos anidados renderizan sus cuadrículas de subcampo. El comportamiento de guardado y el esquema de nombre de entrada HTML permanecen sin cambios — los datos existentes se vuelven editables en la siguiente carga de página sin necesidad de migración de datos.

El botón “Añadir fila” del Repetidor se renderiza sin una etiqueta (píldora vacía en la parte inferior del Repetidor)

Síntomas: En la parte inferior de un Repetidor (y de Repetidores anidados y bloques de Contenido Flexible) hay un óvalo vacío con borde de rosa donde debería estar el botón “Añadir fila” / “Añadir diseño”. Hacer clic en él aún añade una fila, pero no hay etiqueta visible para guiar al editor. Causa (corregido el 2026-04-24): Para los repetidores migrados de ACF, button_label se almacena como una cadena vacía en lugar de null. El renderizador utilizó $field['button_label'] ?? __('Add Row') para volver a la etiqueta por defecto, pero ?? solo se activa en null — una cadena vacía pasa, por lo que el botón se renderizó sin texto. Solución: Actualiza Field Forge a la última versión. La solución de respaldo ahora utiliza !empty(...) para que tanto null como cadenas vacías resuelvan a la etiqueta por defecto “Añadir fila” / “Añadir diseño”. Establecer un button_label personalizado en el editor de grupo de campos sigue funcionando exactamente como antes.

El ancho % del subcampo dentro de un Repetidor es ignorado (todas las columnas se renderizan con anchos iguales)

Síntomas: En el editor de grupos de campos, un Repetidor tiene subcampos con valores explícitos de Width % (por ejemplo, Año 20% y Premios 80%), pero en la pantalla de edición de publicaciones, cada columna de subcampo toma una parte igual de la fila — dos subcampos quedan en 50%/50%, cuatro en 25%/25%/25%/25%, etc. La configuración de Width % parece guardarse pero no tiene efecto visible. Causa (corregido el 2026-04-24): El diseño de fila del repetidor utilizó un contenedor flex con flex: 1 en cada celda, sobrescribiendo cualquier wrapper.width que el subcampo tuviera. Los campos de nivel superior emitían un estilo en línea de su ancho de envoltura, pero la ruta de celda del repetidor no tenía tal rama. Solución: Actualiza Field Forge a la última versión. Cada celda de subcampo de repetidor ahora emite un atributo data-width="N" y un estilo en línea flex: 0 0 calc(N% - 8px); max-width: calc(N% - 8px) derivado del wrapper.width del subcampo, dentro de una fila flex con gap: 8px y flex-wrap: wrap. Los anchos se respetan tanto para repetidores exteriores como para repetidores/grupos/flexibles anidados. Las celdas sin un ancho configurado aún vuelven a flex: 1 y comparten la fila de manera uniforme.

La insignia de ancho % en el editor no se actualiza cuando escribes

Síntomas: En el editor de grupos de campos, cada subcampo tiene una pequeña insignia rosa junto a su etiqueta de tipo (por ejemplo, “Texto 20%”) que refleja su wrapper.width. Escribir un nuevo valor en la entrada de Ancho % cambia la entrada pero deja la insignia sin cambios hasta que la página se guarda y se recarga — dando la impresión de que el cambio no se está guardando. Causa (corregido el 2026-04-24): La insignia se renderizó una vez desde el valor del lado del servidor en la carga inicial. El controlador de entrada en vivo actualizaba el estado del campo JS pero no tocaba el elemento de la insignia, por lo que las dos visualizaciones se separaron hasta la siguiente re-renderización completa. Solución: Actualiza Field Forge a la última versión. El controlador de entrada wrapper.width ahora refleja el valor actual en la insignia rosa en tiempo real — añadiendo la insignia cuando se establece un ancho por primera vez, actualizando su texto a medida que escribes, y eliminándola cuando se borra el campo. Sin cambio funcional, solo una mejora de consistencia visual.

La página traducida (WPML) renderiza el texto del idioma fuente para los campos de grupo

Síntomas: Después de traducir una publicación con WPML, el frontend público del idioma traducido muestra el contenido del idioma fuente para los campos almacenados dentro de un Grupo — a pesar de que el metabox de Field Forge en el administrador muestra claramente la traducción correcta. Manifestación típica: un bloque de detalles del proyecto renderiza etiquetas en inglés bajo una URL rusa (o viceversa). Causa (corregido el 2026-04-24): WPML duplica el postmeta de la publicación fuente en la traducción en el momento de la traducción y no lo mantiene sincronizado con ediciones posteriores. Tus ediciones a los subcampos del Grupo de la publicación traducida se guardan en la propia tabla de Field Forge (wp_fieldforge_values) contra el ID de la publicación traducida, pero la capa de compatibilidad de ACF legada leía los valores del Grupo solo de get_post_meta(), que para la publicación traducida aún devolvía la copia del idioma fuente sin tocar. Solución: Actualiza Field Forge a la última versión. La capa de compatibilidad ahora prefiere valores de wp_fieldforge_values cuando existe un registro para la publicación actual, vuelve a get_post_meta() solo cuando no se encuentra ningún registro, y llena defensivamente los subcampos faltantes desde el postmeta de ACF para que los grupos parcialmente migrados se degraden de manera adecuada. No se requiere migración de datos — las traducciones existentes se vuelven correctas en la siguiente carga de página.

El contenido Wysiwyg / Imagen / Texto desaparece después de un bucle anidado have_rows

Síntomas: Una plantilla de tema itera un campo de repetidor o flexible_content dentro de otro (por ejemplo, un bloque video o image anidado dentro de un grupo topside), y inmediatamente después del bucle interno llama a the_sub_field('textblock') o the_sub_field('img') en la fila exterior — el valor regresa vacío, por lo que el marcado circundante parece roto. Las imágenes se renderizan con src="" y muestran solo el texto alt como respaldo; los bloques de texto desaparecen por completo. Causa (corregido el 2026-04-24): Cuando una iteración de have_rows() se completaba, la capa de compatibilidad limpiaba incondicionalmente el puntero de fila actual, incluso si la iteración estaba anidada dentro de un bucle exterior aún activo. El comportamiento real de ACF es que la fila actual del bucle exterior persiste hasta que termina la iteración exterior. Solución: Actualiza Field Forge a la última versión. Al finalizar la iteración, la capa de compatibilidad ahora restaura la fila actual al bucle más reciente aún activo en la pila y solo la limpia cuando no hay bucles activos. Las plantillas que mezclan llamadas anidadas de have_rows — un patrón común de ACF — ahora funcionan como se esperaba.

El botón “Añadir fila” del Repeater no funciona

Síntomas: Al hacer clic en “Añadir fila” en un campo repeater no pasa nada, o el botón está deshabilitado. Causas y soluciones posibles:
  1. Límite máximo de filas alcanzado. Si el repeater tiene una configuración de filas máximas y has alcanzado ese límite, el botón Añadir fila está deshabilitado. Verifica la configuración del repeater para un valor de filas máximas.
  2. Error de JavaScript. Abre la consola de desarrollador de tu navegador (F12 o Cmd+Opción+I) y verifica si hay errores de JavaScript. Un conflicto con otro plugin o script del tema puede impedir que el repeater funcione. Los culpables comunes son los plugins de constructor de páginas o los plugins de optimización de administración que concatenan scripts de manera agresiva.
  3. Licencia PRO inactiva. Repeater es un tipo de campo PRO. Si tu licencia ha expirado o ha sido desactivada, la funcionalidad del repeater puede estar limitada. Verifica Field Forge > Licencia.
  4. Compatibilidad del navegador. Prueba con otro navegador o borra la caché de tu navegador. Las versiones de navegador desactualizadas a veces tienen problemas con elementos de formulario dinámicos.

Diseños de contenido flexible faltantes

Síntomas: Cuando haces clic en “Añadir diseño” en un campo de contenido flexible, el menú desplegable está vacío o faltan algunos diseños. Causas y soluciones posibles:
  1. Los diseños no fueron definidos. Abre el editor del grupo de campos y verifica el campo de contenido flexible. Cada diseño debe ser añadido explícitamente con un nombre y subcampos. Si un diseño fue eliminado accidentalmente, utiliza el Historial de revisiones para restaurarlo.
  2. Límite máximo de diseños alcanzado. Si se estableció un máximo para un tipo de diseño específico, desaparecerá del menú desplegable una vez que se alcance ese límite. Elimina una instancia existente de ese diseño para liberar el espacio.
  3. Lógica condicional ocultando diseños. Si se configuró lógica condicional en los diseños, algunos pueden estar ocultos en función de otros valores de campo. Verifica la configuración de la lógica condicional.
  4. Problema de licencia PRO. El contenido flexible requiere PRO. Verifica el estado de tu licencia.

Problemas de rendimiento con muchos grupos de campos

Síntomas: El área de administración se siente lenta al editar publicaciones, o la lista de grupos de campos tarda mucho en cargar. Causas y soluciones posibles:
  1. Demasiados campos en una publicación. Si una sola publicación coincide con muchos grupos de campos (resultando en más de 50 campos), el editor puede volverse lento. Consolida grupos de campos donde sea posible o utiliza campos de pestañas para organizar grandes grupos en secciones. Las pestañas cargan campos de manera perezosa, mejorando el rendimiento percibido.
  2. Lógica condicional compleja. Una lógica condicional extensa con muchas reglas interconectadas requiere más procesamiento de JavaScript. Simplifica las condiciones donde sea posible.
  3. Limitaciones de alojamiento. El alojamiento compartido con CPU y memoria limitadas puede tener problemas con páginas de administración complejas. Considera actualizar a un alojamiento de WordPress gestionado si el rendimiento de la administración es consistentemente deficiente.
  4. Caché de objetos. Instala un plugin de caché de objetos (como Redis o Memcached) para reducir las consultas a la base de datos. Field Forge se beneficia de la caché de objetos porque las definiciones de grupos de campos se almacenan en caché después de la primera carga.

Conflicto con ACF (Ambos activos)

Síntomas: Comportamiento extraño, metaboxes duplicados, campos mostrando valores del plugin incorrecto, o errores de PHP mencionando redeclaración de funciones. Causas y soluciones posibles:
  1. Desactiva un plugin. Ejecutar ACF y Field Forge simultáneamente solo está destinado durante la migración. Después de la migración, desactiva ACF. Field Forge proporciona todas las mismas funciones, por lo que el código de tu tema seguirá funcionando.
  2. Conflicto de funciones. Si ambos plugins intentan registrar get_field(), PHP lanzará un error fatal sobre declaraciones de funciones duplicadas. Las versiones actuales de Field Forge se deferirán a ACF siempre que ACF esté activo o se esté activando a través de la administración de WordPress/herramientas de plugins, por lo que ACF Pro puede activarse para la migración sin provocar un error fatal de redeclaración get_field(). Si aún ves este error, actualiza Field Forge primero, recarga los plugins y activa ACF nuevamente.
  3. Fallback de página de opciones durante la migración. Si ACF está activo y devuelve un valor de opción vacío mientras Field Forge tiene el valor de opción específico del idioma, Field Forge proporciona ese valor a través del filtro de carga de valores de ACF. Este puente estrecho mantiene las sondas de página de opciones conscientes de LangForge consistentes durante la migración; no hace que la operación dual a largo plazo de ACF/Field Forge sea la configuración recomendada.
  4. Metaboxes duplicados. Si ves dos conjuntos de los mismos campos en una publicación, uno de ACF y otro de Field Forge, significa que ambos plugins tienen grupos de campos y reglas de ubicación coincidentes. Desactiva ACF para eliminar los duplicados.

Valores de campo perdidos después del cambio de tema

Síntomas: Después de cambiar a un nuevo tema, los datos de campo personalizados parecen estar faltantes en el frontend. Causas y soluciones posibles:
  1. Las plantillas del tema no fueron actualizadas. Los datos de campo aún están en la base de datos — no desaparecen cuando cambias de tema. El problema es que el nuevo tema no contiene el código de plantilla (get_field(), the_field(), etc.) para mostrarlo. Pide a tu desarrollador que añada el código de salida de campo a las plantillas del nuevo tema.
  2. La ruta de JSON local cambió. Si estabas usando la sincronización de JSON local, los archivos JSON estaban en la carpeta del antiguo tema. Copia el directorio fieldforge-json/ del antiguo tema al nuevo, o reconfigura la ruta de JSON local en Field Forge > Configuración.
  3. Los grupos de campos están intactos. Ve a Field Forge > Grupos de campos para confirmar que todos tus grupos de campos aún existen. Se almacenan en la base de datos, no en el tema, por lo que sobreviven a un cambio de tema.

Errores de generación de TypeScript

Síntomas: La función de generación de TypeScript produce tipos incorrectos, lanza errores o genera archivos vacíos. Causas y soluciones posibles:
  1. Licencia PRO requerida. La generación de TypeScript es una función PRO. Verifica que tu licencia esté activa.
  2. No se definieron grupos de campos. Las interfaces de TypeScript se generan a partir de tus definiciones de grupos de campos. Si no tienes grupos de campos, la salida estará vacía.
  3. Tipos de campo no soportados en plugins personalizados. Si registraste tipos de campo personalizados a través de un plugin, el generador de TypeScript puede no saber cómo mapearlos. Verifica la salida generada para tipos any y añade mapeos de tipos personalizados utilizando el filtro fieldforge/typescript/type_map.
  4. Permisos de escritura de archivos. Si no se puede escribir el archivo de salida, verifica que el directorio de destino tenga permisos de escritura para el servidor web.

Fallos de importación/exportación

Síntomas: La importación de un archivo JSON falla, o el archivo exportado está vacío o corrupto. Causas y soluciones posibles:
  1. Formato JSON inválido. Si editaste manualmente un archivo de exportación JSON, un error de sintaxis (coma faltante, corchete extra) hará que la importación falle. Utiliza un validador de JSON (como jsonlint.com) para verificar el archivo antes de importar.
  2. Archivo demasiado grande. Exportaciones muy grandes (cientos de grupos de campos) pueden exceder los límites de upload_max_filesize o post_max_size de PHP. Aumenta estos valores en tu configuración de PHP, o divide la exportación en archivos más pequeños.
  3. Definiciones de campo desconocidas o mal formadas. Field Forge rechaza importaciones que contienen un tipo de campo desconocido, subcampos mal formados, diseños de contenido flexible mal formados, o reglas de ubicación inválidas. Actualiza ambos sitios a la última versión de Field Forge y exporta el JSON nuevamente desde el sitio de origen en lugar de editar esas secciones manualmente.
  4. Desajuste de versión. Importar un archivo exportado de una versión más nueva de Field Forge en una versión más antigua puede fallar si la versión más nueva añadió tipos de campo o configuraciones que la versión más antigua no reconoce. Actualiza Field Forge a la última versión antes de importar.
  5. Problemas de permisos. El servidor web necesita acceso de escritura al directorio uploads para el procesamiento de archivos temporales durante la importación. Verifica los permisos de la carpeta.
  6. Claves de campo duplicadas. Si la importación contiene claves de campo que ya existen en tu base de datos, Field Forge mostrará un aviso de conflicto. Elige sobrescribir los grupos existentes o omitir duplicados.
Asistente de IA de Forge En línea

¡Hola! Soy el asistente de IA de Field Forge. Pregúntame lo que quieras sobre el plugin — configuración, funciones, resolución de problemas o desarrollo.

Ahora mismo
Con la tecnología de Forge AI · Explorar documentación