Entorno de pruebas para PrestaShop: cómo montar una copia que no moleste a nadie

Probar los cambios en una copia de la tienda antes de llevarlos a producción es de lo más sensato que puedes hacer. Pero una copia es, por definición, una tienda completa: tiene los mismos clientes, la misma configuración de correo, las mismas claves de las pasarelas y las mismas tareas programadas. Si no la desconectas bien, hace exactamente lo mismo que la tienda real, y eso incluye escribir a tus clientes.

Este artículo es una lista de lo que hay que neutralizar en una copia de pruebas, en el orden en que conviene hacerlo.

Dónde montarla

Hay tres opciones habituales, con sus ventajas:

• En local, en el ordenador del desarrollador o en un servidor interno. Es la más segura, porque no es accesible desde Internet, pero cuesta más compartirla con quien tiene que revisar.
• En un subdominio del mismo hosting. Es cómoda, pero comparte servidor con la tienda real: una prueba pesada (una importación, una regeneración de imágenes) le quita recursos a producción.
• En un servidor aparte, con la misma versión de PHP y la misma configuración que producción. Es lo ideal para ensayar actualizaciones, porque las diferencias de entorno no te engañan.

Sea cual sea, la copia debe tener la misma versión de PHP que la tienda real, salvo que precisamente estés probando un cambio de PHP.

Paso 1: el correo, lo primero

Antes incluso de abrir la copia en el navegador, corta el correo. Una copia recién importada tiene la configuración SMTP de producción y la base de datos con clientes reales. Un cambio de estado de un pedido, un carrito abandonado que un módulo decide recordar o una tarea programada que envía boletines bastan para escribirle a una persona de verdad desde tu entorno de pruebas.

Opciones, de más a menos recomendable:

• Capturar el correo con un servidor SMTP de pruebas que recibe todos los mensajes y los muestra en una bandeja web sin entregarlos. Así puedes revisar cómo quedan los correos sin riesgo.
• Desactivar el envío en Parámetros avanzados → Correo electrónico, con la opción de no enviar nunca correos. Es rápido, pero no te deja ver los correos.

Paso 2: datos personales anonimizados

Una copia de pruebas no necesita los nombres, correos, teléfonos y direcciones reales de tus clientes. Y tenerlos en un entorno menos protegido que producción es un riesgo de protección de datos. Sustituye, como mínimo:

• Correos de clientes por direcciones ficticias de un dominio que no exista o que controles tú.
• Nombres, apellidos, teléfonos y direcciones de clientes y de direcciones de envío.
• Mensajes de clientes, notas internas y datos de empresa como el NIF.
• Suscriptores de boletín y cualquier tabla de módulos que guarde datos personales: formularios, reseñas, listas de deseos.

Conserva los pedidos, importes y productos: son los que necesitas para probar. Y cambia las contraseñas de los empleados por otras distintas a las de producción.

Paso 3: pagos en modo de pruebas

Cada pasarela tiene un modo de pruebas con sus propias claves. En la copia, cambia todas a ese modo antes de hacer el primer pedido. Revisa en concreto:

• Claves de producción de la pasarela: sustitúyelas por las de pruebas, no te limites a marcar una casilla si el módulo usa las claves que tenga guardadas.
• Webhooks y notificaciones: la pasarela de verdad sigue enviando sus avisos a la URL de producción, y eso está bien. Lo que no debe pasar es que la copia registre un webhook nuevo apuntando a sí misma en la cuenta real.
• Transferencia y contra reembolso: no cobran, pero generan correos al cliente con instrucciones. Ya están cubiertos si el correo está capturado.

Paso 4: que nadie la encuentre

Una copia accesible desde Internet acaba indexada si no lo impides, y entonces compite con tu propia tienda en Google con el mismo contenido.

• Protección con contraseña en el servidor web (autenticación básica). Es lo más eficaz: ni buscadores ni curiosos pasan de la primera pantalla.
• Cabecera noindex en todas las respuestas, como segunda capa.
• Modo mantenimiento de PrestaShop con tu IP permitida, si no puedes poner contraseña.

No confíes solo en el robots.txt: le pide a los buscadores que no rastreen, pero no impide que una URL enlazada desde algún sitio aparezca en los resultados.

Paso 5: las conexiones con el exterior

Aquí es donde más sorpresas hay, porque cada tienda tiene las suyas:

• Tareas programadas. Si copias también el crontab, la copia ejecutará las mismas tareas: exportaciones al ERP, sincronizaciones con marketplaces, envíos de boletines. Desactívalas y actívalas una a una solo si vas a probarlas.
• ERP y almacén. Un conector que crea pedidos o actualiza stock en el ERP real es peligroso desde una copia: puede duplicar pedidos o pisar el stock con datos de pruebas.
• Marketplaces y feeds. Un módulo que publica productos o sincroniza stock con un marketplace usará las credenciales reales.
• Píxeles de seguimiento y analítica. Las visitas de la copia ensucian las estadísticas de la tienda real y pueden enviar conversiones falsas a las plataformas de publicidad.
• Transportistas. Algunos módulos generan etiquetas o solicitan recogidas a través de la API del transportista.

Paso 6: el dominio

PrestaShop guarda el dominio de la tienda en la base de datos (en la tabla de URLs de la tienda y en la configuración). Si no lo cambias, la copia redirige a la tienda real en cuanto la abres. Tras cambiarlo, vacía la caché y regenera el fichero de URLs amigables. Busca también el dominio antiguo en la configuración de módulos y en contenidos CMS: un enlace absoluto a producción dentro de la copia puede hacerte creer que estás probando una cosa cuando estás mirando otra.

Comprobación antes de trabajar

1. Haz un pedido de prueba y comprueba que el correo aparece capturado y no sale.
2. Busca en la base de datos algún correo real de cliente: no debería quedar ninguno.
3. Abre la copia sin sesión desde otro navegador: debe pedir contraseña o mostrar mantenimiento.
4. Revisa qué tareas programadas hay activas y qué módulos tienen credenciales de servicios externos.

Una copia así es una herramienta que puedes usar sin miedo para cada actualización, cada módulo nuevo y cada cambio del tema, y es la base para mantener la tienda al día sin que tus clientes sean los que prueban.

Cómo resolverlo en PrestaShop

En Rekire trabajamos siempre sobre copias de este tipo: correo capturado, datos anonimizados, pasarelas en modo de pruebas y conexiones externas cortadas. Con un bono de horas de soporte te montamos la copia de tu tienda y la dejamos lista para ensayar actualizaciones y cambios, o hacemos nosotros esos cambios en ella antes de llevarlos a producción. Si además buscas un alojamiento pensado para PrestaShop, el Hosting plan profesional de Rekire es nuestra propuesta para tiendas que quieren despreocuparse del servidor.