Si usás ACF con campos en el editor de WordPress y de repente el scroll dejó de funcionar como antes, no estás solo. Desde WordPress 6.8, el Block Editor incorporó un «resize handle» para las meta boxes que rompió el comportamiento del scrollbar único que teníamos en 6.7. El resultado: dos barras de scroll, o directamente ninguna que funcione como esperás.
En 30 segundos
- WordPress 6.8 introdujo un separador redimensionable entre el editor y las meta boxes, lo que rompió el scrollbar único que había en 6.7.
- En Classic Editor, la solución es deshabilitar «Full-height editor» desde Screen Options.
- En Gutenberg, el fix más rápido es un snippet CSS que desactiva el height forzado de
.edit-post-meta-boxes-main.is-resizable. - Si tus campos ACF aparecen apretados en el sidebar derecho, la solución de fondo es cambiar el
positionaacf_after_titlepara moverlos al área principal. - El issue está reportado en el repositorio de Gutenberg (#69923) y todavía no tiene fix en core.
El problema de scrollbar en WordPress con ACF: qué cambió en 6.8
El editor de WordPress con ACF meta boxes funcionaba así hasta 6.7: una sola barra de scroll vertical para toda la pantalla del editor, con las meta boxes cargando debajo del bloque de contenido. Simple, predecible, sin drama.
Con 6.8, Gutenberg introdujo un «resize handle» (un separador arrastrble) entre el área del editor y el bloque de meta boxes. La idea era buena sobre el papel: que puedas darle más o menos espacio a los campos según lo necesites. El problema es que para implementar ese redimensionado, pusieron height fijo a los contenedores, lo que en muchos setups genera dos barras de scroll independientes o directamente la pérdida del scroll en las meta boxes.
El issue #69923 en el repositorio de Gutenberg acumula reportes de esto desde principios de 2026. No es un bug de ACF: es un problema del core de WordPress. ACF simplemente es el plugin que más expone el problema porque tiende a generar muchos campos.
Classic Editor vs Gutenberg: dos problemas distintos que se confunden
Antes de meter código, hay que saber cuál es tu caso real. Porque la solución varía bastante.
Si usás Classic Editor: el comportamiento del scrollbar depende de una opción de pantalla. Andá a «Screen Options» (arriba a la derecha del editor), y fijate si está activado «Habilitar editor de altura completa» (o «Enable full-height editor»). Si lo desactivás, el editor vuelve a tener height automático y el scroll funciona con una sola barra. Sencillo.
Si usás Gutenberg: ahí la complejidad sube. Tenés el editor en sí, el sidebar de opciones del bloque, las meta boxes debajo del contenido, y en algunos casos un iframe para la preview. Cada uno puede tener su propio scroll. El resize handle de 6.8 afecta específicamente al contenedor de las meta boxes, que se llama .edit-post-meta-boxes-main.
¿Cuál de los dos tenés? Si ves el editor de bloques con la toolbar flotante y la barra lateral con «Documento» y «Bloque», es Gutenberg. Si ves un área de texto plano con botones en la parte superior (negrita, itálica, media), es Classic.
Solución rápida: CSS para restaurar el scrollbar único en WordPress 6.8+
Para Gutenberg, el fix más directo es desactivar el height forzado que puso el resize handle. El CSS es este:
.edit-post-meta-boxes-main.is-resizable {
height: unset !important;
max-height: unset !important;
}Para que esto llegue solo al admin (no al frontend), metelo en tu functions.php con admin_enqueue_scripts:
add_action( 'admin_enqueue_scripts', function( $hook ) {
if ( ! in_array( $hook, array( 'post.php', 'post-new.php' ) ) ) {
return;
}
wp_add_inline_style( 'wp-edit-post', '
.edit-post-meta-boxes-main.is-resizable {
height: unset !important;
max-height: unset !important;
}
' );
} );Lo que hace esto: le saca el height computado que Gutenberg le asigna al contenedor de meta boxes cuando activás el resize handle. Con height: unset, el contenedor vuelve a fluir con su contenido natural, y el scroll del documento entero toma el control de vuelta.
Dicho esto: es una solución temporal. El fix correcto tiene que venir de Gutenberg core, y hasta que no llegue eso, este CSS puede quebrarse con alguna actualización. Testealo después de cada update. Ya lo cubrimos antes en nuestro artículo sobre cómo probar cambios en un staging.
Cuando los campos ACF aparecen apretados en el sidebar: el problema de layout
Ponele que registraste diez campos ACF para un custom post type, todos con labels y descripciones. Abrís el editor y los campos aparecen comprimidos en el sidebar derecho, el que tiene apenas 280px de ancho. Los inputs de texto se ven bien, pero los selectores, las galerías o los campos de relación quedan inutilizables.
Esto pasa porque Gutenberg decide, por lógica de espacio, enviar algunas meta boxes al sidebar cuando hay muchos campos. No es un bug exactamente, pero la experiencia es pésima.
Solución inmediata: en el bloque de contenido, hacé clic en el ícono de lápiz (modo «Edit») que aparece en la barra del bloque. Eso le devuelve espacio al área de edición y puede mejorar el layout. No es la solución definitiva, pero zafa para ver qué tenés.
El fix de fondo está en cómo registrás los campos, y lo vemos en la sección siguiente.
Solución de fondo: reorganizar meta boxes con position y drag-drop
ACF te da control sobre dónde aparece cada grupo de campos. El parámetro position en register_field_group (o en la UI del plugin) acepta tres valores:
| Valor | Dónde aparece | Cuándo usarlo |
|---|---|---|
normal | Área principal, debajo del editor | Campos que necesitan ancho completo (galería, relación, repeater) |
side | Sidebar derecho | Campos cortos: fecha, estado, campo texto simple |
acf_after_title | Entre el título y el editor de contenido | Campos que son parte del flujo editorial, no secundarios |
La combinación que más funciona en proyectos grandes: campos de relación, repeaters y galerías en normal, campos de metadatos cortos en side. Si tenés un campo que es casi tan importante como el título (como un subtítulo o un campo de «resumen»), acf_after_title lo pone en el lugar más visible sin competir con el editor.
Aparte del code, WordPress 6.7+ permite drag-drop de meta boxes en el editor: arrastrás el título de la meta box y la reubicás. La posición se guarda en la base de datos por usuario (en wp_usermeta, clave meta-box-order_post), no es global. Útil para el admin, no para estandarizar el comportamiento en todo el equipo.
Casos avanzados: scrollbar doble, iframe focus y WYSIWYG anidado
Para los que están depurando algo más raro, hay tres edge cases documentados que vale tener en mente.
El doble scrollbar del editor
El issue #62319 de Gutenberg cubre el caso donde aparece una barra de scroll dentro del editor de bloques además de la del documento. Pasa en setups donde el editor tiene height: 100vh forzado por el theme o por algún plugin de personalización del admin. Si ves dos scrollbars al mismo tiempo, revisá si tu theme admin o algún plugin de «admin UI» está pisando los estilos de Gutenberg.
El bug del iframe focus en ACF Blocks
Si usás ACF Blocks (no solo campos) con el modo de preview, hay un bug reportado en el soporte de ACF donde el focus del scroll queda atrapado dentro del iframe del bloque. El resultado: scrolleás en el editor y el documento no se mueve, se mueve el contenido del iframe del bloque.
La solución documentada: cambiar el mode del bloque ACF a 'auto' en el registro del bloque. Así:
acf_register_block_type( array(
'name' => 'mi-bloque',
'title' => 'Mi Bloque',
'render_callback' => 'mi_bloque_callback',
'mode' => 'auto', // <-- esto
) );Con mode => 'auto', el bloque decide si usar preview o edición directa según el contexto, y el foco del iframe se maneja diferente. No es perfecto, pero el problema del scroll desaparece en la mayoría de los casos.
Campo WYSIWYG dentro de un bloque ACF
El campo WYSIWYG de ACF, cuando está dentro de un bloque que tiene preview por iframe, genera su propio contenedor de scroll (el editor TinyMCE tiene su propia área de scroll interna). Si ese bloque está en modo preview, el scroll del TinyMCE puede interferir con el del documento. Cambiar el modo a edit forzado soluciona el problema, a costo de perder la preview del bloque. Esto se conecta con lo que analizamos en asegúrate de tener WordPress actualizado.
Checklist para diagnosticar tu problema de scrollbar exacto
Antes de aplicar cualquier fix a ciegas, respondé estas preguntas:
- ¿Qué versión de WordPress tenés? El resize handle existe desde 6.8. En 6.7 no existe este problema específico.
- ¿Classic Editor o Gutenberg? Si tenés el plugin Classic Editor activo, las soluciones son distintas.
- ¿Cuántas barras de scroll ves? Una dentro del editor y otra en el documento = doble scrollbar (issue #62319). Solo la del documento no funciona = resize handle problem (issue #69923).
- ¿El problema aparece en todos los post types o en uno específico? Si es solo uno, probablemente sea la cantidad de campos ACF de ese tipo o su configuración de posición.
- ¿Pasa con otro usuario en el mismo sitio? Si no, el drag-drop de meta boxes pudo haber guardado una configuración rara en la db de ese usuario.
- ¿Tenés ACF Blocks registrados en ese post type? Probable que sea el bug de iframe focus.
- ¿Usás algún plugin de admin UI o custom CSS en el backend? Puede estar pisando los estilos de Gutenberg.
Con estas respuestas, la solución correcta queda clara en el 90% de los casos.
Qué está confirmado / Qué todavía no
| Estado | Qué |
|---|---|
| Confirmado | El resize handle de WordPress 6.8 rompe el scrollbar único en muchos setups con meta boxes |
| Confirmado | El issue #69923 está abierto en el repo de Gutenberg y sin fix en core a mayo 2026 |
| Confirmado | El CSS con height: unset restaura el comportamiento en la mayoría de los setups |
| Confirmado | mode => 'auto' resuelve el bug de iframe focus en ACF Blocks v3 |
| Pendiente | Fix oficial en Gutenberg core: sin fecha confirmada |
| Pendiente | Si ACF Pro va a incluir workaround propio antes del fix de WordPress |
Errores comunes al intentar arreglar esto
Error 1: aplicar el CSS en el stylesheet del frontend. El CSS que arregla el scrollbar del editor es específico del admin. Si lo metés en style.css del theme, no hace nada (las clases edit-post-meta-boxes-main no existen en el frontend). Tiene que ir via admin_enqueue_scripts.
Error 2: desactivar el resize handle a nivel de usuario y esperar que aplique globalmente. El drag-drop y la configuración de meta boxes se guardan por usuario en wp_usermeta. Si vos lo arreglás en tu cuenta de admin, el resto del equipo sigue con el problema. El fix CSS es global y aplica para todos.
Error 3: mover todos los campos ACF a side pensando que "saca el problema de debajo del editor". Lo que hace es empeorarlo: el sidebar es más angosto, los campos quedan más comprimidos, y el scrollbar del sidebar entra en conflicto con el del documento. Los campos complejos (repeaters, galerías, relaciones) siempre van en normal.
Error 4: atribuirle el bug a ACF y desactivarlo para probar. El problema está en cómo Gutenberg maneja las meta boxes desde 6.8. Si desactivás ACF y el scroll funciona, es porque eliminaste las meta boxes, no porque ACF fuera el culpable.
Preguntas Frecuentes
¿Cómo restaurar el scrollbar en el editor de WordPress cuando uso ACF meta boxes?
Agregá este CSS via admin_enqueue_scripts en functions.php: .edit-post-meta-boxes-main.is-resizable { height: unset !important; max-height: unset !important; }. Eso deshabilita el height fijo que WordPress 6.8 le asigna al contenedor de meta boxes para su resize handle. Si usás Classic Editor, la solución es diferente: en "Screen Options" desactivá "Full-height editor".
¿Por qué no funciona el scroll en los campos ACF en el editor Gutenberg?
WordPress 6.8 introdujo un resize handle entre el editor y las meta boxes que fuerza un height fijo en el contenedor de los campos. Eso rompe el scroll natural del documento. El issue está reportado en GitHub como #69923 y no tiene fix en core a mayo 2026. El workaround es remover el height forzado con CSS.
¿Cómo mover mis campos ACF del sidebar apretado al área principal del editor?
En la configuración del grupo de campos en ACF, cambiá el parámetro position a normal. Eso mueve el grupo al área principal debajo del editor, con el ancho completo disponible. La opción acf_after_title los pone entre el título y el bloque de contenido. Solo usá side para campos cortos que no necesiten espacio.
¿Cuál es la diferencia entre tener uno o dos scrollbars en el editor de WordPress?
Un scrollbar (el del documento) es el comportamiento esperado: scrolleás y toda la página se mueve. Dos scrollbars significa que hay contenedores con overflow independientes: uno para el editor y otro para las meta boxes. Eso pasa cuando Gutenberg asigna height fijo a algún contenedor. El resultado es que para ver el final de los campos ACF tenés que scrollear dentro de una caja, no en la página entera.
¿El problema de scrollbar lo causa ACF o es un bug de WordPress?
Es un bug de WordPress (Gutenberg), no de ACF. El cambio al resize handle en 6.8 afecta a cualquier plugin que registre meta boxes debajo del editor. ACF lo expone más claramente porque sus grupos de campos generan meta boxes con mucho contenido. Si desactivás ACF y el scroll mejora, es porque eliminaste las meta boxes, no porque ACF estuviera roto.
Conclusión
El problema de scrollbar en el editor de WordPress con ACF meta boxes tiene origen claro: el resize handle que WordPress 6.8 incorporó al Block Editor. El fix de CSS con height: unset resuelve el síntoma mientras el core no lo arregla. Para los casos donde los campos aparecen apretados en el sidebar, la solución de fondo es revisar el position de cada grupo de campos en ACF. Y para los que usan ACF Blocks, el modo auto evita el bug de iframe focus.
Mientras WordPress no cierre el issue #69923, este es el workflow que funciona: CSS para el scrollbar, position bien configurado para el layout, y mode => 'auto' para los bloques con preview.
![Just released our AI agent plugin for wordpress - [FREEMIUM] - ilustracion](https://wordpress.donweb.com/wp-content/uploads/2026/05/plugin-ia-para-wordpress-claude-agente-hero.jpg)
