Cómo impulsar los cambios de WordPress de la puesta en escena a la versión en vivo
Publicado: 2019-12-03¡Pasar de un sitio de prueba de WordPress a un sitio en vivo nunca ha sido tan fácil!
La puesta en escena es imperativa para el mantenimiento y mantenimiento del sitio web, eliminando los riesgos de probar nuevos complementos, actualizaciones, probar contenido gráfico y animado, cosas que podrían dañar, fallar y potencialmente sacar nuestro sitio fuera de línea.
En nuestra Masterclass del lunes anterior vimos lo simple que era configurar un sitio de preparación, pero eso es solo una parte del proceso de preparación. Impulsar nuestro sitio por etapas, tomar nuestro sitio web actualizado con todos sus cambios y ajustes, y colocarlo en el lugar de nuestro sitio en vivo (o de producción) es tan importante, si no más.
Para el propósito de la puesta en escena, necesitamos establecer dos tipos de sitios web de WordPress o, si lo desea, dos grupos de usuarios de Elementor, cada uno definido por el tipo de contenido utilizado en el sitio:
- Contenido generado por el propietario : sitios web que se basan únicamente en el contenido que proporcionamos nosotros, los moderadores del sitio. También conocido como contenido generado por el moderador o contenido de marca.
- Contenido generado por el usuario : sitios web que dependen, por completo o hasta cierto punto, de los datos del usuario. Esto incluye datos como información de formularios o pedidos realizados por los usuarios, así como archivos cargados, imágenes, comentarios, etc.
La razón por la que tenemos que hacer esta distinción es que necesitamos saber si debemos o no estar preocupado por los datos que fue introducido en nuestro sitio en línea, - mientras estamos trabajando en la copia de seguridad-versión de nuestro sitio, - en el aislado entorno de puesta en escena.
Pasando de la puesta en escena al sitio en vivo: contenido generado por el propietario
* Nota: Este proceso sobrescribirá cualquier dato generado por el usuario que no aparezca en el sitio de Staging, desde el sitio en vivo (incluidos comentarios, pedidos, etc.).
Si somos las únicas personas que ingresan datos en nuestro sitio, podemos evitar agregar datos mientras estamos trabajando en actualizaciones y cambios, y enviar la versión actualizada de nuestro sitio actualizado de la misma manera que lo haríamos con un sitio nuevo. .
Si esta pantalla parece familiar, debería hacerlo, porque es exactamente donde lo dejamos en nuestra última Masterclass.
Como recordará, creamos nuestro entorno de ensayo local cargando una copia de seguridad completa de nuestro sitio de WordPress en vivo, en un entorno que habíamos creado en nuestra propia computadora, utilizando la aplicación local de Flywheel. Hay otras formas de hacer esto usando Bitnami o XAMPP, pero descubrimos que esta era la más simple y, por lo tanto, la más eficiente.
Para el propósito de esta clase magistral, agregamos un menú y un encabezado para ayudar a hacer una distinción práctica entre la apariencia y la funcionalidad de la nueva versión (por etapas) del sitio y la versión anterior (en vivo).
Una vez que hayamos terminado de actualizar y probar nuestro sitio, querremos cargar nuestra nueva versión desde el entorno local al sitio en vivo. La forma más sencilla de hacerlo es mediante un complemento de migración.
Preferimos usar el más popular entre ellos, el plugin All-in-One WP Migration, e instalarlo en ambos WordPress.
Paso 1: Instale la migración WP todo en uno en entornos WordPress locales y en vivo
Instale el complemento All-in-One en nuestra instalación de WordPress de la misma manera que lo haríamos con cualquier otro complemento.
Vaya al panel de WordPress de nuestro sitio de Local Staging y, en la pestaña Complemento, haga clic en 'Agregar nuevo'.
En el cuadro de búsqueda, busque All-in-One WP Migration, descárguelo, instálelo y actívelo.
Una vez que se haya activado el complemento, aparecerá la pestaña 'Migración de WP todo en uno' en la barra de menú izquierda del panel de WordPress.
Repita este proceso para instalar All-in-One WP Migration en el panel de WordPress de su sitio Live.
Paso 2: crear un archivo de exportación desde la versión local de nuestro sitio
En la barra de menú izquierda del panel de WordPress, en la pestaña All-in-One WP Migration, haga clic en la pestaña y seleccione 'Exportar'.
En la ventana Exportar, encontrará que la configuración avanzada le permite exportar ciertos datos en lugar de todo el sitio.
Sugerimos exportar todo el sitio. Para hacer esto, haga clic en el botón Exportar y seleccione la opción Archivo en el menú desplegable.
Cuando el complemento haya terminado de preparar el archivo de exportación, aparecerá una ventana con la opción de descargarlo. Haga clic para descargar el archivo de respaldo a su computadora.
Paso 3: Enviar la copia de seguridad al sitio en vivo
Con la copia de seguridad de nuestro sitio de ensayo descargado, iremos al panel de WordPress de nuestro sitio en vivo. En la barra de menú de la izquierda, haremos clic en 'All-in-One WP Migration', pero esta vez seleccionaremos 'Importar', y en la ventana Importar, haremos clic en Importar, y desde el menú desplegable , seleccionaremos Archivo.
Localizaremos nuestro archivo exportado y haremos clic en 'abrir'. El archivo se cargará en WordPress.
Una vez que se haya completado la carga, aparecerá una advertencia para recordarnos que continuar con este proceso sobrescribirá todo en nuestro sitio en vivo (incluidos comentarios, pedidos, etc.)
Como solo estamos siguiendo este proceso para los sitios web que dependen únicamente del contenido generado por el propietario, haremos clic en 'Continuar'.
El complemento ahora instalará nuestro nuevo sitio, sobrescribiendo la versión anterior. Dependiendo del tamaño de nuestro sitio, esto puede tardar unos minutos o mucho más.
Bonificación: solo empujar ACTUALIZACIONES desde el escenario al sitio en vivo (similar a Git)
Cuando se trata de nuestra otra categoría de usuarios de WordPress y Elementor, aquellos que dependen de datos que provienen de una fuente externa, hay dos formas de enviar un sitio actualizado desde el entorno de prueba al sitio en vivo sin correr el riesgo de perder ningún dato.
Como se mencionó anteriormente, nuestra principal preocupación con los datos que vienen en forma de suscripciones de usuarios, órdenes de compra, incluso comentarios, etc., es que habrán continuado registrándose en nuestro sitio web en vivo, mientras estábamos ocupados trabajando en la versión de prueba aislada.
Un método es un procedimiento complejo que implica jugar con archivos y carpetas individuales a través de una interfaz FTP o SFTP, utilizando herramientas como C-Panel. Como tal, sentimos que correríamos el riesgo de que los lectores malinterpretaran los tediosos pasos y aplastaran accidentalmente su sitio en vivo.
Dicho esto, es extremadamente importante hacer una copia de seguridad de su sitio en vivo y sus datos antes de hacer cualquier otra cosa, independientemente de la forma que elija para impulsar su sitio. Recuerde que siempre es mejor prevenir que curar.
Impulsar cambios y actualizaciones del sitio desde un entorno de ensayo es mucho más seguro que trabajar directamente en el sitio en vivo.
Cómo hacer una copia de seguridad de los datos
Para hacer esto, puede usar el complemento Duplicator o Migrate DB, incluso All-in-One WP Migration.
Una vez que se realiza una copia de seguridad de nuestro sitio en vivo, el segundo método, la forma más segura y fácil de impulsar nuestro sitio es a través del servicio de alojamiento de nuestro sitio web.
Hay muchos servicios de alojamiento web de WordPress que también ofrecen servicios de preparación, mediante los cuales se crea un entorno completamente independiente en el servidor de alojamiento, para que podamos ejecutar todas nuestras pruebas y probar nuevas ideas.
Estos incluyen hosts como Bluehost, SiteGround, Kinsta e incluso el paquete de hospedaje premium de FlyWheel incluye esta opción y, por supuesto, publicaremos enlaces a todos estos y más en las notas del programa a continuación.
BlueHost es el más popular, porque ofrece su servicio de puesta en escena de forma gratuita.
Por otra parte, es posible que prefiera SiteGround debido a su calidad de servicio superior.
Esto es algo que debemos decidir por nosotros mismos, en función del tamaño de nuestro sitio y el volumen de tráfico. Pero también debemos considerar los ingresos que necesitaremos lograr para cubrir nuestros costos y si nuestra elección ayudará o perjudicará a nuestros objetivos comerciales.
Cuando analizamos los números, debemos apuntar a los ingresos máximos mientras mantenemos bajos nuestros gastos generales.
Aquí es donde debemos ser honestos con nosotros mismos, porque si nuestro sitio web también es nuestro medio de vida, entonces el alojamiento no es uno de esos lugares donde queremos tomar atajos, o escatimar y ahorrar. Si nuestro sitio recibe tanto tráfico que una o dos horas de inactividad lo pondrían en peligro, realmente necesitamos invertir en empresas de alojamiento.
Puesta en escena de WordPress local
Local Staging, un entorno de ensayo en nuestra propia computadora, tiene muchos beneficios, el principal de ellos es la velocidad. Trabajando localmente, veremos los resultados de las pruebas y las respuestas mucho más rápido, lo que lo convierte en el entorno perfecto para grandes revisiones y posiblemente también para compilaciones iniciales.
Si bien la preparación del host no es tan rápida como la preparación local, aún puede manejar cambios en gráficos y contenido escrito, actualizaciones y pruebas bastante bien, siempre que no sean demasiado grandes. Es ideal para pruebas y actualizaciones de rutina, especialmente si el servidor también ofrece una opción para enviar su nueva versión al sitio en vivo. El inconveniente es el precio, ya que varios servicios de alojamiento cobran tarifas adicionales por la puesta en escena. Sin embargo, esta tarifa incluye soporte que podría ahorrar mucho tiempo y dinero a largo plazo.
Servicios de puesta en escena
Los sitios anfitriones que ofrecen servicios de puesta en escena tienen características similares que nos permiten impulsar la nueva versión de nuestro sitio desde la puesta en escena a nuestros sitios en vivo, con el mínimo esfuerzo y sin preocupaciones.
En SiteGround, por ejemplo, todas las opciones de preparación se pueden encontrar en la página de gestión de preparación, a la que se puede acceder a través de la versión de cPanel de SiteGround. Aquí los usuarios tienen la opción 'Easy Push' para empujar todo el nuevo sitio sobre el antiguo sitio en vivo, prácticamente arrasándolo y eliminando todo lo que estaba allí. Alternativamente, los usuarios pueden 'Advanced Push' que compara las diferencias entre los archivos antiguos y nuevos, luego le permite seleccionar qué archivos conservar y cuáles sobrescribir. Esta solución conserva de manera eficaz los datos que nos preocupa perder mientras trabajamos en sitios de prueba.
WordPress Staging to Live Site: Conclusión
Mirando hacia atrás en esta edición en dos partes de Monday Masterclass, nos alegra haber decidido abordar el tema de la puesta en escena.
No solo nos dio la oportunidad de ayudar a los usuarios que habían estado pidiendo consejos sobre la puesta en escena, sino que gracias a los maravillosos comentarios y diálogos que generó el primer episodio, decidimos llevar este segundo episodio más allá de lo planeado y aclarar algunos de los problemas y puntos interesantes que planteaste.
Hemos revisado varias formas prácticas, utilizadas por creadores web profesionales de todo el mundo, para impulsar dos tipos diferentes de sitios web de WordPress desde el sitio de preparación local o de acogida a nuestro sitio web en vivo o de producción. Además, discutimos por qué las razones de por qué deberíamos elegir un método sobre el otro.
Al final del día, es nuestra elección como propietarios o moderadores de nuestro sitio web, dónde y en qué debemos invertir nuestro tiempo y dinero, una elección que afectará nuestro tráfico, compromiso e inevitablemente nuestros ingresos.
¿Cómo se pasa del escenario al sitio en vivo? Háganos saber en los comentarios si tiene métodos alternativos.