DataFirefly Staging Pro — Guía completa

Staging Pro crea una copia completa de tu tienda (archivos + base de datos) en una subcarpeta protegida de tu hosting actual, sin ningún timeout gracias a su motor de copia por lotes. Pruebas módulos, temas y actualizaciones con total seguridad, y luego envías tus cambios a producción tabla por tabla, con copia de seguridad automática y rollback en un clic. Esta guía cubre la instalación, la creación de un staging, las opciones de protección, el push a producción y el rollback.

Instalación

1. Descarga el archivo dfstagingpro.zip desde tu cuenta DataFirefly.
2. Back office de PrestaShop → Módulos → Subir un módulo → envía el ZIP.
3. Al instalarse, el módulo crea sus tablas df_staging_env y df_staging_log, registra sus hooks y añade la pestaña Parámetros avanzados → Staging Pro.

Cómo funciona el staging

Un entorno de staging se crea en una subcarpeta en la raíz de tu tienda (por ejemplo /staging-v2/) y usa un prefijo de tablas dedicado (por ejemplo dfs1_) en la misma base de datos que producción. Por tanto, no necesitas ni un segundo servidor, ni un nuevo acceso MySQL, ni configuración DNS.

El motor de copia trabaja por lotes de unos segundos y luego cede el control, reanudándose exactamente donde se detuvo: copia de archivos mediante una cola persistente, clonado de la base por paquetes de filas. Una tienda de varios gigabytes se clona sin errores, incluso en hosting compartido con un max_execution_time bajo.

Crear un staging

Ve a Parámetros avanzados → Staging Pro y, en el panel de creación:

1. Introduce un nombre (solo minúsculas, dígitos y guiones, por ejemplo v2). La URL del staging será tu-tienda.com/staging-v2/.
2. Elige tus opciones de protección y copia (ver más abajo).
3. Haz clic en Crear. El progreso se muestra en directo con una barra de avance.

Al final del proceso, la URL del staging y, si procede, las credenciales htpasswd aparecen en la fila del entorno.

Opciones de protección y copia

• Proteger con .htpasswd: añade una autenticación HTTP (usuario staging). La contraseña puede introducirse o generarse automáticamente, y luego se muestra en el panel.
• Desactivar e-mails: corta los e-mails salientes del staging (PS_MAIL_METHOD = 3). Sin riesgo de escribir a un cliente real.
• Desactivar pagos: desactiva y deshookea los módulos de pago conocidos en el staging.
• Omitir estadísticas: excluye de la copia las tablas grandes y no esenciales (conexiones, logs, carritos abandonados…) para una copia mucho más rápida.
• Sin datos de clientes: crea vacías en el staging las tablas de clientes, direcciones de clientes, pedidos, carritos, mensajes, invitados, newsletter y registros RGPD. Se conservan las direcciones de proveedores, fabricantes y almacenes, así como las tablas de configuración de pedidos (estados, plantillas de mensajes, estados de devolución, reglas de carrito). Ver la sección dedicada más abajo.
• Symlink de la carpeta img/: crea un enlace simbólico a las imágenes en lugar de copiarlas, para un enorme ahorro de espacio en disco.
• Modo mantenimiento: pone el staging en mantenimiento con tu IP de administración en lista blanca.

El motor de copia por lotes

La creación de un staging encadena varias etapas, cada una con su presupuesto de tiempo y reanudación automática: preparación, copia de archivos, clonado de la base de datos, reescritura de URLs, configuración y protección, y finalización. La reescritura de URLs cubre shop_url, la configuración (incluidos los valores serializados y JSON, tratados sin corrupción), así como los contenidos CMS, productos, categorías, marcas, proveedores y tiendas.

Refresh, multientorno y eliminación

• Refresh: reconstruye un staging existente desde el estado actual de producción (elimina y luego recrea la carpeta y el prefijo), en un clic.
• Multientorno: crea tantos stagings como necesites (v2, hotfix, prueba de módulos…), cada uno independiente.
• Eliminación: elimina la carpeta y las tablas de un entorno de forma presupuestada, sin timeout.

Push a producción

Una vez validadas tus pruebas, el botón Push permite enviar tus cambios a producción, tabla por tabla:

1. Haz clic en Push en la fila del entorno: aparece la lista de tablas, con el número de filas de cada una.
2. Marca exactamente las tablas a transferir.
3. Confirma. Antes de cada reemplazo, la tabla de producción correspondiente se respalda automáticamente mediante un renombrado con marca de tiempo a un prefijo dfbak{marca}_.

Las URLs se reescriben en el sentido staging → producción durante la transferencia. Las tablas críticas (shop_url, configuration, shop, sesiones y tablas del módulo) están protegidas y nunca pueden enviarse.

Rollback

El botón Rollback restaura producción desde la última copia del push, en un clic. El módulo renombra las tablas de copia dfbak…_ para que vuelvan a su lugar original.

Salvaguardas y registro

• Todas las acciones se bloquean si la tienda actual es ella misma un staging, para evitar operaciones en cascada.
• Hay un registro detallado por entorno disponible mediante el botón Logs.
• Como un robots.txt en una subcarpeta no es respetado por los motores, la verdadera protección anti-indexación se basa en la cabecera X-Robots-Tag y el meta noindex; la opción .htpasswd sigue siendo la protección más segura.

Compatibilidad y notas técnicas

• PrestaShop 8.0 a 9.x, compatible con hosting compartido y multiidioma.
• Controlador de administración legacy (sin controlador Symfony) para la compatibilidad PS8/PS9.
• Endpoints AJAX del back office mediante el 4.º argumento de getAdminLink(); renderizado JSON mediante un método dedicado.
• Staging = subcarpeta en la raíz + prefijo de tablas dfs{id}_ en la misma base MySQL.
• Copias de seguridad del push con marca de tiempo bajo el prefijo dfbak{YmdHis}_, a purgar tras la validación.

Staging sin datos de clientes

La opción Sin datos de clientes, disponible desde la versión 1.1.0, crea el staging sin ningún dato personal. Las tablas afectadas se crean con su estructura exacta, pero quedan vacías. Es la opción recomendada para confiar un staging a un proveedor externo, para una prueba de tema o de módulo que no toque el proceso de compra, y para reducir la superficie RGPD de tus entornos de prueba.

Lo que no se copia

• Clientes, grupos de clientes, hilos y mensajes de atención al cliente, sesiones de clientes, invitados y estadísticas de conexión.
• Pedidos y toda la familia asociada: detalles, historial, facturas, pagos, transportistas, reglas de carrito aplicadas, vales de devolución y devoluciones.
• Carritos, productos de los carritos, listas de deseos, mensajes, suscripciones a la newsletter, registros RGPD y registros de correos.
• Direcciones de clientes: la tabla address se copia con un filtro, solo se descartan las filas vinculadas a un cliente.

Lo que se conserva

• Direcciones de proveedores, fabricantes, almacenes y tiendas.
• Tablas de configuración de pedidos: estados de pedido y sus traducciones, plantillas de mensajes, estados de devolución, tipos de vales.
• Reglas de carrito, cupones, transportistas, impuestos y todo el catálogo.
• Empleados del back office: te conectas al staging con tus credenciales habituales.

Autenticación HTTP y hostings cPanel / LiteSpeed

Desde la versión 1.0.1, el archivo .htpasswd se genera en formato APR1-MD5 (el del comando htpasswd -m), que leen Apache, LiteSpeed y nginx. La versión 1.0.0 usaba bcrypt, que LiteSpeed (muy habitual detrás de cPanel) no sabe leer: el staging respondía entonces 404 en todas sus páginas.

El bloque de protección añade además una página de error 401 inline. En cPanel, el error 401 se redirige globalmente a /401.shtml, una página que no existe en PrestaShop: la subpetición cae en el dispatcher de producción y devuelve su página 404, de modo que el navegador nunca muestra la ventana de inicio de sesión. La página inline evita esa redirección.

Por último, la línea ErrorDocument 404 del .htaccess copiado se reescribe hacia la subcarpeta de staging: un error en el staging muestra la página 404 del staging, no la de producción.

Autocomprobación al crear

Al final de la configuración, el módulo envía una petición HEAD al robots.txt del staging, con las credenciales si la protección está activa, y después sin credenciales para comprobar que el servidor responde 401. El resultado se registra en los logs del entorno:

• 200 con credenciales y 401 sin ellas: todo correcto.
• El servidor rechaza el bloque de autenticación: el módulo retira el bloque y el .htpasswd, desactiva la opción y muestra «Ready with warning» en la fila del entorno. El staging queda entonces accesible sin contraseña; activa el modo mantenimiento.
• Código 0: el servidor no puede llamarse a sí mismo (peticiones salientes bloqueadas). Abre la URL del staging manualmente.

FAQ y resolución de problemas

¿Funciona el módulo en un hosting compartido? Sí. El motor de copia por lotes con reanudación automática evita cualquier timeout, sea cual sea el max_execution_time del servidor.

La creación se interrumpió, ¿qué hago? Reabre el panel de Staging Pro: el entorno reanuda automáticamente la copia donde se detuvo.

¿Puede el staging enviar e-mails a mis clientes? No si la opción «Desactivar e-mails» está activa (recomendado): los e-mails salientes se cortan en el staging.

Tras un push, ¿cómo lo deshago? Usa el botón Rollback, que restaura la última copia automática. Luego recuerda purgar las tablas dfbak* obsoletas.

¿Puedo crear varios stagings a la vez? Sí, el número de entornos es ilimitado y cada uno es totalmente independiente.

¿El staging responde 404 en todas partes, o no aparece la ventana de inicio de sesión? Es el síntoma corregido en 1.0.1 en hostings cPanel / LiteSpeed. Actualiza el módulo y lanza un Refresh del entorno; consulta la sección «Autenticación HTTP y hostings cPanel / LiteSpeed» más arriba.

¿Puedo crear un staging sin los datos de mis clientes? Sí, marca «Sin datos de clientes» al crearlo. Consulta la sección «Staging sin datos de clientes» más arriba.

Historial de versiones

1.1.0 (4 de septiembre de 2026)

• Nueva opción «Sin datos de clientes»: clientes, direcciones de clientes, pedidos, carritos, mensajes, invitados, newsletter y registros RGPD creados vacíos en el staging.
• Se conservan las direcciones de proveedores, fabricantes y almacenes, así como las tablas de configuración de pedidos.
• Salvaguarda de push: esas tablas se retiran de la lista y se rechazan en el servidor en un staging creado sin datos de clientes.

1.0.1 (3 de septiembre de 2026)

• Protección htpasswd: hash generado en APR1-MD5, compatible con Apache y LiteSpeed (bcrypt era rechazado en algunos hostings cPanel y dejaba el staging inaccesible).
• Ventana de inicio de sesión HTTP: página 401 inline, para los hostings que redirigen los errores 401 a una página inexistente.
• Línea ErrorDocument del .htaccess reescrita hacia la subcarpeta de staging.
• Autocomprobación al final de la creación: control HTTP del staging, retirada automática de la protección si el servidor la rechaza y aviso en el panel.

1.0.0 (11 de junio de 2026)

Primera versión pública.