El editor masivo de WooCommerce no guarda los cambios: causas y solución
Que los cambios del editor masivo de WooCommerce no se guarden puede significar cuatro cosas distintas: un valor escrito en una celda desaparece al recargar, la edición vinculada (binded editing) cambia solo la fila en la que has escrito, una edición masiva termina con productos procesados: 0 (products bulked: 0), o los valores se guardaron y horas después volvieron a los antiguos. Cada caso tiene su propia causa, y el editor te indica con cuál estás tratando si sabes dónde leerlo. A continuación va primero esa lectura y después la solución para cada caso.
Qué te dice el síntoma
Tras editar una celda, BEAR muestra Guardando ... (Saving ...) mientras se ejecuta la petición y Guardado (Saved.) cuando el servidor ha respondido, y entonces la celda se vuelve a dibujar con lo que devolvió el servidor. Tras una edición masiva, la pestaña Historial (History) recibe un registro con su estado y el número de productos modificados. Juntos señalan la causa:
| Lo que ves | Qué significa |
|---|---|
| Ningún Guardando ... (Saving ...), valor antiguo tras recargar | La edición nunca se envió: la celda se dejó sin pulsar Enter |
| La celda muestra no permitido (forbidden) tras pulsar Enter | El campo no es editable para tu rol |
La celda muestra 0 tras pulsar Enter | La comprobación de seguridad rechazó la petición: no hay permiso para este producto, o la página del editor estuvo abierta tanto tiempo que su token de seguridad caducó (recárgala) |
| Guardando ... (Saving ...) se queda y Guardado (Saved.) nunca aparece | La petición fue bloqueada o falló en el servidor |
| La edición vinculada cambió una fila de varias marcadas | El envío a las demás filas no se inició o no recibió sus datos |
| Historial: completado (completed), productos procesados: 0 (products bulked: 0) | Los datos de la edición masiva se perdieron entre peticiones, normalmente por la caché |
| Guardado, visible en Historial, vuelto a cambiar más tarde | Algo distinto de BEAR escribió en los productos |
Las ediciones en línea se guardan con Enter
Las celdas de texto y número del Editor de productos (Products Editor) (título, SKU, precios, cantidad de stock, peso, dimensiones, campos meta) abren un campo de entrada al hacer clic. El valor se envía al servidor solo cuando pulsas Enter, que guarda y abre la misma celda en la fila siguiente, o Flecha arriba / Flecha abajo, que guardan y suben o bajan. Esc cancela. Tabulador y un clic fuera de la celda no envían nada, y hacer clic en otra celda cierra el campo abierto sin guardarlo. Flecha izquierda y Flecha derecha solo mueven el cursor dentro del texto. Cuando te acostumbras, así se rellena una columna muy rápido: escribir, Enter, escribir, Enter, hacia abajo por toda la página.
Los desplegables, los interruptores y los editores emergentes, como el de la descripción, guardan en el momento en que eliges un valor o confirmas la ventana, así que no necesitan Enter.
En los campos meta, una edición que "no se queda" también puede deberse a una clave escrita de forma distinta a la real: BEAR guarda bajo la clave que configuraste, y el producto sigue mostrando el valor almacenado bajo la clave real. Compara la clave de la pestaña Campos meta (Meta Fields) con los campos personalizados del producto.
La edición vinculada cambia un solo producto
La edición vinculada es un interruptor del panel de herramientas. Con él activado, un valor guardado en una fila marcada se envía a todas las demás filas marcadas de la página; el envío se ejecuta como una pequeña operación masiva, y por eso recibe su propio registro en Historial. Los motivos habituales por los que cambia solo la fila en la que has escrito:
- El interruptor se desactivó solo. Se apaga en cuanto empieza un envío, así que el siguiente campo que edites se guarda solo en una fila. Actívalo de nuevo antes de cada edición vinculada.
- No hay suficientes filas marcadas. Marca al menos dos productos, incluido aquel en el que vas a escribir. Marcar funciona en la página actual; para un conjunto mayor usa un filtro y la pestaña Edición masiva (Bulk Edit), como se describe en establecer el mismo valor en varios productos.
- El campo no está disponible para la edición vinculada. La información sobre herramientas junto al interruptor enumera los campos que la versión gratuita puede enviar; para los demás, una alerta indica que el campo está desactivado para la edición masiva.
- La petición de envío no recibió sus datos. Usa el mismo almacenamiento del servidor y las mismas peticiones a
admin-ajax.phpque la pestaña Edición masiva, así que todo lo de la sección de cortafuegos y cachés más abajo se aplica también aquí. Un error de JavaScript en la consola del navegador (F12) también lo detiene; prueba en una ventana privada y en otro navegador para descartar un script en caché obsoleto o una extensión del navegador.
Los productos marcados siguen marcados mientras continúas trabajando en la página, y la pestaña Edición masiva les da prioridad sobre el filtro: su línea La edición masiva se aplicará a (Bulk editing will be applied to) nombra entonces los productos seleccionados y su número. Desmárcalos con el botón de desmarcar del panel de herramientas antes de una edición masiva que deba abarcar todo el filtro; de lo contrario, solo cambia los marcados.
Ediciones rechazadas por roles y capacidades
BEAR se abre para los usuarios que tienen la capacidad manage_woocommerce de WooCommerce, y cada guardado comprueba que el usuario puede editar ese producto concreto. Un rol sin edit_others_products solo puede guardar sus propios productos; para los demás la petición se rechaza y la celda muestra 0.
Los roles distintos de administrador también están limitados campo por campo. En la pestaña Ajustes (Settings), un administrador marca visible para el gestor de la tienda (visible for the shop manager) bajo cada columna que un gestor de la tienda puede ver y editar, y guarda con Guardar todos los ajustes (Save all settings). Las columnas sin la marca no se muestran en absoluto a ese rol. La trampa es una instalación nueva: hasta que un administrador haya guardado la pestaña Ajustes una vez, ningún campo está marcado todavía, así que el gestor de la tienda ve todas las columnas y cada edición responde no permitido (forbidden). Guardar la pestaña Ajustes como administrador lo soluciona. La FAQ sobre limitar el rol de gestor de la tienda muestra la configuración.
Para reglas que las casillas no pueden expresar, dos filtros deciden en código. woobe_user_can_edit decide por campo para los roles que no son administrador: devuelve 1 para permitir, 0 para rechazar.
// Child theme functions.php or a code snippets plugin.
// BEAR: let non-administrator roles edit prices and stock whatever the Settings checkboxes say.
add_filter( 'woobe_user_can_edit', function ( $can_edit, $field_key, $visibility ) {
if ( in_array( $field_key, array( 'regular_price', 'sale_price', 'stock_quantity' ), true ) ) {
return 1;
}
return $can_edit;
}, 10, 3 );
woobe_permit_special_roles hace que un rol cuente como administrador dentro de BEAR. Úsalo con moderación: ese rol también ve y guarda los ajustes de toda la tienda, entre ellos los del servidor MCP.
add_filter( 'woobe_permit_special_roles', function ( $roles ) {
$roles[] = 'shop_manager';
return $roles;
} );
Cuando una cuenta de administrador no puede guardar y otra sí, el problema es la propia cuenta. BEAR decide según el primer rol de la cuenta, así que un administrador que además tiene un segundo rol de un plugin de membresías o de edición de roles puede ser tratado como ese otro rol, y un editor de roles puede quitar capacidades a una sola cuenta. Crea un administrador nuevo, repite la edición y compara los roles y las capacidades de las dos cuentas.
Cortafuegos, plugins de caché y "productos procesados: 0"
Cortafuegos del servidor. Las reglas de ModSecurity, incluido el cortafuegos de aplicaciones web de Plesk, suelen responder 403 Forbidden a una petición que lleva HTML, de modo que las descripciones y otros textos con marcado se quedan en Guardando ... (Saving ...). El registro del cortafuegos nombra la regla; desactiva esa regla para el sitio en lugar de todo el cortafuegos. La FAQ El contenido de la descripción no se guarda muestra un caso así.
Plugins de caché y de optimización. Cada guardado y cada paso de una edición masiva es una petición a /wp-admin/admin-ajax.php. Las cachés de página con la caché de administración o de AJAX activada, las funciones de "optimizar para usuarios conectados", la minificación y combinación de scripts de administración, y las cachés de hosting en plataformas con escalado automático han interceptado estas peticiones. WP-Optimize y LiteSpeed Cache son ejemplos típicos, y en ambos la solución es excluir /wp-admin/ de la caché de páginas y de la optimización; la limpieza de la base de datos y la compresión de imágenes pueden seguir activadas. Para comprobarlo, desactiva el plugin de caché, vacía la caché del servidor, repite la edición y vuelve a activar las cosas de una en una.
El almacenamiento de los datos de la edición masiva. La pestaña Edición masiva guarda la operación en el servidor y cada lote la vuelve a leer. Si el almacenamiento la pierde, cada lote no encuentra nada que escribir e Historial muestra completado (completed) con productos procesados: 0 (products bulked: 0). Establece Almacenamiento del plugin (Plugin memory storage) en Ajustes en Opción (recomendado) (Option (recommended)) y elimina cualquier fragmento antiguo de woobe_storage_type; los motivos se explican en el filtro del editor masivo no funciona, porque el mismo almacenamiento guarda el filtro.
Si nada de esto aplica, un plugin enganchado al guardado de productos aún puede detener o deshacer una escritura. Aislar plugins durante las ediciones masivas muestra cómo encontrarlo y cómo mantenerlo fuera de las peticiones de BEAR.
Valores que vuelven a cambiar más tarde
BEAR solo escribe en los productos cuando alguien guarda en su editor, revierte un registro en Historial o trabaja a través de su servidor MCP cuando está activado. Cada una de estas acciones deja un registro en Historial, y este muestra quién hizo el cambio y si se hizo a mano o mediante un agente de IA. Si los precios, el stock o los atributos vuelven a cambiar en un momento que no tiene registro en Historial, no fue BEAR.
Busca qué más escribe en los productos de forma programada: plugins de importación y sincronización de productos, conectores de TPV y de inventario, integraciones con ERP y marketplaces, feeds de proveedores y plugins multilingües que copian campos del idioma original a las traducciones. Sus registros, o la hora de sus tareas programadas en Herramientas > Acciones programadas (Tools > Scheduled Actions), suelen coincidir con el momento en que cambió el valor.
Cómo confirmar que un cambio se guardó
- La celda. Tras pulsar Enter muestra el valor guardado, no no permitido (forbidden) ni
0, y aparece Guardado (Saved.). - Historial. El registro existe, su estado es completado (completed) y productos procesados (products bulked) coincide con el número que esperabas.
- El propio producto. Ábrelo en Productos (Products) en wp-admin. La base de datos es la verdad; si la página de la tienda sigue mostrando el valor antiguo, la caché de páginas o la caché propia de un maquetador de páginas está sirviendo una copia vieja (consulta el caso de Elementor).
- Los registros. Con
WP_DEBUG_LOGactivado,wp-content/debug.logmuestra los errores de PHP producidos durante el guardado, y la pestaña Red del navegador muestra el estado de la petición aadmin-ajax.php: 403 si es un cortafuegos, 500 si es un error de PHP.
Si el valor sigue sin guardarse, abre un tema en el foro de soporte de BEAR con el campo, lo que muestra la celda tras pulsar Enter, el registro de Historial y el estado de la petición.