Update: Here's the follow up post on drupal.org with the implementation plan: http://drupal.org/node/1540656.

DrupalCon is over (since two weeks already). It was an awesome time. Some say it was the best so far. Thankfully it doesn't mean that the community will sleep until Munich. No, now it's time for action! The code freeze is coming closer and things need to happen quickly.

One of the things that I've decided to help with for Drupal 8, is improved support for content staging in core. At DrupalCon there were quite a bit of discussions around this matter. And I'm going to try to summarize this in this blog post.

Content staging is a lot of different things to different people. It involves workflows, APIs to manage content, universally unique and identifiable content, APIs for pushing and merging content between environments, and so on. Many people also use content staging-like functionalities to share content across networks of sites. So, when people talk about content staging they often talk about it in different contexts or focusing on different technical problems. Here are some of the semi-related discussions that took place.

Core conversation on content staging

On Tuesday I started off with my core conversation on this topic. You'll find slides and videos here: http://denver2012.drupal.org/content/content-staging-core

Discussions about Workflows

@stevector and robeano held a core conversation about the editorial workflow experience in Drupal and highlighted some problems with revision management in core. This is something we need to improve to efficiently be able to stage revisions of content. But more about that in the next blog post. Listen to the core conversation here: http://denver2012.drupal.org/content/i-just-want-edit-node

Discussions about Entity API

On Tuesday (if I recall correctly) we held an Entity API BoFs. One of the things we talked about was introducing a Property API, similar to what the Entity API contrib module for Drupal 7 provides. This would unify how we interact with fields and properties on the code level and help solve one of the toughest problems for efficient content staging, namely consistently tracking what properties and fields that adds dependencies (like author or taxonomy terms). This would then be defined in the property API, similar how "data types" are used in the Entity API contrib module and Rules.

Another important discussion that happened around the Entity API in core was @DamZ's and @lsmith's core conversation about implementing standards for document storage in content management systems in general, but Drupal in particular. One of the very interesting topics was the plan for introducing PHPCR to Drupal. PHPCR defined a standardized API for how content should be stored and managed. That in turn, would make it a lot easier to implement a standardized outward-facing API and a canonical format for our content (like CMIS). This would define a more robust transportation protocol for moving content between environments. Go ahead and listen to the whole core conversation here: http://denver2012.drupal.org/content/open-standards-and-document-oriented-storage.

Notes from the content staging BoFs

For the Drupal 7 BoF that was held, we mostly talked about how people are tackling content staging (and similar functionality) right now. We simply concluded that people and organizations do it very differently. Some people are using Deploy, some people don't, some people build more advanced content staging/preview functionalities on a single site together with modules like Workbench Moderation or State Machine. One thing that came out of the Drupal 7 BoF was that we should look deeper into how we can integrate Deploy and State Machine better with each other. More on this in another post.

For the Drupal 8 BoF we identified some of the things I already mentioned in this blog post:

• better revisioning support for single-site content staging
• ability to define variants of your configuration (more on this below)
• ability to synchronize deployments of configuration and content together
• we need a canonical entity format

Being able to work on different variants of configuration for your site was something we talked a lot about. One exemplifying scenario would be an editor on an e-commerce site that, through the UI, prepares new sets of content together with a new variant of configuration (menus, views, landing pages etc) for the launch of a new spring clothes collection. Currently in CMI there's no API support for this, not even support for different variations between staging and production. It's for now recommended that you solve this on a VCS level with different branches of your code. I talked to Greg Dunlap, the initiative lead, about this and he said it has been discussed. But providing API support for this and eventually a UI where you blindly can switch between variants of your configuration is complicated with the risk of mangling your database (switching between different Field API configurations for instance). So we would need to think some more about this and eventually re-visit this discussion.

Summary

All in all, there were a lot of good discussions and ideas flying around. The next step will be to formalize a more concrete plan and start work on things we need to improve for better content staging in Drupal 8. Work is already being done in a lot of areas that help improve the situation, but there's more work to do. More about this in the next blog post ;)

Topic: DrupalTags: Content stagingDeployDrupalConDrupal planet