Solucionar problemas
PrestaShop, tamaño excesivo de la tabla layered_filter_block
La tabla PREFIX_layered_filter_block es la caché de consultas del módulo Búsqueda por facetas (ps_facetedsearch). Usa el prefijo real de la instalación: no siempre es ps_.
Antes de limpiar, comprueba en phpMyAdmin el tamaño de cada tabla y mide su variación. Las claves de caché dependen de las consultas, filtros y contextos de tienda, idioma, moneda y país realmente solicitados; el tamaño del catálogo por sí solo no demuestra el origen del crecimiento.
La caché se introdujo en ps_facetedsearch 3.x, no en una versión concreta del núcleo PrestaShop. Las tasas de crecimiento publicadas corresponden a casos particulares y no deben usarse como valor esperado para todas las tiendas.
Actualización de seguridad:
ps_facetedsearch3.0.0 a 4.0.3 está afectado por GHSA-m5f5-28qr-9g9r. Actualiza a 4.0.4 o posterior antes de limpiar o automatizar la caché. Si la tienda ejecutó una versión afectada, conserva registros y solicita una revisión de integridad; vaciar la tabla no demuestra que la instalación esté limpia.
Limpiar la caché medida
En Módulos > Gestor de módulos > Búsqueda por facetas > Configurar, usa Clear cache. Esta acción vacía PREFIX_layered_filter_block.
PREFIX_layered_price_index es un índice distinto. Reconstrúyelo solo si está incompleto o desactualizado y dentro de una ventana de mantenimiento; limpiar la caché de bloques no obliga por sí solo a regenerar los índices. En InnoDB, reducir el tamaño lógico tampoco garantiza que el fichero físico del tablespace disminuya.
Valida filtros, precios, idiomas y monedas después de la limpieza. Vuelve a medir la tabla para confirmar que era la que crecía.
Automatizar solo si vuelve a crecer
Si has confirmado un crecimiento recurrente, copia la URL específica Flush block cache que muestra el apartado cron del módulo. No copies el enlace AJAX del botón ni construyas la URL manualmente. El token concede acceso a la tarea: trátalo como una credencial y no lo publiques.
curl --fail --silent --show-error --max-time 300 "URL_FLUSH_BLOCK_CACHE" >> /home/usuario_cpanel/logs/prestashop-facetas.log 2>&1
Define la frecuencia a partir de las mediciones y conserva el log durante las primeras ejecuciones. Un cron que falla en silencio no controla el crecimiento ni sustituye la investigación del tráfico o configuración que genera tantas claves.
Comprobar la tarea y el crecimiento
Antes de programar el ejemplo, crea un directorio de logs privado fuera de la raíz de la web y sustituye la URL y el usuario. La URL puede contener un token visible en la tarea programada y en herramientas de procesos; limita el acceso a esa configuración.
Una salida correcta de curl no demuestra que el módulo haya vaciado la caché: una redirección o una página de error con código 200 puede parecer una petición correcta. Revisa el cuerpo de la respuesta y compara el tamaño o recuento de la tabla antes y después.
Evita ejecuciones solapadas y ajusta frecuencia y conservación del log. Si las claves se regeneran enseguida, revisa peticiones, filtros y contextos antes de aumentar la frecuencia de borrado; una caché constantemente vacía puede elevar el coste de navegación.
También te puede ayudar
- Error "Argument X passed OrderProductForViewing must be of the type string" Identifica el argumento y la fila exactos que entregan NULL al visualizar un pedido de PrestaShop, s...
- Error "Shop not found at line xxx in file classes/shop/Shop.php" Localiza Shop not found revisando la URL solicitada, shop_url y el ámbito de PS_SHOP_DEFAULT antes d...
- Error SQLSTATE 2026 al instalar o actualizar PrestaShop Diagnostica la conexión SSL con MySQL que impide a Doctrine consultar la versión del servidor, sin c...
- Error de zonas horarias de GLPI con MariaDB o MySQL Distingue entre datos de zonas horarias no cargados y el permiso que solo requieren versiones de GLP...
¿Algo no cuadra o ha cambiado? Cuéntanoslo y lo revisamos.