DataFirefly Cleanup — Guía completa
Instalación, seis limpiadores, modos auditoría/dry-run/ejecución, tarea cron y solución de problemas del módulo de limpieza de base PrestaShop.
Presentación
DataFirefly Cleanup es un módulo de administración para PrestaShop 8 y 9 que limpia su base de datos con total seguridad: estadísticas obsoletas, carritos abandonados, logs antiguos, búsquedas caducadas, metadatos huérfanos e imágenes huérfanas. Cada limpiador ofrece tres modos — auditoría, dry-run y ejecución — y el módulo calcula la ganancia de espacio en MB antes de cualquier acción.
El módulo no modifica ni su tema ni los archivos del núcleo de PrestaShop. Crea una sola tabla (el historial de limpiezas) y una pestaña de administración.
Instalación
- Descargue el archivo
dfcleanup.zipdesde su cuenta DataFirefly. - En su back office de PrestaShop, vaya a Módulos > Gestor de módulos > Subir un módulo.
- Arrastre el ZIP o selecciónelo. La instalación crea la tabla de historial, la pestaña de admin y el token cron.
- Abra Parámetros avanzados > DataFirefly Cleanup.
Requisitos: PrestaShop 8.0+ o 9.0+, PHP 8.0+, MySQL 5.7+ o MariaDB 10.3+.
El panel de control
La pantalla principal muestra tres bloques de información en la cabecera:
- Tamaño de la base — el espacio total ocupado por sus tablas (datos + índices), calculado vía
information_schema. - Ganancia potencial — la estimación del espacio recuperable si se ejecutaran todos los limpiadores.
- Porcentaje recuperable — el ratio entre ambos.
Debajo, el top 10 de las tablas más grandes le muestra a dónde va realmente su espacio en disco. Las tablas de estadísticas (ps_connections, ps_page_viewed) casi siempre encabezan la lista en una tienda activa.
Los seis limpiadores
Estadísticas
Limpia ps_connections (y sus tablas hijas connections_page y connections_source), ps_page_viewed, ps_referrer_cache, ps_pagenotfound y los guests huérfanos. Retención por defecto: 90 días. Suele ser el limpiador con mayor ganancia — las tablas de estadísticas crecen con cada visita.
Carritos abandonados
Elimina los carritos sin pedido asociado más antiguos que la retención (30 días por defecto), además de las filas huérfanas de cart_product y cart_cart_rule, y las reglas de carrito expiradas.
Un carrito convertido en pedido nunca se elimina: cada consulta verifica la ausencia de pedido mediante una unión con ps_orders. Sus datos de pedidos son intocables.
Logs de aplicación
Poda ps_log con retención ponderada por severidad: las entradas informativas y las advertencias (severidad 1-2) se eliminan tras la retención configurada (30 días por defecto), mientras que los errores y errores críticos (severidad 3-4) se conservan el doble de tiempo.
Búsquedas obsoletas
Limpia el historial ps_statssearch (60 días por defecto) y las filas huérfanas del índice de búsqueda (search_index, search_word) que apuntan a productos eliminados.
Metadatos huérfanos
Apunta a las filas cuyo padre ya no existe: product_lang, product_shop, product_attribute, category_product, stock_available, specific_price, customization, direcciones soft-deleted sin pedido, image_lang e image_shop. Sin noción de retención aquí: un huérfano es un huérfano.
Imágenes huérfanas
Dos partes: las entradas ps_image cuyo producto ya no existe (siempre activo), y un escaneo del sistema de archivos opcional que recorre la carpeta de imágenes de producto buscando archivos JPG sin entrada en base de datos. El escaneo está limitado a 200.000 archivos por seguridad.
Los tres modos
| Modo | Escritura en base | Uso |
|---|---|---|
| Auditoría | Ninguna | Contar las filas afectadas y estimar la ganancia. Ejecutar siempre primero. |
| Dry-run | Solo historial | Simular la ejecución y guardar una traza fechada del alcance. |
| Ejecución | Eliminación real | Eliminar en lotes de 5.000 filas (configurable), con micro-pausas entre lotes. |
Antes de cualquier Ejecución: haga una copia de seguridad de su base. La limpieza es irreversible. Flujo recomendado: Auditoría → Dry-run → Backup → Ejecución → OPTIMIZE TABLE.
OPTIMIZE TABLE
Eliminar filas no devuelve inmediatamente el espacio al sistema: InnoDB conserva el espacio dentro del archivo de tabla. La casilla OPTIMIZE TABLE tras la ejecución reconstruye las tablas limpiadas para devolver el espacio físico al disco (requiere innodb_file_per_table, activado por defecto en instalaciones modernas). Resérvelo para horas de poco tráfico: la operación bloquea brevemente cada tabla.
Tarea cron
El panel Limpieza programada (cron) del dashboard le permite automatizar las limpiezas.
Configuración
- Activar el cron — interruptor global. Desactivado, el endpoint responde 503 incluso con un token válido.
- Modo — auditoría, dry-run (por defecto, sin riesgo), ejecución, o ejecución + OPTIMIZE.
- Limpiadores a ejecutar — casillas. Por defecto: stats, cart, log, search. Metadata e image son opt-in.
URL y token
El endpoint público es /module/dfcleanup/cron?token=SU_TOKEN. El token (32 caracteres hexadecimales) se genera en la instalación y se verifica en tiempo constante. El botón Regenerar token invalida inmediatamente la URL antigua.
Planificación
Dos opciones:
- Módulo cronjobs de PrestaShop — si está instalado, la tarea se registra automáticamente allí (hook
actionRetrieveCronJobs), programada a las 3:00 cada día. Modifique el horario desde la configuración del módulo cronjobs. - Crontab del sistema — copie la línea mostrada en el admin:
0 3 * * * /usr/bin/curl -s 'https://su-tienda.com/module/dfcleanup/cron?token=XXXX' > /dev/null 2>&1Sobrecargas puntuales
Puede sobrecargar el modo y los limpiadores para una llamada concreta, sin tocar la configuración:
?token=XXXX&mode=audit
?token=XXXX&mode=execute&cleaners=stats,logEl botón Ejecutar cron ahora ejecuta inmediatamente la configuración actual — práctico para probar sin esperar al siguiente tick.
Ajustes
- Tamaño de lote — filas eliminadas por consulta (por defecto 5.000, mín 100, máx 100.000). Redúzcalo en hosting compartido limitado, auméntelo en un servidor dedicado potente.
- Retención del historial — duración de conservación de las entradas del historial del módulo (180 días por defecto).
- Retención por limpiador — en días. 0 = desactiva el filtro temporal (los limpiadores de huérfanos ignoran este ajuste).
Historial
Cada acción (auditoría, dry-run, ejecución — manual o cron) queda registrada: limpiador, modo, filas afectadas, bytes liberados, detalle por tabla en JSON, operador (email admin, cron o cron (manual)), fecha. La tabla de historial se purga automáticamente según la retención configurada.
Solución de problemas
Timeout en eliminaciones grandes
El módulo desactiva el límite de tiempo de PHP durante la ejecución, pero algunos hosts imponen límites a nivel del servidor web. En ese caso, reduzca el tamaño de lote, ejecute limpiador por limpiador, o use el cron vía CLI (curl desde crontab no está sujeto a los límites del servidor web).
El endpoint cron responde 403
El token proporcionado no coincide. Verifique que la URL de su crontab está actualizada — un token regenerado invalida la URL antigua.
El endpoint cron responde 503
El cron está desactivado en los ajustes del módulo. Actívelo desde el panel Limpieza programada.
La ganancia mostrada difiere del espacio realmente liberado
La ganancia es una estimación proporcional (filas_eliminadas / filas_totales × tamaño_tabla). El espacio real devuelto al disco depende de OPTIMIZE TABLE y de la fragmentación. La estimación es deliberadamente conservadora.
Notas técnicas
- El módulo usa detección de esquema defensiva (
tableExists/columnExistsvíainformation_schema): se adapta a las diferencias PS 8 / PS 9 e ignora las tablas ausentes. - Las eliminaciones single-table se ejecutan por lotes con
LIMIT; las eliminaciones multi-tabla (uniones) se ejecutan en una sola sentencia, ya que MySQL no permiteLIMITen esa sintaxis. - El token cron se compara vía
hash_equals(tiempo constante) para resistir ataques por temporización. - Compatible multi-tienda. Interfaz en FR/EN/ES/DE.