En general, las "respuestas" anteriores son correctas, existen alternativas a la conversión de Word que tienen mejor soporte integrado para entornos de ensayo y migraciones de compilación. Sin embargo, las alternativas sugeridas no son exactamente iguales a la plataforma wordpress, por lo que creo que es mejor responder a la pregunta en cuestión.
Wordpress no admite de forma nativa el alojamiento del mismo sitio desde dos hosts diferentes. El núcleo se basa en direcciones URL absolutas almacenadas en la base de datos y se utilizan en casi todos los aspectos de la lógica central. Esto da como resultado una cantidad de errores superfluos, como los aproximadamente 500 relacionados con el acceso SSL porque intentan modificar dinámicamente todos los esquemas http: // a https: // sobre la marcha.
Como resultado, al hospedarse en dev.example.com y migrar a staging.example.com y nuevamente a www.example.com, debe realizar búsquedas muy cuidadosas & reemplazar las manipulaciones en la exportación de la base de datos cada vez que cambia Hospedadores. Y esto causa problemas adicionales cuando descubres que muchos plugins populares de wordpress serializan la url en valores en la base de datos. Por lo tanto, cuando busca &, reemplace dev.example.com con staging.example.com, los datos serializados que contenían la longitud del carácter del valor original ya no se deserializan con el nuevo formato más largo. Algunos contribuidores principales creen que la solución a este problema posterior es configurar sitios de ensayo con el mismo número de caracteres que la cuenta de producción ...
En una línea similar, también sugieren intercambiar asignaciones de host y solo utilizar la url de production.com en todos los entornos de alojamiento. Dependiendo de los requisitos particulares de su caso de uso, probablemente no sea una solución válida si necesita proporcionar acceso a clientes externos, usuarios analfabetos (por supuesto, a usuarios que saben leer y escribir)
Pero wordpress en sí tiene una número de características excelentes de lo contrario y es una plataforma de desarrollo rápido muy poderosa y adaptativa. Como resultado, puede ampliar el marco central para hacer mucho de lo que necesita de él. Cuando me presentaron esta situación, tuve que desarrollar una solución que fuera viable para todas las circunstancias. Tradicionalmente, este problema se resuelve con las URL relativas a la raíz, funcionan en entornos de hospedaje cruzado y no sufren cambios de esquema, cambios de puerto o prácticas de intercambio de subdominios que son comunes con las migraciones de etapas.
Con este plugin: http://wordpress.org/extend/plugins/root-relative-urls/ (? Sesgada sí, he escrito este plug-in.) Se obtiene las direcciones URL relativas a la raíz donde es anfitriones importantes y dinámicos, donde las direcciones URL relativas a la raíz no funcionan Todo lo que (como los canales RSS.) El hecho de que migre el sitio a diferentes hosts consiste en mover el archivo wp-config.php fuera de la raíz de www (un nivel arriba es soportado de manera nativa por wordpress) para que pueda mantener copias diferentes en diferentes servidores. O, alternativamente, puede usar sentencias if básicas para distinguir hosts por nombre de servidor y definir las constantes clave de wordpress basadas en el servidor. Al final, su contenido, código &, los datos de transición sin problemas.
Como nota de preocupación, los complementos a los que se hace referencia requieren configurar el acceso de escritura al archivo wp-config.php, una práctica muy mala desde una perspectiva de seguridad para servidores de producción o accesibles públicamente. Quizás pueda implementar esto cómodamente en un entorno de ensayo restringido, pero luego deberá deshabilitar y eliminar el complemento en las transiciones de producción.
Para abreviar, sí puede alojar WordPress en múltiples entornos de host. Las soluciones largamente promocionadas son muy específicas de cada caso y restringidas por la opción debido a la arquitectura central. Pero el marco es lo suficientemente flexible como para superar el déficit central. Esta decisión de diseño central probablemente cambie en algún momento en el futuro dada la cantidad de esfuerzo que los desarrolladores centrales gastan continuamente en la superación de los problemas en cascada. Pero también hay devotos defensores de la religión url absoluta que mantendrán la práctica en su lugar por el momento. Tal vez una plataforma diferente que admita migraciones de servidores de forma nativa (elija casi cualquiera de ellos porque la mayoría lo hace) sería una mejor opción para usted ahora.
Estoy de acuerdo con esto. Silverstripe es un gran CMS y más al punto si estás creando sitios web, debes usar un CMS, no un software de blogs. – Bendihossan