Wordpress staging environment

Question

I work for a company that does sites for the pharma industry and we often need to get legal approval before we push any changes live. So, I'd like to migrate a lot of our work to a CMS environment, specifically wordpress but we need the ability to have a staging environment. Is it possible to instead of publishing a page have it publish to a staging environment that someone can browse as with a link as a site. So basically have 2 sites, one staging one live?

Answer 1

Generally speaking other "answers" here are correct, there are alternatives to WordPress that have better built-in support for staging environments and build migrations. However the suggested alternatives aren't exactly equal substitutes to the WordPress platform, so I think it's best to answer the question at hand instead.

WordPress does not natively support hosting the same site from two different hosts. The core relies on absolute URLs stored inside the database and are used in just about every aspect of the core logic. This results in a number of superfluous bugs like the 500 or so related to SSL access because they try to dynamically alter all http:// schemes to https:// on the fly.

As a result when you host on dev.example.com and migrate to staging.example.com and again to www.example.com you have to do very careful search & replace manipulations on the database export each time you switch hosts. And this causes additional problems when you find out that many popular WordPress plugins serialize the URL into values in the database. So when you search & replace dev.example.com with staging.example.com the serialized data which contained the character length of the original value no longer deserializes with the new longer format. Some core contributors believe the solution to this later problem is to only ever setup staging sites with the same number of characters as the production account...

In a similar vein they also suggest swapping host mappings and only ever using the production.com URL on all hosting environments. Depending on your particular use-case requirements this is probably not a valid solution if you need to provide access to off-site clients, tech-illiterate users (versus tech-literate users of course.)

But WordPress itself has a number of great features otherwise and is a very adaptive and powerful rapid development platform. As a result you can extend the core framework to do much of what you need from it. When I was presented with this situation, I had to develop a solution that was viable for all circumstances. Traditionally this problem is solved with root-relative URLs, they work in cross-hosting environments, and they don't suffer from scheme changes, port changes or subdomain swapping practices that are common with staging migrations.

With this plugin: http://wordpress.org/extend/plugins/root-relative-urls/ (biased? yes, I wrote this plugin.) you get root-relative URLs where it's important and dynamic hosts where root-relative URLs don't work (like rss feeds.) All that remains from migrating the site to different hosts is to move the wp-config.php file outside of the www root (one level up is supported natively by WordPress.) so you can maintain different copies on different servers. Or alternatively you can use basic if-statements to distinguish hosts by server name and define key WordPress constants based on the server. In the end your content, code & data will transition seamlessly.

As a note of concern, the referenced plugins require setting write access to the wp-config.php file, a very bad practice from a security perspective for production or publicly accessible servers. Perhaps you can comfortably implement this in a restricted staging environment but then you'd need to disable and remove the plugin in production transitions.

Long story short, yes you can host WordPress in multiple host environments. The long-touted solutions are very case-specific and option-restricted because of the core architecture. But the framework is flexible enough to overcome the core deficit. This core design decision will probably change at some point in the future given the amount of effort the core developers continually spend on overcoming the cascading issues. But there are also devout defenders of the absolute URL religion that will keep the practice in place for the time being. Maybe a different platform that supports server migrations natively (pick just about any of them because most do) would be a better option for you now.