El filtro del editor masivo de WooCommerce no funciona o se pierde en la página 2

30 January 2027

Cuando el filtro del editor masivo de WooCommerce no funciona, el síntoma es casi siempre el mismo: la primera página de la tabla muestra los productos correctos, y la página 2, un cambio de filas por página, un clic en la ordenación o el interruptor de variaciones devuelven todo el catálogo. En la mayoría de los casos el filtro en sí está bien. Lo que falla es el lugar del servidor donde BEAR guarda el filtro entre peticiones, y por eso una edición masiva pensada para 200 productos filtrados puede acabar escribiendo en todos los productos de la tienda. A continuación se explica cómo funciona ese almacenamiento, el ajuste que lo corrige desde la versión 2.2.2, el antiguo fragmento de código que puede deshacer ese ajuste sin avisar, y los casos en que el filtro funciona exactamente como está diseñado pero devuelve algo que no esperabas.

Cómo guarda el editor masivo un filtro entre páginas

Cuando pulsas Filtrar (Filter), el navegador envía las condiciones una sola vez. BEAR las guarda en el servidor bajo una clave aleatoria y la página recuerda solo esa clave. Cada petición posterior, la página 2, una nueva longitud de página, la ordenación, el interruptor de variaciones (variations), la edición masiva, la exportación, envía únicamente la clave, y el servidor vuelve a leer las condiciones del almacenamiento. Si el almacenamiento no devuelve nada, no hay nada por lo que filtrar, y la consulta se ejecuta sobre todos los productos.

Eso convierte el contador situado bajo la tabla en el número más importante de la pantalla. Mostrando 1 a 50 de 226 entradas (Showing 1 to 50 of 226 entries) justo después de filtrar, y luego de 5720 entradas (of 5720 entries) en la página 2, significa que el filtro se perdió entre las dos peticiones. La pestaña Edición masiva (Bulk Edit) no muestra un recuento; dice La edición en masa se aplicará a: los productos filtrados (Bulk editing will be applied to: the filtered products), y lee el filtro del mismo almacenamiento. Así que cuando el contador salta, una edición masiva o una exportación basada en el filtro en ese momento abarca todo el catálogo.

Antes de cada Realizar edición en masa (Do Bulk Edit) sobre un filtro, mira el contador. Si una ejecución ya ha ido a parar a los productos equivocados, abre la pestaña Historial (History): cada operación masiva queda registrada con los valores anteriores y se puede revertir como un único registro.

Dos cosas borran un filtro por diseño. Recargar la página del editor inicia una página nueva sin clave, así que el filtro desaparece; guárdalo como perfil de filtro si vas a necesitarlo de nuevo. Y un filtro almacenado caduca un día después de aplicarse, de modo que una pestaña abierta durante la noche necesita que se aplique el filtro otra vez antes de la siguiente ejecución masiva.

La solución: Almacenamiento del plugin en Opción

Abre la pestaña Ajustes (Settings) de BEAR y busca Almacenamiento del plugin (Plugin memory storage) en la columna Ajustes generales (General settings). Tiene dos valores: Opción (recomendado) y Transient. Elige Opción (recomendado) (Option) y pulsa Guardar todos los ajustes (Save all settings). El ajuste afecta a toda la tienda y solo un administrador puede cambiarlo. Existe desde la versión 2.2.2, así que actualiza BEAR primero si no lo ves.

Por qué importa:

Opción guarda el filtro, los datos de la edición masiva y el contador de progreso masivo en una fila de la tabla wp_options por usuario, llamada woobe_memory_ más el ID de usuario, con autoload desactivado para que nunca se cargue en las páginas de la tienda. Una fila de la base de datos no se puede expulsar. Las cachés pueden descartar su copia, y la siguiente petición simplemente la vuelve a leer de la base de datos.
Transient es como funcionaba BEAR antes. En un sitio sin caché de objetos persistente, un transient también es una fila de la base de datos, y funciona. Con Redis o Memcached, WordPress guarda los transients solo en la caché y nunca los escribe en la base de datos (consulta la API de Transients), de modo que cualquier cosa que vacíe la caché destruye el filtro. La clave del transient además se construía a partir de la dirección IP del visitante, que cambia entre peticiones detrás de algunos proxies y CDN y es compartida por los compañeros de una misma oficina.

Opción es el valor por defecto en las instalaciones nuevas y en las actualizadas que nunca guardaron otro valor. Si el contador sigue saltando con Opción seleccionada, la sección siguiente es el motivo más probable.

Los antiguos fragmentos woobe_storage_type anulan el ajuste

Durante años la respuesta a un filtro perdido fue una línea en el functions.php del tema que cambiaba el almacenamiento a 'session' o 'transient' mediante el filtro woobe_storage_type. Ese filtro sigue existiendo y se ejecuta después de leer el ajuste: lo que devuelva el fragmento se impone, sea lo que sea que esté seleccionado en Ajustes. Un sitio que añadió el fragmento hace años sigue funcionando con sesiones o transients tras la actualización, mientras la pestaña Ajustes dice Opción.

Busca woobe_storage_type en el tema activo, el tema hijo, los mu-plugins y los plugins de fragmentos de código. Un resto típico tiene este aspecto:

add_filter('woobe_storage_type', function($type) {
    return 'session'; // or 'transient'
});

Elimínalo y después elige el almacenamiento en Ajustes. Session ya no se ofrece allí: depende del manejo de sesiones de PHP y WooCommerce del servidor y era la opción menos fiable de las tres para una serie de peticiones AJAX. Conserva un fragmento solo si una prueba en tu sitio demuestra que el ajuste por sí solo no funciona, y en ese caso haz que devuelva 'option', para que al menos fuerce el almacenamiento que sobrevive al vaciado de la caché.

Redis, Memcached y otras cachés

El vaciado de la caché de objetos y woobe_use_cache_flush

Antes de construir las filas de la tabla, BEAR llama a wp_cache_flush() para que la tabla muestre los valores actuales y no lo que estaba en caché antes de tu última edición. Sin una caché de objetos persistente, esto solo borra la memoria de la petición actual y no cuesta nada. Con Redis, Memcached u Object Cache Pro vacía toda la caché del sitio en cada carga de la tabla, que es lo que antes eliminaba el transient con el filtro.

Con el almacenamiento en Opción, el vaciado ya no toca el filtro. Sigue costándole al resto del sitio una reconstrucción de la caché cada vez que se carga la tabla. En una tienda con caché de objetos persistente puedes desactivar el vaciado:

// Child theme functions.php or a code snippets plugin.
// BEAR: do not flush the persistent object cache before drawing the products table.
add_filter( 'woobe_use_cache_flush', '__return_false' );

La contrapartida: un valor cambiado hace un momento puede mostrar ocasionalmente su versión antigua en la tabla hasta que recargues. La parte pública de la tienda no se ve afectada en ningún caso. El hook figura junto con las demás opciones a nivel de código en Más ajustes (implícitos).

A menudo hay una caché de objetos persistente activa sin que nadie la haya instalado: los hostings gestionados y los paneles de hosting activan Redis o Memcached por ti. Si Plugins en wp-admin muestra una lista Drop-ins con object-cache.php, tienes una.

Cachés de página, de administración y de optimización

Las cachés de página como WP Rocket, LiteSpeed Cache o WP-Optimize, las reglas de CDN como una regla de Cloudflare de cachear todo, y las cachés a nivel de hosting nunca deben almacenar en caché /wp-admin/ ni /wp-admin/admin-ajax.php. La página del editor y cada petición de la tabla pasan por estas direcciones, y un administrador necesita ver el resultado del cambio que acaba de hacer, no una copia almacenada. Los valores por defecto de los plugins conocidos ya las excluyen; los lugares donde mirar son las reglas personalizadas, las cachés de servidor en hostings gestionados y las funciones de "optimizar el administrador". Si el filtro funciona con todo el almacenamiento en caché desactivado y falla con él activado, añade las exclusiones y vacía todas las cachés.

Cuando el filtro no devuelve nada o devuelve productos equivocados

Algunos resultados que parecen un filtro roto son el filtro haciendo exactamente lo que se le pidió.

Una categoría padre no incluye sus subcategorías

Filtrar por una categoría encuentra los productos asignados a ese término. Un producto asignado solo a Zapatos > Zapatillas no lo encuentra Zapatos. Selecciona también las subcategorías, o haz que el filtro incluya los hijos en las taxonomías que elijas:

// Child theme functions.php or a code snippets plugin.
// BEAR: filtering by a parent term also finds products of its child terms.
add_filter( 'woobe_filter_include_children', function ( $include, $taxonomy ) {
    if ( in_array( $taxonomy, array( 'product_cat' ), true ) ) {
        return true;
    }
    return $include;
}, 10, 2 );

La búsqueda EXACTO necesita el título completo

Los comportamientos de la búsqueda de texto son CONTIENE (LIKE), EXACTO (EXACT), NO (NOT), EMPIEZA POR (BEGIN) y TERMINA EN (END). EXACTO compara con el título completo, sin distinguir mayúsculas y minúsculas: una palabra de un título de cinco palabras no encuentra nada. Usa CONTIENE para parte de un título. Para buscar varios textos a la vez, consulta varios títulos en el cuadro de búsqueda.

Un precio normal exacto no encuentra nada

En el rango del precio normal, el valor inferior está incluido y el superior está excluido, de modo que 46.90 a 46.90 es un rango vacío. Introduce 46.90 a 46.91. También se buscan los precios de las variaciones: un producto variable aparece cuando una de sus variaciones está dentro del rango.

Destacado es un campo, no una clave meta

WooCommerce no guarda Destacado (Featured) en los metadatos del post, así que un campo meta personalizado añadido en la pestaña Campos meta (Meta Fields) con un nombre como featured no encuentra nada y puede romper el filtro en el que se usa. Elimina ese campo y activa en su lugar la columna destacado integrada en Ajustes.

Temas y plugins que cambian las consultas de productos

BEAR selecciona los productos con una consulta normal de WordPress, así que cualquier código que cambie las consultas de productos en el administrador o en peticiones AJAX cambia también los resultados del editor. Los temas que fuerzan su propia ordenación de productos por defecto, los plugins de búsqueda que reescriben la búsqueda de productos y los plugins de transliteración que alteran el texto de las consultas han hecho que el filtro devuelva todo el catálogo o productos aleatorios. Abre la consola del navegador (F12) en la página del editor y comprueba primero si hay errores en rojo. Después vuelve a poner la ordenación de productos por defecto de WooCommerce en una estándar y prueba, o encuentra el plugin con el método de aislar plugins durante las ediciones masivas, que además puede mantener a ese plugin alejado de forma permanente de las peticiones de BEAR.

Lista de comprobación: confirma que el filtro se mantiene

BEAR está actualizado a la versión actual, y Almacenamiento del plugin está en Opción (recomendado).
No queda ningún fragmento woobe_storage_type en el tema, el tema hijo, los mu-plugins ni un plugin de fragmentos, salvo que devuelva 'option'.
Recarga la página del editor, aplica un filtro y anota el recuento bajo la tabla.
Ve a la página 2, cambia las filas por página, haz clic en una columna para ordenar y activa y desactiva variaciones. El recuento debe seguir siendo el mismo.
Marca dos productos, ejecuta una pequeña edición masiva sobre ellos y comprueba el registro en el Historial. Después ejecuta la operación real sobre el filtro.

Si el recuento sigue cambiando con Opción seleccionada y sin ningún fragmento, abre un tema en el foro de soporte de BEAR con la versión de BEAR, los plugins de caché y de caché de objetos que usas y los dos recuentos que ves.