Starting to work on Drupal 8

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 <a href="http://affinitybridge.com">Ariane Khachatourians</a>.

Drupal branch

A screenshot of my screen after we created the Drupal 8 branch.

Comments

Jonathan Wagener (not verified):

Awesome :D - i look forward to developing Drupal 8.

March 17, 2011
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. :)

Dave

March 17, 2011
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...

March 17, 2011
Steven Behun (not verified):

Awesome! Can't wait to see it!

March 17, 2011
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?!

March 18, 2011
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 :)

March 18, 2011
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. :-)

March 18, 2011
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.

March 18, 2011
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

March 30, 2011
Anonymous (not verified):

The 5 strategic directions are on the mark!

- Interoperability: Drupal should join the OASIS's CMIS technical committee, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis

- 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 !!

March 18, 2011
peach - soopert... (not verified):

Content staging could be on top of the list IMHO, its one of the few reasons that big companies have to pick a m$ sharepoint based solution over Drupal.

March 20, 2011

Add new comment

© 1999-2014 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.