# DataFirefly Cleanup — Guía completa > 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,… - Página: - Idioma: es - Actualizado el: 2026-07-02 - Otros idiomas: [fr](https://www.datafirefly.com/documentation/dfcleanup/index.md), [en](https://www.datafirefly.com/en/documentation/dfcleanup/index.md), [de](https://www.datafirefly.com/de/documentation/dfcleanup/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfcleanup/index.md), [it](https://www.datafirefly.com/it/documentation/dfcleanup/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfcleanup/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfcleanup/index.md) - Índice: ## 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 1. Descargue el archivo `dfcleanup.zip` desde su cuenta DataFirefly. 2. En su back office de PrestaShop, vaya a **Módulos > Gestor de módulos > Subir un módulo**. 3. Arrastre el ZIP o selecciónelo. La instalación crea la tabla de historial, la pestaña de admin y el token cron. 4. 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: 1. **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. 2. **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>&1 ``` ### Sobrecargas 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,log ``` El 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` / `columnExists` vía `information_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 permite `LIMIT` en 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.