At DrupalCon Chicago I created the Drupal 8 development branch in front of a room full of core contributors. This means that we have officially started work on Drupal 8 and that I started to accept new features and improvements for Drupal 8, the next major version of Drupal.

In my State of Drupal presentation in Chicago I outlined what I believe should be the strategic direction for Drupal 8. If you want all the details, you can watch a video recording of my keynote. If you don't want to watch the entire video, here is the executive summary:

  1. Multi-device publishing (aka mobile); clean HTML/CSS, HTML5, contexts, web services APIs, etc
  2. Interopability and integration with cloud services: web service APIs, pluggable components, clean data models, etc
  3. Delightful experience: accessibility, usability, performance
  4. Configuration management: better separation between content and configuration, universally unique identifiers (UUIDs), exportables, more consistent CRUD APIs, etc
  5. Content staging

I plan to blog more about each of these topics in the next couple of months. In the mean time, let's continue all the conversations and let's start work. Woot!

Drupal branch
Sam Boyer helping me to create the Drupal 8 branch. Picture taken by Ariane Khachatourians.
Drupal branch
A screenshot of my screen after we created the Drupal 8 branch.


David Thorne (not verified):

And with that D8 is open for business. Thanks Sam for helping Dries do the honours.

I look forward to more comments on progress as time goes on. I'm particularly keen to see how people want staging to work and to get involved with that side of things. :)


Manolo (not verified):

Hi Dries, you say that one of the objectives for Drupal 8 is "clean HTML/CSS, HTML5". This statement is a bit confusing for me (what kind of markup is generated by Drupal now?).

I'm just learning Drupal 7 and so far I have a basic knowledge of theming. However, being a fluent HTML4-5/XHTML coder, I hope I will be able (now, in Drupal 7) to personally write from scratch every line of the front-end code for my web site. I don't like HTML code generated by CMSes (or by their modules). Is this realistic? Or there are some parts of the front-end of a Drupal web site that a web designer can't overwrite?

I come from Django where I had total freedom in designing templates. The creators of Django decided for a clear separation between data, python code and HTML templates. Is Drupal different from this point of view?

I'm asking this question because I've just read the report of Adactio fron DrupalCon Chicago, where he says that "Drupal makes complex things (like setting up a website) easy and easy things (like editing some markup) complex."

I would like to read an article where all the difficulties faced by Drupal theme designers are listed and discussed...

PMdrupal (not verified):

I don't see i18n / multilanguage integration into Drupal 8 core, which is very important to gain market share in Europe - hope that is planned?!

Jonathan Wagener (not verified):

i18n in core would be awesome, i have done a couple of multi-language sites (in drupal6 and drupal7) and it is quite a nightmare to setup. having the features in core would be great :)

Anonymous (not verified):

... having the features in core would be great :)

Yes and no.

Moving any module into core means that feature will not develop and change quite as quickly or easily as if it were a standalone module. The bar for checkins will be much higher, and criteria for new features will be much more conservative.

For example, 'blog' was spun out of Drupal for version 7, in part because it did not belong in core but also because of the things I mention above. This caused 'blog' to cease being cutting edge.

I would agree that a stable i18n method would be good for Drupal, but also remember that PHP itself only started sorting out i18n recently, and there is still work to be done in PHP.

In short, be careful what you wish for. :-)

Benj (not verified):

Yes, it's time to complete the incomplete implementation of multi-language support in Drupal. Right now it really feels half done.

Yoav (not verified):

+1 for multi-language i18n.

The lack of multi-lang support is the #1 pain for 4 of my clients, serving the EU community. Doing Business Dev and Marketing on Drupal Gardens

Anonymous (not verified):

The 5 strategic directions are on the mark!

- Interoperability: Drupal should join the OASIS's CMIS technical committee,

- Web services: The Web Services API and Web Services are awfully neglected. There isn't even a beta. If Drupal is to grow and get a foot hold in the corporate and government enterprises, Web services and interoperability are top priorities.

- User experience: Accessibility, Accessibility, Accessibility.

- HTML5, WAI-ARIA, Mobile devices.

- Content staging: Absolutely needed to compete with the big boys in the corporate and government world.

All the best to Drupal 8 !!