En Kinsta, cada sitio puede tener 1 Entorno Staging Estándar y hasta 5 Entornos Staging Premium. Los entornos staging te permiten probar plugins, temas o modificaciones de código sin afectar al sitio en producción.

Kinsta ofrece la opción de empujar tu entorno de staging de WordPress a tu entorno real si estás contento con los cambios que has hecho y quieres que se apliquen a tu sitio real. Gracias a la función de Selective Push, tienes un control granular sobre lo que debes empujar en vivo.

En el pasado, empujar desde el entorno de staging al sitio en vivo era un proceso de todo o nada, en el que el entorno de staging sobrescribía completamente el sitio en vivo durante el empuje. Con Selective Push, puedes elegir qué empujar desde tu entorno de staging a tu sitio en vivo. En concreto, ahora puedes empujar:

  • sólo tus archivos,
  • sólo tu base de datos,
  • o ambos..

Se puede pasar de staging a en producción en solo unos clics, pero por favor, lee las notas que aparecen a continuación antes de proceder. Contienen información esencial sobre el proceso.

Notas Importantes

  • Recomendamos utilizar la funcionalidad de Push to Live con cuidado, iniciándola en momentos de poco tráfico y teniendo un desarrollador a mano por si acaso. Si necesitas la ayuda de un desarrollador, hay varios sitios donde puedes contratar uno.
  • Creamos una copia de seguridad de forma automática para que puedas retroceder cuando lo necesites. Nota: Si tu sitio en vivo es un sitio de comercio electrónico u otro sitio dinámico y que cambia rápidamente, los datos podrían perderse entre el momento en que se empuja y cuando se restaura la copia de seguridad.
  • Los ajustes del entorno (redirecciones, geolocalización, configuración de PHP y Nginx, etc.) se incluyen en el envío (incluso si sólo se selecciona Archivos o Base de datos) y sobrescribirán completamente los ajustes del entorno del sitio en producción.
  • Una vez que se haya completado el empuje, purga cualquier caché incorporado en tu tema o plugins, limpia la caché de tu navegador y prueba tu sitio para asegurarte de que funciona como te esperabas.
  • Cuando se empuja la base de datos, si se marca la opción de Ejecutar Búsqueda y Reemplazo, tu dominio de staging será automáticamente reemplazado por el dominio de tu sitio en vivo.
  • Seleccionando Archivos se enviarán todos los archivos, incluyendo plugins, temas y archivos dentro de wp-content/uploads.
  • Cualquier URL codificada en el código de tu tema o plugin deberá ser actualizada a la URL del sitio en vivo.
  • Si la protección por contraseña (.htpasswd) está activa en tu entorno de staging, no se trasladará al entorno real. Si necesitas configurar esto en tu sitio en vivo, tendrás que habilitarlo en el sitio en vivo.
  • Vuelve a comprobar el sitio de staging y resuelve cualquier error antes de lanzarlo al mercado.
  • Los entornos staging están pensados únicamente para el desarrollo y las pruebas. No están diseñados para ser utilizados como sitios de producción en activo, y puede haber cosas que no funcionen como se espera. Kinsta no es responsable si intentas utilizar un entorno staging para un sitio en producción.
  • El paso a producción no afecta al entorno staging, y permanecerá separado del sitio en producción. Después de pasar a producción, puedes seguir desarrollando y probando los cambios en el entorno staging sin que afecte a tu sitio en producción hasta que vuelvas a pasar los cambios a producción.
  • El traspaso a modo activo no interferirá con la CDN de Kinsta si se está ejecutando en tu sitio activo, pero te recomendamos que borres la caché de la CDN después del traspaso (Sitios de WordPress > Tu sitio > CDN > Borrar caché de la CDN).
  • Si tu sitio es una red multisitio, debes tener cuidado con el paso de la base de datos a producción. Enviar la base de datos puede o no funcionar, dependiendo de cómo esté configurado el multisitio. Si utilizas el selective push y envías la base de datos o la base de datos y los archivos, todo el contenido de la base de datos se enviará a producción y afectará a todos los sitios (el sitio principal y los subsitios) de tu red multisitio.

¿Cómo traspasar de staging a modo activo con el Selective Push?

Sigue los siguientes pasos para pasar tu entorno staging de WordPress a producción. El flujo de trabajo para el Selective push te permite elegir lo que vas a transferir de tu sitio de staging a tu sitio en vivo.

Paso 1

Accede a MyKinsta, haz clic en Sitios de WordPress y haz clic en el sitio al que quieres enviar los cambios. Utiliza el selector de Entorno junto al nombre del sitio para seleccionar el entorno staging desde el que quieres realizar el envío. Si has añadido un entorno Staging Premium, tendrás más de un entorno staging para elegir.

Cambia a un entorno staging de WordPress en MyKinsta.
Cambia a un entorno staging de WordPress en MyKinsta.

Paso 2

Una vez que estés en el entorno de staging, haz clic en el menú de Acciones del Entorno y selecciona Pasar a Producción en el menú desplegable.

Pasar de Staging a Producción en MyKinsta con Envío Selectivo.
Pasar de Staging a Producción en MyKinsta con Envío Selectivo.

Paso 3

En la ventana emergente/modal de Pasar a Producción que aparece, elige Archivos, Base de datos o marca ambos, dependiendo de lo que quieras empujar a vivo. Escribe el nombre del sitio para confirmarlo y haz clic en el botón Pasar a Producción.

Utiliza el Envío Selectivo para mover los archivos del entorno de staging a producción.
Utiliza el Envío Selectivo para mover los archivos del entorno de staging a producción.

Hay que tener en cuenta un par de cosas:

  • El tiempo necesario para completar el proceso depende del tamaño de tu sitio web.
  • MyKinsta te notificará cuando el proceso haya finalizado.
  • Tu sitio web experimentará un par de segundos de inactividad en las etapas finales del proceso.
  • Los ajustes del entorno (redirecciones, geolocalización, configuración de PHP y Nginx, etc.) se incluyen en el envío (incluso si sólo se selecciona Archivos o Base de datos) y sobrescribirán completamente los ajustes del entorno del sitio en producción.

Casos de uso y ejemplos de flujos de trabajo

A continuación te damos algunos ejemplos de cuándo puedes querer empujar sólo los archivos, sólo la base de datos o ambos. Ten en cuenta lo siguiente cuando pases del staging al sitio en vivo:

  • Los ajustes del entorno (redirecciones, geolocalización, configuración de PHP y Nginx, etc.) se incluyen en el envío (incluso si sólo se selecciona Archivos o Base de datos) y sobrescribirán completamente los ajustes del entorno del sitio en producción.

Sólo archivos push

  • Cambios realizados directamente en los archivos del tema (incluyendo HTML, CSS o PHP) que no guardan ningún dato en la base de datos.
  • Subir un archivo que no necesita ser incluido en la biblioteca de medios de WordPress.
  • Si tienes un plugin personalizado en tu sitio y haces cambios en los archivos que no afectan a la base de datos (no almacena ni altera los datos en la base de datos).

Sólo base de datos push

Nota: Se perderá cualquier cambio realizado en la base de datos del sitio real desde que se creó el sitio de staging, incluidos, entre otros, los comentarios, los nuevos contenidos, las compras en los sitios de comercio electrónico, las inscripciones en los sitios de membresía y las publicaciones en los foros.

  • Crear o editar una nueva publicación o página que no incluya ningún medio cargado (imagen, vídeo u otros archivos cargados).
  • Cambios de diseño en una página o entrada realizados a través de un plugin de construcción.
  • Cambiar el título o el eslogan del sitio.

Empujar todo

Nota: Se perderá cualquier cambio realizado en la base de datos del sitio en vivo desde que se creó el sitio de staging, incluidos, entre otros, los comentarios, el nuevo contenido, las compras en los sitios de comercio electrónico, las inscripciones en los sitios de afiliación y las publicaciones en los foros.

  • Crear nuevos contenidos que incluyan medios cargados (imagen, vídeo u otros archivos cargados).
  • Cambios en tu tema realizados tanto en el Personalizador como en los archivos del tema.
  • Instalar y probar un nuevo plugin o una versión actualizada de un plugin.

Preguntas frecuentes (FAQ)

P: Si pruebo un plugin en el entorno de staging y envío sólo los archivos al entorno en vivo, ¿se crearán las tablas de la base de datos correspondientes al plugin?

Si instalas un plugin en tu sitio de staging que nunca ha sido instalado en el sitio en vivo, al pasar sólo los archivos de staging a vivo no se crearán las tablas de la base de datos para ese plugin.

Esto también significa que cualquier ajuste que haya sido configurado en el plugin no será empujado a vivo (a menos que los ajustes se guarden en un archivo fuera de la base de datos, como en un archivo JSON, por ejemplo).

Dependiendo de cómo esté codificado el plugin, la activación (primero la desactivación si es necesario) del plugin en el sitio en vivo puede crear la estructura de la base de datos.

P: Si empujo sólo los archivos a vivo, ¿esto significa que la antigua base de datos (en staging) no sobrescribirá el vivo y sólo se sobrescribirán los archivos?

Sí, cuando se empuja sólo los archivos, esto significa que la base de datos en el sitio en vivo permanece sin cambios y sólo los archivos en el sitio de vivo se sobrescribirán.

P: ¿Esto significa que puedo trabajar en los cambios de diseño en mi sitio de staging y pasarlos a vivo sin perder nuevos suscriptores o clientes en mi sitio en vivo?

Sí, siempre y cuando los cambios se realicen sólo en los archivos (sin cambios en el panel de control de WordPress – incluyendo la configuración del plugin, el tema o el personalizador) se puede empujar con seguridad a vivo sin empujar la base de datos. Cuando empujes los cambios a vivo, selecciona Archivos y asegúrate de que la base de datos no está seleccionada.

P: ¿Puedo utilizar el push selectivo para cambiar la versión de PHP de mi sitio?

Sí, puedes utilizar el entorno de staging para probar y actualizar una nueva versión de PHP a tu entorno en producción, pero no es estrictamente necesario pasar del entorno de staging a la versión en producción para actualizar tu versión de PHP. Aquí hay un breve resumen de cómo se puede cambiar la versión de PHP sin pasar desde el staging a producción:

  1. Crea un sitio de staging.
  2. Ve al sitio de staging y cambia la versión de PHP en el sitio de staging.
  3. Si todo está bien y funciona como se espera en el sitio de staging (asegúrate de probar tu sitio a fondo), cambia la versión de PHP en el sitio en vivo.

P: He realizado cambios de CSS en el panel de control de WordPress y he enviado los archivos. ¿Por qué no veo mis cambios, incluso después de borrar toda la caché?

Dependiendo del tipo de cambio realizado y de dónde se almacene esa información, es posible que tengas que empujar la base de datos o hacer esos cambios manualmente en el sitio en vivo. Por ejemplo, si has añadido o editado CSS en un bloque o widget en el panel de control de WordPress, probablemente se guardará en la base de datos.

Si realizas cambios en el panel de control de WordPress, a excepción de los cambios realizados con el Editor de temas (Apariencia > Editor de temas), esa información suele guardarse en la base de datos.

Nota: Cualquier cambio realizado en la base de datos del sitio real desde que se creó el sitio de staging se perderá, incluidos, entre otros, los comentarios, el nuevo contenido, las compras en los sitios de comercio electrónico, las inscripciones en los sitios de membresía y las publicaciones en los foros. En este caso, te recomendamos que hagas los mismos cambios manualmente en el sitio en vivo en lugar de empujar la base de datos.

P: ¿Cómo funciona el envío selectivo en una red de sitios múltiples?

Si utilizas el selective push para enviar sólo los archivos, funcionará bien, independientemente del tipo de red multisitio. Si envías sólo la base de datos o la base de datos y los archivos, puede o no funcionar, dependiendo de cómo esté configurado tu multisitio:

  • Si se trata de un multisitio de subdirectorios (ejemplo.com, ejemplo.com/subsitio1, ejemplo.com/subsitio2), el envío a producción funcionará como se espera.
  • Si se trata de un multisitio de subdominio (ejemplo.com, subsitio1.ejemplo.com, subsitio2.ejemplo.com), funcionará bien, siempre que los subsitios no requieran HTTPS.
  • Si se trata de un multisitio con mapeo de dominios (carga diferentes subsitios en dominios completamente diferentes, por ejemplo, ejemplo.com, ejemplo1.com, ejemplo2.com), no funcionará sin una importante configuración manual.
    • Opción 1: Desactiva el mapeo de dominios y vuelve a la configuración estándar de subdirectorios/subdominios. Ejecuta buscar y reemplazar en la base de datos manualmente.
    • Opción 2: Configura subdominios de staging para cada dominio activo, añade todos ellos al sitio de staging, y ejecuta buscar y reemplazar en la base de datos manualmente para actualizar cada dominio después de enviar de staging a producción.