I am re-opening this question (originally posted by NDP) because is is a critical issue in WordPress and the original question was not replied to or resolved.
“This question has two sides to it: a theoretical one, and a technical one:
I am trying to resolve a development lifecycle issue with my website design.
My initial plan was to set up a staging server with an instance of apache/php/mysql and WordPress, develop my content on this staging server, then, at various checkpoints in the development process, deploy my code to a separate instance of apache on the same server (mapped to a different URL).
My question is:
Is this a typical website development methodology? The reason why this is not obvious to me, is that I’ve had several difficulties in transferring my content from the staging configuration to production; it doesn’t always seem to go smoothly, and I have yet to find a simple process that just works. That’s the technical side of my question. . “
My question is almost identical to NDP’s for WordPress 3.1. We are in the middle of migrating 5 new domains on to WordPress and were using the development / staging / Production approach to domains and associated sub-domains. Our experience has only been successful in a completely manual migration mode that has made us seriously question the sustainable viability of the WordPress platform for future client development.
The above link: http://codex.wordpress.org/Moving_WordPress does not adequately answer the question or resolve the issue. It seems that almost all the responses provide this same answer given over and over again. Unfortunately, the codex article only addresses the simplest of WordPress installations.
The issue is practically simple… WordPress needs to define and support a best practice approach to a site design methodology and a site version migration strategy that is typically used in most commercial site deployments. In our situation, we are seeking recommendations to successfully migrate complex WordPress sites (new site functionality as opposed to the Version of WordPress) within a domain from the development environment (a sub-domain) to a “staging” (testing) environment (another sub-domain) and then to the production (live site) environment (production domain). It would appear that this is still a critical weakness in the WordPress platform as of Version 3.1. There are no documented best practices, there are no utilities or scripts published and WordPress incorporates “absolute” or hard-coded URL links in several places that make migration very, very, frustrating and prone to over-sight / error. In a typical commercial environment the site specific variables and links are actively referenced (called) via a global variable declaration file and a dynamic variable declaration file. Until this type of capability is incorporated to support advanced user needs … the developer is stuck manually editing each and every config file, theme and content file. This is not practically supportable or sustainable for sites with complex theme structures, advanced functionality and larger data volumes
If anyone has found a best practice approach to address this site development and migration issue… Please, please reply. Other post of this nature have simply been closed without any answers and marked as “unresolved”.
I do not believe that the WordPress or the WordPress community should ignore or overlook this issue.
Comments welcome and encourage to resolve this issue. Thanx!
- The topic ‘Best Practices: Site Development Methodology and Migration Strategy’ is closed to new replies.