¿Cuál es una buena manera de configurar un flujo de trabajo de desarrollo, organización y desarrollo con wordpress?
staging dev-to-production (4)
Wordpress presenta algunos desafíos, ya que tiende a mantenerse demasiado en la base de datos, lo que dificulta el traslado de un servidor a otro.
¿Cuáles son algunos otros problemas a tener en cuenta?
¿Cómo fue tu flujo de trabajo?
Esta misma pregunta fue formulada y contestada en WordPress.stackexchange . Contiene información detallada y las mejores prácticas para un rápido despliegue desde el desarrollo hasta la producción.
Editar
Esta es la misma respuesta que agregué en WordPress Answers.
Puede que haya muchas formas mejores de que me pierda, pero le voy a dar 2 opciones:
1.Utilice Exportación XML para exportar sus nuevas publicaciones y comentarios. Luego use el Importador de WordPress para importar las nuevas publicaciones y comentarios de nuevo en la base de datos de desarrollo.
Es mejor importar en dev y luego mover la base de datos a producción porque cuando lo importe, descargará todos los archivos multimedia nuevos de producción.
Mientras tanto, la producción ha cambiado (nuevas publicaciones, nuevos comentarios, etc.)
Esto resolvería su problema de traer cualquier contenido cambiado.
2. Use el comando INSERT IGNORE INTO MySql para agregar las nuevas tablas de dev. o el comando REPLACE para sobrescribir filas duplicadas en la misma tabla.
Antes de usar MySql, haga una copia de seguridad de ambas bases de datos, mueva la base de datos gz al servidor de producción y cargue el volcado (cambie el nombre de dev si es el mismo que el de producción).
INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`
No me siento cómodo con los comandos de MySql, así que elegiría la opción 1.
Si tiene phpMyAdmin instalado, mover los sitios de WordPress de un servidor a otro no debería ser un problema. Simplemente exporte la base de datos a un archivo tar.gz y copie su tema personalizado (si está usando uno) a través de FTP y luego, después de crear una nueva base de datos y un volcado de wordpress nuevo, vuelva a cargarlos en el nuevo servidor. 2 cambios en la URL de inicio y blog en la base de datos y 2 cambios en el archivo wp-config y listo.
Una cosa con la que he tenido problemas es con los complementos de terceros. Terminé codificando muchas galerías y widgets de javascript porque los complementos de terceros parecen basura, son lentos o no funcionan como deseo. Gracias a Dios por JQuery.
Tengo el Sitio de desarrollo en mi máquina local y cambio el archivo de hosts locales para que las llamadas al servidor en vivo (www.example.com) apunten al host local. De esa manera, todas las llamadas a archivos externos (jquery, etc.) todavía funcionan y no tengo que molestarme en revisar la base de datos para cambiar nada. Ex e importar el contenido a través de wordpress XML me ha dado los mejores resultados.
ACTUALIZACIÓN: He utilizado http://www.mertyazicioglu.com/projects/wordpress-move/ y he obtenido buenos resultados.
JD
Tengo una única instalación de WordPress configurada para alimentar múltiples dominios en mi servidor de desarrollo. Los archivos de complementos y temas también se comparten, por lo que la actualización es un proceso de un solo clic para todos los blogs.
Uso Apache VirtualHosts para asignar múltiples dominios a la misma raíz del documento, y rocío un poco de magia en el wp-config.php principal wp-config.php para establecer dinámicamente DB_NAME , según el host actual (puedo publicar el código si lo desea).
Para trabajar localmente, solo tengo un usuario de MySQL con privilegios de root y lo uso para todas mis bases de datos (¡no recomendado en un servidor de producción!).
Mis dominios locales se llaman apropiados para los dominios reales , pero con un TLD falso. Así que trabajando con example.com , configuré un ejemplo de VirtualHost.
Cuando estoy listo para HeidiSQL , uso HeidiSQL para hacer una copia de la base de datos de desarrollo y luego reemplazar todas las apariciones de example.dev con example.com .
La base de datos copiada ya está lista para la instalación de producción. Refleje su instalación local de WordPress en el servidor de producción (copiando sobre plugins, subidas y temas), y use HeidiSQL (recomendado) o phpMyAdmin para importar la base de datos preparada.
ACTUALIZAR
Naturalmente, si realiza cambios en uno y luego lo copia todo en el otro, perderá cualquier cambio que haya realizado en el otro. ¡Esto no es solo para WordPress, sino para casi cualquier otra cosa en la vida misma!
Si alguna vez necesito realizar cambios importantes una vez que el sitio está activo (y por mayor, me refiero a los cambios que no deberían realizarse en un servidor de producción), hago el proceso inverso de lo anterior (copio todo desde la producción al desarrollo), Realice los cambios, luego haga lo contrario nuevamente.