¿Cómo: mover fácilmente una instalación de WordPress del desarrollo a la producción?

Hago desarrollo en una caja y uso una segunda para la producción. En este momento, simplemente vuelco la base de datos y luego busco un reemplazo para los cambios de URL; luego copie sobre los archivos e importe el nuevo SQL.

¿Hay mejores formas de hacer esto?

@ Insanity5902 : La implementación de un sitio de WordPress de una caja a otra ha sido un PITA desde el primer día que comencé a trabajar con WordPress. (A decir verdad, fue un PITA con Drupal durante 2 años antes de que comenzara con WordPress, por lo que el problema no es exclusivo de WordPress).

Me molestaba que cada vez que necesitaba mover un sitio tenía que gastar tanto esfuerzo duplicado a menudo y me impedía implementar para probar con la frecuencia que hubiera preferido. Hace unos 4-6 meses comencé a trabajar en un complemento para resolver el problema de migración de webhost y mencioné mis ideas en el foro de WP Tavern .

Avancemos rápidamente hasta hoy y lo tengo funcionando y lo llamo " WP Migrate Webhosts ". A pesar de que el complemento todavía es beta (probablemente incluso alfa) dada su pregunta, creo que estoy listo para permitir que la gente empiece a utilizarlo.

El caso de uso previsto es que:

1. primero, el desarrollador se encarga de cargar todos los temas y archivos de complementos modificados a través de FTP,
2. luego carga la base de datos MySQL de desarrollo al servidor de prueba en su totalidad y finalmente
3. luego ejecuta el complemento para migrar cualquier referencia del dominio anterior al nuevo. (Mi complemento no intenta resolver la fusión de nuevos campos de base de datos o tablas con datos en vivo; ESO es un problema mucho mayor que no estoy seguro de cómo resolver).

Puede descargar el complemento de mi sitio web y descomprimirlo en su directorio de complementos (si no sabe cómo hacer esto, entonces este complemento no es para usted porque requiere que alguien que sepa lo que está haciendo lo use). mantenga este complemento en línea hasta que lo publique en WordPress.org, luego de lo cual debe buscarlo allí.

Para usarlo se toma un enfoque diferente en su wp-config.phpeso normal comentando los cuatro (4) define DB_NAME, DB_USER, DB_PASSWORDy DB_HOSTy en lugar de registrar los valores predeterminados para los servicios de alojamiento web y luego registrar información sobre cada servicio de hosting propio. Así es como wp-config.phppodría verse ese segmento (tenga en cuenta que la primera sección es el código innecesario comentado y también tenga en cuenta que configuré mi archivo de hosts en mi máquina local con .devdominios de nivel superior no enrutables para facilitar el desarrollo diario. En Mac, VirtualHostX lo hace muy fácil):

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
//define('DB_NAME', 'wp30');

/** MySQL database username */
//define('DB_USER', 'wp30_anon');

/** MySQL database password */
//define('DB_PASSWORD', '12345');

/** MySQL hostname */
//define('DB_HOST', '127.0.0.1:3306');

require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/wp-webhosts.php');
register_webhost_defaults(array(
 'database'  => 'example_db',
 'user'      => 'example_user',
 'password'  => '12345',
 'host'      => 'localhost',
 'sitepath'  => '',        // '' if WordPress is installed in the root
));
register_webhost('dev',array(
 'name'      => 'Example Local Development',
 'host'      => '127.0.0.1:3306',
 'domain'    => 'example.dev',
 'rootdir'   => '/Users/mikeschinkel/Sites/example/trunk',
));
register_webhost('test',array(
 'name'      => 'Example Test Server',
 'rootdir'   => '/home/example/public_html/test',
 'domain'    => 'test.example.com',
));
register_webhost('stage',array(
 'name'      => 'Example Staging Server',
 'rootdir'   => '/home/example/public_html/stage',
 'domain'    => 'stage.example.com',
));
register_webhost('live',array(
 'name'      => 'Example Live Site',
 'rootdir'   => '/home/example/public_html/',
 'password'  => '%asd59kar12*fr',
 'domain'    => 'www.example.com',
));
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/set-webhost.php');

Esperemos que esto (en su mayoría) se explique por sí mismo. Intenté hacer el código lo más limpio posible, pero desafortunadamente requiere esas dos require_once()líneas crípticas antes y después del bloque del código de registro de webhost, ya que no había forma de " enganchar " WordPress antes de que wp-config.phpse llamara.

Una vez que haya actualizado su wp-config.php, simplemente puede usar el acceso directo de URL wp-migrate-webhostspara ir a la pantalla de administración de la siguiente manera:

http://example.com/wp-migrate-webhosts

Lo anterior lo llevará a una pantalla de administración como la siguiente, que tiene un poco de texto descriptivo y le permite migrar DESDE cualquiera de los otros dominios de webhost con un solo clic después de seleccionar los dominios para migrar ( NOTA : este ejemplo muestra que va ABAJO desde / etapa de servidores de prueba / en vivo con el desarrollo local, pero puede estar seguro de que puede migrar a cualquier dominio en el que pasa a estar ubicado. Esto también significa que el plugin será muy bueno para tomar un sitio en producción existente y obtener rápidamente un entorno de desarrollo local que trabaja! ):

Si no está claro, " migración " en este contexto significa actualizar todas las referencias en la base de datos actual para que sean apropiadas para el servidor web actualmente definido (y " actual " se detecta mediante la inspección $_SERVER['SERVER_NAME']).

Lo bueno del complemento es que implementa algunas migraciones básicas, pero cualquiera puede conectarlo y realizar sus propias migraciones . Por ejemplo, si se agrega una galería plugin que almacena las rutas completas a las imágenes en la base de datos se podría enganchar la migrate_webhostsacción que se aprobó la " del servicio de hosting" y la " a " servicio de hosting cada uno como un conjunto de metadatos y se le permitió para realizar lo que necesite hacer en la base de datos utilizando SQL o cualquier función API de WordPress aplicable para realizar la migración. Sí, cualquiera de nosotros podría hacer esto sin el complemento, pero sin el complemento descubrí que escribir todo el código necesario era más esfuerzo de lo que valía la pena. Con el complemento es más fácil escribir estos pequeños ganchos y acabar de una vez.

También puede encontrar que mis migraciones fallan en casos extremos que no he probado y tal vez pueda ayudarme a mejorar el complemento. Cualquier persona que quiera puede enviarme un correo electrónico a través de mi cuenta de Gmail (mi alias es "mikeschinkel").

Además, el plugin fue diseñado para aceptar los metadatos de hosting fácil de definir, además de los que reconozca como database, user, password, host, domainetc. Un ejemplo perfecto podría ser googlemaps_apikeydonde se puede almacenar a las diferentes claves de la API para cada dominio que las necesidades de plug-in de su Google Mapa para operar correctamente (¿quién de ustedes que ha utilizado un complemento de Google Maps no ha implementado una aplicación en un servidor en vivo y se olvidó de cambiar el código a la clave API correcta? Vamos, sea honesto ... :) Con este complemento, ¡un googlemaps_apikeyelemento en su matriz register_webhost () y un pequeño migrate_webhostsenlace personalizado que puede eliminar efectivamente como una preocupación!

Bueno, eso es todo. Estoy lanzando este complemento aquí en el Intercambio de respuestas de WordPress porque la pregunta de @ Insanity5902 lo activó. Avíseme si es útil, aquí si corresponde o por correo electrónico si no.

PD: si decide usar esto, recuerde que es alfa / beta y eso significa que cambiará, así que prepárese para una cirugía menor si desea usarlo de vez en cuando y luego use la versión lanzada una vez que haya sido golpeada por muchas manos.

PPS ¿Cuáles son mis objetivos con esto? Me encanta ver que esto migre al núcleo de WordPress para que todos tengan acceso a él. Pero antes de que eso pueda considerarse, muchas personas tienen que estar interesadas en usarlo para asegurarse de que realmente resuelva más problemas de los que potencialmente podría crear. Entonces, si te gusta la idea, úsala y ayúdame a ganar impulso para una eventual inclusión esperanzada en el núcleo de WordPress.

Cuando es posible, configuro WP_HOMEy WP_SITEURLentro wp-config.php. Esto, combinado con un volcado e importación de la base de datos, es la más simple de todas las soluciones con las que estoy familiarizado.

http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php

Mi truco favorito agregue una configuración a su /etc/hostspara hacer que el dominio de producción apunte a su cuadro de desarrollo, solo en su máquina. Para implementar en producción, sincronice todos los archivos y empuje la base de datos.

Los riesgos de esta estrategia son claros; puede confundir su entorno de desarrollo con su entorno de producción.

Sin embargo, sigue siendo una solución fácil.

Quería algo similar cuando migré a WP hace unos meses, así que escribí un script de shell bastante simple que usa rsync y mysqldump sobre ssh:

http://snarfed.org/sync_wordpress

No es sofisticado ni está basado en la web, pero estoy contento con eso.

WP Engine es un nuevo servicio que ofrece "Puesta en escena con un clic":

WPEngine tiene una característica exclusiva llamada "puesta en escena". Así es como funciona: antes de hacer un cambio aterrador en su blog, haga clic en el botón "instantánea". Hacemos una copia completa de su blog y lo configuramos en un área separada y segura. Puedes jugar con lo que quieras; Nada está vivo. Solo cuando esté listo para hacerlo en vivo, toque su sitio principal.

Parece una forma muy fácil de pasar rápidamente del desarrollo a la producción, especialmente con un sitio ya en vivo.

Complemento Duplicador: Aquí hay un complemento en el que he estado trabajando. Actualmente está en versión beta, pero hace el trabajo para la mayoría de los sitios. En este momento está dirigido a instalaciones de WordPress más pequeñas. http://wordpress.org/extend/plugins/duplicator/

Recursos: Puede encontrar recursos adicionales para el complemento aquí: http://lifeinthegrid.com/duplicator/

Comunidad: ¡Cuéntanos sobre tus éxitos o cualquier problema que puedas encontrar! En un esfuerzo por administrar más fácilmente los diversos hilos, publique problemas en los foros de plugins de WordPress.org. No publique ningún dato de registro del complemento en los foros en línea. Los datos de registro se pueden enviar a nuestro sitio de soporte.

Puede echar un vistazo a un producto de iThemes, llamado BackUpBuddy . Solo lo he usado dos veces, cada vez tuve un problema o dos, pero en general parece prometedor.

Estoy abordando personalmente este problema con mi proyecto en Github, llamado Autopress . Todavía no tengo una solución perfecta, pero me estoy acercando, especialmente con el complemento wpstage de la gente de wpengine.

Esto parece prometedor. Estamos trabajando en algunos scripts para manejar la migración de algunos de los datos, por ejemplo, wp-options, cambiando las rutas en la base de datos, una copia a través de los medios.

El problema que tengo es que el sitio en vivo continúa creciendo mientras el otro está en desarrollo. Un sitio en el que trabajamos tiene 20 publicaciones por día y más de 3.000 comentarios por día. Esa es demasiada información para mover con phpmyadmin o mediante la línea de comando. Además, mover los datos siempre causa problemas de UTF por alguna razón.

Además, ahora que parece que las opciones de menú están almacenadas en la base de datos, tengo aún más que tratar.

Verifico todo mi código en SVN e implemento el código a través de FTP desde el servidor (Beanstalk). Sin embargo, esto no realiza los cambios en la base de datos ni activa nuevos complementos.

Mi plan en este momento es crear un archivo de manifiesto mientras estoy desarrollando para hacer todos mis cambios en el sitio en vivo.

Por ejemplo, el archivo tendría líneas legibles por humanos

Incluiría complementos para activar, opciones de wp para mover, imágenes para mover, páginas para mover. Luego, mi complemento detectaría el archivo de manifiesto y realizaría todos los cambios en el sitio de preparación.

Una vez que probé eso y estuve seguro de tener todo, podría estar seguro de que funcionaría en la producción.

Este complemento todavía es solo una idea, pero tengo un código escrito para ello.

Además, si desea realizar cambios solo en la URL en su base de datos, puede usar el siguiente SQL.

simplemente reemplace $old$con el dominio anterior y $new$con el nuevo

update wp_postmeta set meta_value = replace(meta_value, '$old$' , '$new$') ;
update wp_posts set post_content = replace(post_content, '$old$' , '$new$') ;
update wp_options set option_value = replace(option_value, '$old$' , '$new$') ;

Dos proyectos de Google Summer of Code que tienen un objetivo similar:

• Migración Automática (GSoC 2010)
• WordPress Move ( propuesta ) (GSoC 2011)

Utilizo el comando de exportación de subversion para instalar los archivos de WordPress (http://core.svn.wordpress.org/tags//) así como todos los complementos en el repositorio (http://plugins.svn.wordpress.org//tags //), luego simplemente comprime el tema y los complementos personalizados e instálalos normalmente. Una vez que todo eso está funcionando sin contenido, exporto la base de datos de prueba y hago una búsqueda / reemplazo de la URL Y la ruta del archivo (almacenada para los medios) e importo a una base de datos vacía, luego solo cambio la información de la base de datos en wp-config .php. Generalmente me lleva unos 10-20 minutos.

Normalmente inicio sesión en phpMyadmin, subo la base de datos y edito el contenido de wp_options> siteurl y wp_options> home en el dominio esperado. Si necesita actualizar las URL dentro del contenido de sus publicaciones y páginas, puede hacer una búsqueda / reemplazo de la URL y la ruta de medios / cargas en el archivo .SQL antes de cargarlas. Es un trabajo rapido.

Si bien no hay escasez de buenas soluciones aquí, en el espíritu de compartir, pensé que agregaría mi script de implementación bash a la pila: https://github.com/jplew/SyncDB

SyncDB es un script de implementación bash destinado a eliminar el tedio de la sincronización de versiones locales y remotas de un sitio de Wordpress. Permite a los desarrolladores que trabajan en un entorno local (por ejemplo, MAMP) "empujar" o "tirar" rápidamente los cambios hacia o desde su servidor de producción con un solo comando de terminal.

Este script funciona bien con WP-Skeleton y los arneses de Mark Jaquith mysqldump, gity rsyncpara sincronizar todo su sitio (base de datos, código y medios) en dos sencillos pasos:

./syncdb
git push hub master

He estado usando http://wordpress.org/plugins/wp-clone-by-wp-academy/ . ¡Funciona muy bien!

Solo 3 pasos:

1. Instale el complemento en ambos sitios.
2. Use el complemento para generar una copia de seguridad en el sitio anterior.
3. Tome la URL de respaldo que le proporciona y conéctela a la página del complemento en el nuevo sitio, presione Go, ¡y su migración se completará en solo unos segundos!

Ajusta todas las URL automáticamente, incluidos los reemplazos de cadena serializados, por lo que no hay riesgo de perder configuraciones de widgets, etc.

Los únicos problemas que he tenido son con algunos sitios web con bases de datos más grandes (~ 300 MB), que causaron tiempos de espera de ejecución de script PHP durante la importación de la copia de seguridad del sitio.

A partir de 2017, estas son las dos mejores formas que he encontrado para manejar la transferencia de una base de datos de WordPress desde el desarrollo hasta la producción.

WP Migrate DB Pro / WP Sync DB

https://wordpress.org/plugins/wp-migrate-db/

Estos complementos de WordPress le permiten empujar, extraer y sincronizar tablas de bases de datos entre instalaciones de WordPress. Esto es mucho mejor que buscar / reemplazar por muchas razones porque:

• Exporta su base de datos como un volcado de datos MySQL (al igual que phpMyAdmin)
• Hace una búsqueda y reemplazo en URL y rutas de archivos
• Maneja datos serializados
• Le permite guardarlo en su computadora como un archivo SQL

Soy fanático de que me paguen por el trabajo que hago, por lo que le recomiendo que apoye al Sr. Brad Touesnard y compre una copia de la licencia del producto real. WP Sync DB es una réplica y, como resultado, siempre está atrasado en el soporte. Con este complemento, el proceso es muy simple:

1. Instale / active el complemento en su host local y entorno de producción
2. Configure una transferencia automática desde su servidor localhost / de desarrollo a su producción
3. Complete las reglas para las tablas que desea transferir y defina las reglas de búsqueda y reemplazo para realizar
4. ¡Eso es!

Búsqueda y reemplazo de bases de datos para bases de datos de WordPress por InterconnectIT

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

Esta herramienta gratuita no es un complemento, pero está instalada en su directorio raíz de su instalación de producción de WordPress. Esto no es tan bueno como WP Migrate DB Pro porque requiere unos pocos pasos manuales, pero no obstante es una gran opción que funciona de manera consistente. Cuando se utiliza este enfoque, el proceso se ve así:

1. Haga una copia de seguridad de su base de datos local, esto es absolutamente necesario ya que pronto lo volveremos a importar
2. Agregue el script a una carpeta en el directorio raíz de su instalación
3. Ejecute buscar y reemplazar en su base de datos
4. Exporte su base de datos y guárdela para su entorno de producción
5. Vuelva a importar su copia de seguridad desde el paso 1 para restaurar su host local
6. Conéctese a su base de datos de producción y realice una copia de seguridad (como siempre debería hacerlo antes de hacer estas cosas)
7. Importe la exportación que hicimos DESPUÉS de ejecutar la rutina de buscar / reemplazar desde el paso 4

Puede utilizar un enfoque más rápido, pero implica un tiempo de inactividad para su sitio de producción que, en mi opinión, es inaceptable. Por eso lo llamamos producción, ¿verdad?

dado que ejecuto mis sitios en IIS (también ejecuto asp.net, por lo que necesito Windows) uso WebPI de Msft para instalar una nueva instancia, luego copio la plantilla y uso la importación / exportación para transferir los datos.

No es perfecto, pero todo lleva menos de una hora.

Obviamente, sería bueno tener una solución de un solo clic, pero esto es lo que me pareció más fácil.

Otra solución de pago: el marco temático Xtreme One lanzó la versión 1.2 con Xtreme Backup que le permite "exportar o importar la configuración de sus Childthemes, Layouts o Widgets con toda su configuración / contenido como archivo XML".

Un compañero de trabajo encontró esto. Concepto interesante, aunque no funciona entre servidores parece. Todavía lo estoy explorando, pero parece que podría funcionar muy bien para una instancia de preparación

http://code.google.com/p/deploymint/

Puede que esto no haya existido cuando hizo la pregunta, pero he estado usando un servicio llamado Blogvault durante un par de meses y lo ha hecho sin problemas. Probablemente he realizado más de 50 migraciones (cruzando dominios, subdominios y servidores web), no es un problema y no toma tiempo en absoluto.

Es un servicio pago (por dominio / mes), pero no tanto.

RAMP es un nuevo complemento de implementación de contenido de Crowd Favourite, y se ve muy elegante. Sin embargo, cuesta $ 250, así que aún no lo he probado. Sin embargo, podría pagarse solo en la cantidad de tiempo ahorrado, así que lo estoy considerando.

El gran beneficio que tiene sobre la mayoría de los otros métodos mencionados es que puede combinar de manera inteligente publicaciones, comentarios, etc. No se trata solo de importar un mysqldump, es más como un control de fuente para la base de datos. Por ejemplo, al implementar una publicación, también implementará las etiquetas para esa publicación, si aún no existen en producción.

Déjame regalar uno de mis favoritos :-)

// proven local<->live codefork (covers local network testing, i.e. from mobile devices):
$GLOBALS['is_local'] =  
    in_array( $_SERVER['REMOTE_ADDR'], array("127.0.0.1","::1")) || // simple localhost (IPv4 IPv6)
              $_SERVER['HTTP_HOST'] == 'local.workblog'          || // call by local name (adjust)
       substr($_SERVER["REMOTE_ADDR"],0,8) == '192.168.';           // (mobile) device in local network

$table_prefix  = NULL; // ensure scope

if ( $GLOBALS['is_local'] )  // LOCAL fork ------------------------
{
        ....
}
else  // STAGE/LIVE fork -------------------
{

... y luego trabajas desde allí. DB_NAME, DB_USER ... table_prefix. Personalmente , enciendo ALTERNATE_WP_CRON en local (para evitar algunas advertencias molestas ), WP_DEBUG en ambos (si no eres desarrollador) o solo en vivo (si lo eres), otro ini_set('display_errors', '0');en vivo también podría ser bueno, y por último, como se mencionó anteriormente: WP_HOME y WP_SITEURL a la URL local / actual respectiva.

Eso es todo, nada queda por encima del clásico WordPress '¡Eso es todo, deja de editar!' línea...

El 192.168. parte le permite hacer algunas pruebas locales (es decir, desde pads o teléfonos) dentro de su red local)

El $ GLOBALS ['is_local'] también puede ser útil en el desarrollo de su tema, para algunos resultados de depuración adicionales, etc.

He estado usando el complemento backupbuddy por un tiempo ahora. Le permite hacer una copia de seguridad de la base de datos y todos los archivos, descargarla como un archivo zip o enviarla directamente a otro servidor a través de FTP. También hace que la URL encuentre y reemplace por usted. Por lo general, me lleva unos 5 minutos completar todo el proceso. Y debido a que todos los archivos están comprimidos, el proceso de carga / descarga es mucho más rápido. Y no, no trabajo para ellos, pero este complemento realmente ha hecho todo este proceso mucho más fácil.

Otra herramienta útil para manejar las migraciones de servidores para sitios es la CLI de WordPress, este artículo tiene una buena descripción de lo que puede hacer, pero específicamente la sección "Buscar y reemplazar" es útil para encontrar todas las referencias a la URL del sitio antiguo / desarrollador :

Gestión avanzada de WordPress con WP-CLI

Esta es la forma más fácil: https://themes.artbees.net/docs/website-migration/
Solo se necesitan dos clics. Uno para exportar, uno para importar.

Es posible mediante el uso del complemento All in one WP Migration. El enlace de arriba muestra cómo usarlo.

Si está tratando de lograr una sincronización continua, le sugiero que use rsync junto con un trabajo cron personalizado para reescribir cualquier url o datos específicos del sitio.

Después de haber seguido esta respuesta durante un tiempo, he creado mi propio pequeño complemento: Pitta Migration . Las razones son:

1. De todas las ideas tratadas aquí, la más simple es la WP_HOMEy las WP_SITEURLopciones
2. Luego los uso para establecer las dos wp_optionsURL coincidentes , que cubre cuando los complementos / temas ignoran estos
3. Esto me da 100% de confianza en lo que se está cambiando en mi base de datos.
4. Esto también funciona multiplataforma (todos esos scripts de bash no funcionan bien en Windows)
5. Es fácil entender qué está haciendo el complemento
6. No hay configuración más allá de las dos constantes: realice una importación mysqldump y mysql a su base de datos local y el complemento ve que la constante y la tabla difieren y las actualiza para que coincidan
7. Sin búsqueda de texto y reemplazo
8. No hay posibilidad de destruir su base de datos: uso el objeto de base de datos de WordPress para hacer dos actualizaciones y nada más
9. Funciona muy bien con cosas como WordPress Skeleton donde puedes tener todo en control de fuente y configurar una configuración local
10. Lo puse en el directorio de complementos de WordPress y en Github para que sea gratuito, de código abierto, fácil de bifurcar y fácil de instalar
11. Una vez que está instalado, puede olvidarse de él y debería 'simplemente funcionar': le da un pequeño aviso para decir que la base de datos ha sido modificada
12. Debería funcionar con cualquier proceso de copia de seguridad / FTP / restauración

En mi opinión, la forma más fácil que sigo es la transferencia manual. Simplemente copie la carpeta wp-content y el archivo wp-config.php al nuevo host. Exporte la base de datos del host anterior e impórtela en una nueva base de datos del host nuevo.

En la nueva base de datos de host, vaya a la tabla de opciones de wp y cambie la URL del sitio y la URL del blog a Nueva dirección de host del host anterior. como desde http: // localhost / wp a http://example.com

Ahora en el archivo wp-config simplemente cambie la información de la base de datos y el usuario con nueva información de host.

Ahora inicie sesión en el nuevo wp-admin y vaya a la configuración y guarde el enlace permanente.

Estás listo. Creo que esto es simple sin usar ningún complemento.

He intentado diferentes tipos de complementos y todos estos tienen muchos tipos de problemas.

Así que prefiero esta simple transferencia manual, que es más fácil, creo.