Cómo crear un entorno de staging para WordPress y Laravel

Todo desarrollador tiene su historia de «un cambio rápido en producción». Una actualización de plugin que dejó en blanco una tienda un viernes por la tarde. Una migración de Laravel que bloqueó una tabla en plena hora punta. Un retoque del tema que se veía bien en tu portátil y rompió el checkout en móvil. Un entorno de staging existe para que esas historias ocurran donde nadie está mirando. Pero un staging hecho con descuido provoca sus propios desastres: clientes que reciben correos de prueba, Google indexando un duplicado de tu sitio o un «promote» que sobrescribe un día de pedidos reales. Así se hace bien el staging en WordPress y Laravel.

Qué es realmente un entorno de staging

El staging es una segunda copia de un sitio en producción, sobre la misma pila de software, con sus propios archivos, su propia base de datos y su propia dirección, normalmente un subdominio como staging.example.com. Las reglas que lo hacen útil:

• La misma pila que producción. Misma versión de PHP, mismas extensiones, misma configuración del servidor web. Un staging en PHP 8.3 no te dice nada de cómo se comporta un cambio en el PHP 8.1 de producción. (Si alojas varios sitios, consulta ejecutar varias versiones de PHP por sitio.)
• Su propia base de datos. Nunca apuntes el staging a la base de datos de producción. Una prueba que borra filas borra filas reales.
• Datos recientes. Un staging copiado hace un año no reproduce los fallos de hoy. Refréscalo desde producción con regularidad.
• Aislado del mundo exterior. Sin indexación en buscadores, sin correos reales, sin claves de pago reales.

Copiar producción a staging

El movimiento básico es el mismo para cualquier aplicación PHP: copiar los archivos, copiar la base de datos y luego corregir lo que difiere.

# Archivos (excluyendo cachés y subidas grandes que no necesitas)
rsync -a --delete --exclude 'wp-content/cache' \
  /var/www/site/public_html/ /var/www/site/staging/

# Base de datos: exportar producción e importar en la base de staging
mysqldump --single-transaction site_prod | mysql site_stg

--single-transaction te da una instantánea coherente de las tablas InnoDB sin bloquear el sitio en producción mientras se exporta.

WordPress: reemplaza las URL con search-replace

WordPress guarda su propia URL en la base de datos, a menudo dentro de arrays PHP serializados (ajustes de widgets, datos de maquetadores). Un simple REPLACE() en SQL corrompe las cadenas serializadas porque la longitud guardada deja de coincidir. Usa wp-cli, que entiende la serialización:

wp --path=/var/www/site/staging search-replace \
  'https://example.com' 'https://staging.example.com' \
  --all-tables --precise --dry-run
# ¿Se ve bien? Vuelve a ejecutarlo sin --dry-run

Después asegúrate de que el wp-config.php del staging apunte a la base de staging con sus propias credenciales, y define define('WP_ENVIRONMENT_TYPE', 'staging'); para que los plugins que consultan el entorno se comporten en consecuencia.

Laravel: un .env separado

Laravel mantiene las diferencias de entorno fuera de la base de datos, lo que simplifica el staging. El staging tiene su propio .env:

APP_ENV=staging
APP_DEBUG=false
APP_URL=https://staging.example.com
DB_DATABASE=site_stg
MAIL_MAILER=log
QUEUE_CONNECTION=sync

Ejecuta primero php artisan migrate en staging. Si una migración falla o tarda diez minutos sobre una copia de datos reales, acabas de aprender lo que producción te habría enseñado por las malas. Limpia y regenera la caché de configuración (php artisan config:cache) tras editar el .env, o Laravel seguirá usando los valores antiguos.

Mantén el staging invisible e inofensivo

Aquí es donde fallan la mayoría de los stagings.

• Bloquea los buscadores. Una copia pública de tu sitio es contenido duplicado. Protege el staging con autenticación HTTP básica, que deja fuera a los rastreadores y a los curiosos a la vez. Como mínimo, envía una cabecera noindex:

add_header X-Robots-Tag "noindex, nofollow" always;

En WordPress, marca además «Disuade a los motores de búsqueda de indexar este sitio» (wp option update blog_public 0). Un Disallow en robots.txt no basta: impide el rastreo, no la indexación de enlaces encontrados en otros sitios.

• Desactiva el correo saliente. Una base de datos de tienda copiada contiene direcciones reales de clientes. Una sola ejecución de cron en staging puede enviar «tu pedido ha sido enviado» a cientos de personas. En Laravel usa MAIL_MAILER=log; en WordPress, un plugin que capture los correos o un entorno de pruebas como Mailpit.
• Cambia las claves de pago a modo de prueba. Stripe, PayPal y compañía tienen claves sandbox. El staging nunca debe tener claves reales.
• Desactiva o aísla las tareas programadas. Los cron, los workers de colas y los webhooks que hablan con terceros (sincronización de CRM, exportación a ERP) deben estar apagados o apuntar a endpoints de prueba.
• Anonimiza si puedes. Para las agencias que manejan datos de clientes, limpiar los datos personales en staging suele ser una expectativa del RGPD, no solo una cortesía.

Promover: el paso que más cuidado necesita

«Pasar staging a producción» suena a una sola acción. En realidad son dos muy distintas:

• El código y los archivos pasan de staging a producción. Suele ser seguro y es lo que quieres.
• La base de datos es donde se vuelve peligroso. Entre tu última sincronización y ahora, producción ha seguido recibiendo pedidos, comentarios, formularios y nuevos usuarios. Sobrescribir la base de producción con la copia de staging tira todo eso a la basura.

Reglas prácticas:

1. Haz copia de producción justo antes de promover. Archivos y base de datos, guardados fuera del servidor. (Consulta copias de seguridad cifradas de sitios web en S3.)
2. Promueve archivos libremente y la base de datos rara vez. Para sitios de contenido que cambian poco, una promoción completa justo después de una sincronización reciente está bien. Para tiendas y sitios de membresía, reproduce los cambios de base de datos como migraciones (Laravel) o rehaz los ajustes a mano en lugar de copiar toda la base.
3. Refresca el staging justo antes del trabajo, no semanas antes. Cuanto menor sea el intervalo entre sincronización y promoción, menos datos de producción estarán en riesgo.
4. Promueve en una franja tranquila y revisa el sitio en producción justo después: portada, checkout o inicio de sesión, registro de errores de PHP.
5. Invierte el reemplazo de URL. Si vuelves a copiar una base de WordPress, ejecuta el search-replace en sentido contrario o el sitio en producción empezará a enlazar al subdominio de staging.

Trampas habituales

• Un staging apuntado «temporalmente» a la base de datos de producción.
• Buscadores indexando el subdominio de staging porque nadie añadió autenticación ni noindex.
• Correos de prueba que llegan a clientes reales desde una tabla de pedidos copiada.
• Una versión de PHP distinta en staging, de modo que los fallos solo aparecen tras la promoción.
• Promover una base de staging desfasada y borrar en silencio una semana de pedidos.
• Olvidar actualizar el staging tras cambios en producción, de modo que las pruebas se hacen contra el pasado.
• Rutas o nombres de host de producción escritos a fuego en archivos de configuración (plugins de caché, ajustes de caché de objetos, configuración propia de Laravel), de modo que el staging escribe en silencio en la caché o el almacenamiento de producción.
• Compartir una misma base de Redis o un mismo directorio de subidas entre ambos entornos, de modo que vaciar la caché o borrar un archivo en staging afecta también al sitio en producción.

Cómo gestiona ShadowPanel el staging

ShadowPanel es un panel de control de hosting autoalojado y, en los planes Pro y Agency, cada sitio puede tener un entorno de staging:

• Creación con un clic. El panel prepara un subdominio staging. del sitio con su propia raíz de documentos y su propia base de datos dedicada, con la misma versión de PHP que producción.
• Refrescar desde producción. Una acción sobrescribe el staging con una copia reciente del sitio en producción, para que pruebes con datos actuales.
• Promover cuando esté listo. Otra acción pasa la copia de staging a producción, tras un paso de confirmación, con el registro de la última sincronización visible en el panel.
• Eliminar limpiamente. Borra el entorno de staging y su base de datos cuando el proyecto termine.
• Encaja con el resto del panel. Haz una copia bajo demanda de producción antes de promover y, en sitios WordPress, usa el WordPress Toolkit para probar primero las actualizaciones en staging. (Más sobre esa rutina en gestionar muchos sitios WordPress.)

Las partes propias de cada entorno siguen en tus manos: credenciales de staging en wp-config.php o .env, el reemplazo de URL, los ajustes de correo y pagos y la protección frente a la indexación. Dependen de tu aplicación, y la lista anterior las cubre.

En resumen

El staging es un seguro barato, siempre que sea una copia fiel que no pueda hacer daño a nadie: misma pila, su propia base de datos, datos recientes, sin indexación, sin correos reales, sin claves reales. Trata la promoción como el paso arriesgado que es: copia primero, mueve archivos libremente y mueve bases de datos solo cuando estés seguro de que no ha pasado nada nuevo en producción. ShadowPanel da a cada sitio Pro y Agency una copia de staging que puedes crear, refrescar y promover desde el panel.

curl -fsSL https://shadowpanel.de/install.sh | bash

Ver precios y descargar →