Architecture of staging environment for CMS

Question

My company has developed a cms but now we use it for a while we stumble upon a problem: all changes are directly linked to the live environment. If you want to do a big overhaul of a site, you sometimes want to do all the work first and then publish all the changes to the live site at once.

I'm talking about content now, not a development/testing/staging/production environment for developing software

I've seen several options to solve the problem, but none can completely solve this problem:

1. Use versioning: version x is running at production, y is at staging;
2. Use a draft/publish flag: all draft content is kept away from the live site;
3. Use two databases: one for the staging environment, one for live.

All of them have problems:

1. Versioning is problematic for newly created pages (version null at production?) and changes in page sitemap (we use a nested set for that);
2. For drafts it is not possible to create a second version of an already published page;
3. With a second database you have to copy/synchronise all data you don't want to be different between the two places: users, user groups, permissions etc.

Are there other options? Preferably you want to do this on a user-lever, so user A can start a big overhaul and user B is still able to publish new content. But perhaps this is too difficult for now and we just have to solve the first problem for now.

PS. It is a php, ZF app with MySQL backend, but that shouldn't matter for the architecture I think.

Answer 1

It's been a long time, but we have now a multi stage CMS which works as follows. The tree of production and staging is two-fold. In a nested-set setup we can store multiple trees in one database. The page in production is linked to the staging with a UUID.

Content itself is managed with versioning where a versioning table holds all versions and an entity table holds the production version. The versioning is (for staging) thus some steps ahead of the production version. This way we can also implement autosave for text blobs (it's just another version).