These are my notes from Dick Olsson's Content Staging in Core talk at Drupalcon Denver 2012. Follow him on twitter @dickolsson. [My other notes from DrupalCon Denver]
Dries has been talking about this for the last three or four years in the keynote, but it hasn't happened much. The configuration management initiative has obviously kicked off, and will do a great deal to separate content from configuration. But, what about the content staging problem? I'm not necessarily here with the solution, but I do want us to come out of Drupalcon with a plan for how much core should care about content staging.
Content staging is different for different people. Editors want to review and publish content. Some just want to preview a whole site and push a button to move it to production. I work at Al Jazeera, and talking to my system team, they see content staging as a security requirement. You can also see content staging purely as a method of moving data between arbitrary systems, perhaps even the same site existing on different servers in different regions.
What do we need to do?
- Finish the UUID implementation. We should have UUID for all entity types, and we should consider implementing UUID for other things such as path aliases. Should we implement a plugin system?
- Canonical entity format. We need a way to represent entities in order to be able to exchange data between arbitrary systems. See groups.drupal.org/node/197583. We're not there yet; we need to discuss this more.
- Entity dependencies. Difficult problem when moving entities; could be defined by the format or the field or property API. We need to figure this out to figure out how to move entities around without breaking them.
A lot of other things can be left to contrib. We have the Web Services initiative, which we could use to move stuff around. The deployment and staging UI can be left in contrib. Workflows and Rollback, the same.
Next Steps at Drupalcon
- Hack on the UUID implementation
- Discuss the entity format
- BoF: Content Staging in Drupal 8, Wednesday 10:45am-noon
- BoF: Content Staging in Drupal 7, Wednesday noon-1pm
Questions and Answers
Q: How does this work for tiny sites?
A: Content staging is not intended for every site. Sites with heavy editorial workflows obviously need it. The underlying solution for content staging should be more useful and has a lot of use cases, but it's not directly applicable to everyone.
Q: It seems like a lot of work is going into deployment strategies for content; what about a one-system solution?
A: I know there's a lot of discussions on how to solve this. Acquia has a large-scale Drupal group on groups.drupal.org. The state machine module could be one solution. That's something we definitely need to discuss. We need a way to move data between different systems; exchanging data is increasingly important. We should probably have a solution as well for previewing on one system.
Q: If content vs configuration changes by use case, has there been thought to making what is configurable, configurable?
A: For Deploy in Drupal 7, we chose to only support entities. We let Features take care of configuration management. We're finding a middle ground now but it's a tough ground, and we need to discuss more.
Q: Some content is generated by users. It's not always going to start in staging and move to production.
A: Exactly. That's why we want to move content between arbitrary sites. The UUID implementation will ensure that we can replicate content around.
Q: Regarding importing and migrating content from non-Drupal sources, will we use more open ETL tools?
A: Attend one of the BOFs and explain that to me!