Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Apr 05 2012
Apr 05

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.


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 ;)

Mar 10 2012
Mar 10

The lack of a robust content staging solution in Drupal has been long standing. In this post I won’t go into details of why this is such a difficult problem to solve. Instead, I’ll suggest a plan, to make a plan, to solve it! So, those of you that are interested in tackling a strategically important functionality for Drupal 8, please continue to read.

What’s being done right now?

Throughout the last 8-9 months I’ve been working on a rewritten version of UUID and Deploy for Drupal 7. It’s been moving slow for different reasons, one being because we’re very few people coding on it. But (dare I say it?) we are close to a release of Deploy!

Acquia started an initiative called Large Scale Drupal (LSD), focusing on identifying, planning and consolidating work on problems for large scale Drupal implementations. Content staging is one focus area, with wireframes and workflow discussions.

In parallel with all this, the Configuration Management Initiative landed the first UUID patch and the initial version of the file based configuration API. Both patches are important for improving the content staging situation in Drupal 8, but it’s not enough.

A plan, to make a plan

For those of you that are interested to work on this topic, here are some events you should participate in during DrupalCon Denver, and some points we need to discuss in order to get out of Denver with a solid plan on how to make content staging work better in Drupal 8!

Core conversation: Content Staging in Core, Tue 11:15am – 11:45am

Some points I will raise and we hopefully will discuss during my core conversation:

  • Why a file based configuration API isn’t the whole answer
  • What I think is needed in core to tackle content staging better (this will also be a separate post soon)
  • Next steps for the UUID implementation in core
  • Do we need some sort of documentation, group or sub-initiative to track this?

BoF: Content Staging in Drupal 7, Wed 11:45am – 1:00pm

  • Work being done in different projects for Drupal 7, like Deploy, State Machine, LSD etc.
  • How to consolidate work across those projects
  • Next steps moving towards a working solution in Drupal 7

BoF: Content Staging in Drupal 8, Wed 1:00pm – 2:00pm

  • Follow up on our discussion from the core conversation
  • Create issues, documentation or plans we find needed in order to move forward


This blog post is a cross post of this g.d.o post, please discuss there.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web