Cómo crear un sitio de staging PrestaShop

Por qué necesita un sitio de staging

Todo propietario de una tienda PrestaShop se enfrenta tarde o temprano al mismo dilema: necesita actualizar un módulo, cambiar el tema o probar una nueva funcionalidad, pero hacerlo en la tienda en producción supone el riesgo de romper algo de lo que dependen sus clientes. Un sitio de staging resuelve esto proporcionándole una copia idéntica de su tienda donde puede realizar pruebas libremente y sin consecuencias.

Si alguna vez actualizó un módulo y vio cómo su página de inicio se rompía, o instaló un nuevo tema solo para descubrir que el proceso de pago dejó de funcionar, un entorno de staging habría detectado ese problema antes de que ningún cliente lo viera.

Un sitio de staging no es un lujo: es el mínimo indispensable para gestiónar una tienda de comercio electrónico de forma profesional. El coste de una hora de inactividad durante un pico de tráfico supera con creces el esfuerzo de mantener un entorno de pruebas.

¿Qué es exactamente un sitio de staging?

Un sitio de staging es un clon completo de su tienda en producción — la misma base de datos, los mismos archivos, la misma configuración — ejecutándose en una URL separada a la que solo usted (y su equipo) pueden acceder. Se ve y se comporta exactamente igual que su tienda real, pero los clientes nunca lo ven.

Piénselo como un ensayo general. Primero prueba todo en staging, confirma que funciona y luego aplica los mismos cambios en su tienda en producción.

Lo que un sitio de staging SÍ es

• Una copia exacta de los archivos y la base de datos de su tienda en producción
• Se ejecuta en un dominio o subdominio independiente (por ejemplo, staging.yourshop.com)
• Protegido con contraseña o restringido por IP para que solo su equipo pueda acceder
• Un lugar seguro para probar actualizaciones, nuevos módulos, cambios de tema y actualizaciones de PHP

Lo que un sitio de staging NO es

• Un entorno de desarrollo para crear código personalizado desde cero (eso es un entorno de desarrollo)
• Una solución de copias de seguridad (las copias de seguridad son algo aparte — nunca confíe en el staging como su única copia de seguridad)
• Algo que se configura una vez y se olvida — necesita actualizarse periódicamente desde producción

Opción 1: Staging basado en Docker (Recomendado)

Docker es, con diferencia, la forma más limpia de ejecutar un entorno de staging para PrestaShop. Le proporciona entornos aislados y reproducibles que puede levantar y eliminar en minutos. Esto es lo que utilizamos internamente para todo nuestro desarrollo y pruebas de módulos.

Requisitos previos

• Un servidor Linux o VPS con al menos 2 GB de RAM (se recomiendan 4 GB)
• Docker y Docker Compose instalados
• Acceso SSH tanto a su servidor de producción como a su servidor de staging
• Conocimientos básicos de la línea de comandos

Paso 1: Configurar el entorno Docker

Cree un directorio para su proyecto de staging y un archivo docker-compose.yml:

mkdir ~/staging-shop && cd ~/staging-shop

cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.2
    container_name: staging-shop
    ports:
      - "8080:80"
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=root
      - DB_PASSWD=your_secure_password
    volumes:
      - ./html:/var/www/html
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: mysql:5.7
    container_name: staging-shop-db
    environment:
      - MYSQL_ROOT_PASSWORD=your_secure_password
      - MYSQL_DATABASE=prestashop
    volumes:
      - ./mysql:/var/lib/mysql
    restart: unless-stopped
EOF

Importante: Haga coincidir la versión de la imagen de PrestaShop con su versión de producción. Si está ejecutando PS 1.7.8, utilice prestashop/prestashop:1.7.8. Si es PS 8.1, utilice prestashop/prestashop:8.1.

Paso 2: Exportar la base de datos de producción

Conéctese por SSH a su servidor de producción y exporte la base de datos:

# On your production server
mysqldump -u root -p prestashop > ~/prestashop_backup.sql

# Download to your local machine / staging server
scp user@production-server:~/prestashop_backup.sql ./

Paso 3: Importar en el staging

# Start the containers
docker compose up -d

# Wait ~30 seconds for MySQL to initialize, then import
docker exec -i staging-shop-db mysql -u root -pyour_secure_password prestashop < prestashop_backup.sql

Paso 4: Copiar los archivos de producción

# Sync your production files to the staging html directory
rsync -avz --delete \
  user@production-server:/var/www/html/ \
  ./html/ \
  --exclude='var/cache/*' \
  --exclude='var/logs/*' \
  --exclude='app/config/parameters.php'

Paso 5: Actualizar la configuración

Después de la importación, actualice la URL de la tienda en la base de datos para que apunte a su dominio de staging:

docker exec -i staging-shop-db mysql -u root -pyour_secure_password prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

A continuación, actualice html/app/config/parameters.php con las credenciales de la base de datos de staging (que coincidan con su docker-compose.yml).

Por último, limpie la caché:

docker exec staging-shop rm -rf /var/www/html/var/cache/*

Opción 2: Subdominio en hosting compartido

Si utiliza hosting compartido (cPanel, Plesk, DirectAdmin), Docker no está disponible. En su lugar, creará un subdominio con su propio directorio raíz y base de datos.

Paso 1: Crear el subdominio

En su panel de hosting:

1. Vaya a Subdominios o Dominios
2. Cree staging.yourshop.com
3. Apúntelo a un nuevo directorio, por ejemplo, /home/user/staging.yourshop.com

Paso 2: Crear una nueva base de datos

En su panel de hosting:

1. Vaya a Bases de datos MySQL
2. Cree una nueva base de datos (por ejemplo, user_staging)
3. Cree o asigne un usuario con todos los privilegios sobre esa base de datos

Paso 3: Copiar archivos

Utilice SSH o el Administrador de archivos para copiar toda la instalación de PrestaShop al directorio de staging. Si dispone de acceso SSH:

cp -r /home/user/public_html/* /home/user/staging.yourshop.com/

Paso 4: Exportar e importar la base de datos

# Export production
mysqldump -u user -p production_db > ~/staging_import.sql

# Import to staging
mysql -u user -p staging_db < ~/staging_import.sql

Paso 5: Actualizar la configuración

Edite app/config/parameters.php (o config/settings.inc.php en PS 1.6) para que apunte a la base de datos de staging. Actualice las URL de la tienda en la base de datos como se muestra en la Opción 1, Paso 5.

Opción 3: Desarrollo local con XAMPP/MAMP

Para pruebas locales rápidas, XAMPP (Windows/Linux) o MAMP (macOS) funcionan bien. El proceso es similar al del hosting compartido: crear una base de datos, copiar archivos, importar el volcado y actualizar la configuración. Esta es la opción más rápida para desarrolladores individuales que solo necesitan probar un módulo rápidamente.

La desventaja es que su entorno local puede diferir del de producción (diferente versión de PHP, diferente versión de MySQL, extensiones faltantes), por lo que siempre debe realizar una prueba final en un staging basado en servidor antes de desplegar en producción.

Pasos esenciales posteriores a la configuración

Desactivar el envío de correos electrónicos

Esto es crítico. Su sitio de staging tiene una copia de la base de datos de producción, lo que significa que contiene direcciónes de correo electrónico reales de sus clientes. Si activa una confirmación de pedido o un restablecimiento de contraseña en staging, esos correos llegarán a clientes reales.

Vaya a Parámetros avanzados → Email y:

• Configure el método de envío de correos como “No enviar correos electrónicos nunca” (lo más seguro), o
• Redirija todos los correos salientes a una dirección de prueba utilizando una herramienta como Mailtrap

Desactivar las pasarelas de pago

Si su sitio de staging está conectado a procesadores de pago en producción (Stripe, PayPal), desáctívelos de inmediato. No desea que se realicen cobros accidentales en tarjetas reales. Puede:

• Desactivar todos los módulos de pago en staging, o
• Cambiarlos a modo sandbox/pruebas

Bloquear los motores de búsqueda

Evite que su sitio de staging sea indexado por los motores de búsqueda — el contenido duplicado es una pesadilla para el SEO:

• Vaya a Parámetros de la tienda → Tráfico y SEO y desactive el sitemap
• Añada un robots.txt que bloquee todos los rastreadores: User-agent: * / Disallow: /
• Mejor aún, restrinja el acceso por completo (véase a continuación)

Restringir el acceso

Su sitio de staging no debería ser accesible públicamente. Opciones:

• Lista blanca de IP mediante .htaccess: Permita solo la IP de su oficina o domicilio
• Autenticación básica HTTP: Añada una solicitud de contraseña a través de .htaccess
• Modo de mantenimiento de PrestaShop: Actívelo e incluya su IP en la lista blanca en Back Office → Parámetros de la tienda → General → Mantenimiento

Recomendamos la lista blanca de IP en .htaccess como el método más fiable — el modo de mantenimiento puede eludirse, y la autenticación básica a veces entra en conflicto con módulos que dependen intensivamente de Ajax.

Mantener el staging sincronizado

Un sitio de staging solo es útil si refleja su entorno de producción actual. Actualícelo periódicamente:

Cuándo actualizar

• Antes de cualquier actualización importante (actualización del núcleo de PrestaShop, actualización mayor de un módulo)
• Al menos una vez al mes si está desarrollando activamente
• Después de cambios significativos en el catálogo (nuevas categorías, cambios en la estructura de productos)

Script de actualización rápida (Docker)

#!/bin/bash
# refresh-staging.sh — Pull latest production data into staging

# 1. Dump production DB
ssh production "mysqldump -u root -p'PASS' prestashop" > /tmp/staging_refresh.sql

# 2. Import to staging
docker exec -i staging-shop-db mysql -u root -p'your_secure_password' prestashop < /tmp/staging_refresh.sql

# 3. Fix URLs
docker exec -i staging-shop-db mysql -u root -p'your_secure_password' prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

# 4. Sync files
rsync -avz --delete production:/var/www/html/ ./html/ --exclude='var/cache/*' --exclude='app/config/parameters.php'

# 5. Clear cache
docker exec staging-shop rm -rf /var/www/html/var/cache/*

echo "Staging refreshed."

Errores comunes que debe evitar

Usar claves API de producción en staging

Si su tienda en producción se conecta a Stripe, PayPal, API de envíos o cualquier servicio externo, esas claves API ahora también están en su sitio de staging. Cambie siempre a claves de sandbox/pruebas en staging para evitar:

• Cobrar a clientes reales desde pedidos de prueba
• Enviar solicitudes de envío reales a los transportistas
• Alcanzar límites de uso de API que afecten a su tienda en producción

Olvidarse de desactivar las tareas cron

Si su tienda en producción tiene tareas cron (recordatorios de carritos abandonados, sincronización de stock, generación de feeds), esas tareas también podrían ejecutarse en staging si las URL son similares. Desactive o comente todas las entradas cron relacionadas con el staging.

Probar con la tienda en producción abierta en otra pestaña

Si tiene sesión iniciada tanto en el back office de staging como en el de producción en el mismo navegador, las cookies pueden entrar en conflicto. Utilice un navegador diferente o una ventana de incognito para el staging.

Cuándo probar en staging vs. en producción

Resumen

Configurar un sitio de staging lleva aproximadamente una hora la primera vez. Actualizarlo toma 5 minutos una vez que tiene un script. La inversión de tiempo se amortiza la primera vez que detecta un cambio que rompe algo antes de que llegue a sus clientes.

Docker es el mejor enfoque si dispone de un VPS o un servidor dedicado. La clonación mediante subdominio funciona en hosting compartido. En cualquier caso, lo importante es que tenga algo entre sus cambios de código y sus clientes.

Si necesita ayuda para configurar un entorno de staging específicamente para probar nuestros módulos, consulte nuestro programa Pruebe antes de comprar — cada módulo incluye una demo totalmente funcional de 30 días que puede instalar en su sitio de staging para probarlo antes de comprarlo.