When doing a test site, and you do an upgrade, you will have to redo the upgrade on the live site to keep new data such as new orders or forum posts. The test site and live site get out of sync if any new content is posted to the live site. It would be better if a system were developed that would only push some of the changes to the live site, letting upgrade run the rest of the changes (such as for the orders database..). This could be a part of the staging system, where data is flagged as frequently changing, or very likely to change, and therefore won't be migrated from a test site, it will use what's on the live site and update that instead. The modules themselves should mark the data as to whether or not the data can safely be pushed to the live site, or whether it should run the update procedure on the data on the live site separately. This could be on a per database table basis...
This would make it much easier to do test upgrades, but still use some of those upgrades on the live site, while not falling out of sync with the most important data (orders, forum posts, comments, webform entries, or anything other data that can be entered by users that you wouldn't want to lose by having a test site fall out of sync...
----
We've already identified that people talk about some different things when mentioning 'content staging'. The two primary things are:
* Moving content between different physical environments (editorial staging > quality assurance > production)
* Content moderation and content preview on one and the same environment
While both are immensely important for large scale Drupal implementations and both sometimes can solve the same problem, they are technically different. The former has some more history as being referred to as 'content staging' and the later to just 'moderation' and/or 'content preview'.
Once we have a good framework for moving content between environments we can build more workflows on top of that. So this issue is going to focus on 'content staging' in the first sense.
Comments
Comment #1
catchFeature requests aren't critical.
Comment #2
limako commentedI recently wrote a guide to managing multisite staging on a single server by using (1) a virtualhost on another port number as the development site and (2) scripts to automate creating the development space from production and switching between development and production with zero downtime: http://drupal.org/node/942540
Comment #3
mitchell commentedThis would make for a good 'content staging' issue.
So, to start, I'm breaking out the related info in the entity serialization issue and putting it into this OP; #1540656-1: [META] Entity Serialization API for web services (e.g. content staging) & Help understanding the Deployment use case should also come along. Adding 'Issue summary initiative' tag.
The other 'staging' tagged issues could also be cross-linked.
To do, create: Identify complimentary needs of configuration staging & content staging. See also, #1697256: Create a UI for importing new configuration
Comment #3.0
mitchell commentedMigrated serialization issue content
Comment #16
smustgrave commentedAre you describing the workspace module?
Comment #18
quietone commentedThere hasn't been discussion here for 13 years supporting this idea.
The proposal doesn't met the Criteria for evaluating proposed changes. In this case, there is not demonstrated demand and support for the change.
If there is interest in this re-open the issue and add a comment. Or open a new issue and reference this one.