Drupal 6 has been in a code freeze for more than 6 months and is almost ready to be released now. We're only a few bug fixes away from the Drupal 6.0 release. Therefore, I just created the DRUPAL-6 CVS branch for Drupal core. This means that while Drupal 6 is being finalized and we prepare for the Drupal 6.0 release, we'll also start accepting new features and improvements for Drupal 7, the next major version of Drupal.

In my State of Drupal presentation in Barcelona I hinted about what would be the killer Drupal 7 release according to a survey I conducted. While that list is not exclusive and nothing but a wishlist (not a deliverable), it might be worth a look if you want to help shape the future of Drupal.

If you don't want to watch the entire video, here is the executive summary:

  1. Better media handling
  2. Custom content types in core
  3. WYSIWYG editor
  4. Better performance
  5. Better tools to structure/organize content
  6. Basic Views like module
  7. Automatic upgrade functionality
  8. Improved node access system
  9. Better internal APIs
  10. Better external APIs (import/export, web services)
  11. Usability

Expect me to blog more about these in the next couple of months.


A. drupal them… (not verified):

Awesome, somehow I'm getting the feeling that 7.0 is going to be The One. The one stable release that overshadows them all.

I know Drupal is already growing explosively, but we're not yet closing the gap with those "easier systems".

If the planned usability improvements, and partial, or even full core integration of CCK and views can be accomplished, I think the 7.0 might start breaking into the more technically impaired (no offense) Joomla user base.

TimothyP (not verified):

Web services would indeed be very nice. It would open a lot of doors, especially for those of us who aren't real PHP fans. I see desktop integration, dashboard widgets, etc. :-)

Håvard (not verified):

heh.. without WYSIWYG Drupal is dead.. Think about all the "comtuper-dummies"-customers out there.. Other plattforms have WYSIWYG as top priority,

david (not verified):

I'm learning Drupal so i can make a website for my village. but until WYSIWYG appears - & has a real easy image upload feature in it - i can't even think about rolling out a site

[ my village is full of people like my mum. & she won't even search for stuff on Google without asking me for help ]

oyun (not verified):

Usually I don't need any WYSIWYG, but I think that powerful but simple WYSIWYG could help a lot in spreading Drupal to less technical skilled users.

Mehdi Abbasi (not verified):

This is great to support RTL in core without any patch!
Your website blocked in Iran! Many of blocked websites in Iran is left and socialist and communist organization and parties. Are you socialist?

Christopher Pelham (not verified):

If Views 2 (and perhaps at some point Panels 2?) come into Drupal core (or even if they don't), then I think it will really help to develop better tools to structure/organize our Views and Panels, but especially Views as people probably create more Views than Panels. This may seem like a minor point, but Views and Panels (or mini Panels anyway) are themselves bits of content and it's very inefficient to have to page through one long list of them. It's certainly not as bad as managing images/media but still. One could say the same of feeds, and other objects that accumulate in Drupal. are these all best left to 3rd parties to develop different approaches of organizing and presenting?

Another idea...
In terms of user management and desktop/web interoperability, I think a LOT of people and organizations would like a SUPER quick and easy, better yet automated, way to keep their email address books (whether desktop based or gmail/yahoo/etc based) synced with their CMS and CRM user lists. Some people have access to personal lists as well as company-wide lists. etc. it's a big, complex job, but if it could be made to just work, so that wherever I am and whichever program I am in, I have access to all my addresses and accounts, etc. ... wow! holy grail. we may take a small step toward this as we develop better google apps integration.

Anonymous (not verified):

OOP? Please say Drupal 7 will be OOP, I wished 6 was. Let's make things beautiful.

Anonymous (not verified):

No OOP. Drupal should be easy to learn. Leave OOP to the bloated Java and .Net. And Drupal is slow enough, let's not make it slower.

How about more flexibility instead in the 7th version? Blocks aren't really core, so if one wants to they can disable the Blocks module. If the site has only one author, there should be an option to disable Filters module. And Revisions and logging should be a separate module IMHO. And there should be an option to turn off Anonymous sessions.

Shecky (not verified):

If I might make a plea, it would definitely be better-optimized database interaction in general. This is the single most serious factor in scalability of Drupal, especially if one is using modules such as Relativity, Taxonomy, etc. For example, a site I'm currently building in Drupal makes 75 queries simply to load a basic page...fancier pages are much worse by orders of magnitude.

The ability to disable anonymous sessions would also be an enormous help in terms of basic scalability, for the same reason (reduced DB interaction).

I'd also second the motion in favor of OOP, or at least a basic Class structure. Anonymous 2 is mistaken: OOP and classes do not slow things down. The benefits of encapsulation, class extension, etc. etc. should be pretty obvious.

But frankly, the data issue is way more significant.

Thanks for listening...

Denis (not verified):

I believe that OOP is the most important change request now! I really believe that Drupal should have a good OOP architecture. I think you should not delay with it. Quality OOP architecture will make the system more flexible and more easier for developers. It will allow reuse (and make more reusable) much more code. It will allow use and apply all standard OOP patterns in common way. So eventually it will make Drupal more clear,easier and convenient for developers who used to think in OOP (I think that now the most of developers know OOP, patterns, etc.)

I think you are agree that OOP is a mainstream and one of the most important and useful stages in programming. So why does Drupal go against of the mainstream? Why does Drupal try to invent a wheel again (e.g. implementing basic OOP paradigms with procedural approach)? Why does not Drupal uses the most programming language features and uses just a part of them and so restricts oneself?

I really like almost all ideas and conceptions of Drupal: very flexible module system, very flexible themes system, great multi-language support, taxonomy, multi-siting, etc. All these are brilliant. But I don't like implementation based on procedural paradigm. I believe that such brilliant system as Drupal should use the most powerful paradigms and approaches. Hope that in next versions it will be on the way.

PS: sorry for my English, I am from Russia.

Alex (not verified):

I am agree w/ Denis and the others who vote for OOP. Drupal would be much more awesome w/ good OOP architecture. It won't make Drupal slower and it makes the system easier. Don't afraid OOP. OOP is not evil, OOP is the kind! :)

Lars Pohlmann (not verified):

I might begin working on Drupal projects soon, so I browsed through the Drupal sources to get some feel for it.

And though it is very clean, structured and well documented, it really gives me the shivers to be forced to go back to procedural programming, I thought I left that once and for all ...

Writing good procedural code is much more difficult than writing good OOP code.

So OOP in Drupal, that'd be great.

Max (not verified):

Drupal is a great system! I like it! Thank you Dries :)
However we had to implement self OOP layer for Drupal to make the system more "OOP"-friendly and to write more code in OOP style. So please make Drupal 7 OOP-based system.

Preston (not verified):

OOP +1.

And full i18n integration, from scratch!
I think the localization system of 6.x release was nice, but to be honest and working everyday on translated Drupal's, we always need the i18n module as the core system is clearly not sufficient.

Anyway, thanks for the really good job done!

DruRoot (not verified):

I like the idea of OOP. I especially like the cakePHP and Zend frameworks which utilize the MVC pattern.

While the developer in me would love to see some OOP/MVC shiftage, I think that it is much more important for the growth of drupal to make the core more powerful for those Drupal users who aren't developers.

I think the biggest and most important step would be a tight integration of Views and Panels into core. If this were well implemented and, more importantly, easy to use, I think Drupal could take marketshare from those simple CMS tools like WordPress and Joomla.

Tam Nguyen (not verified):

Better performance will be good. We should make drupal 7 be a good choice for an enterprise application. Another important thing is a better media handling. For WYSIWYG editor, I think TinyMCE or FCKEditor is OK.

Jonathan (not verified):

I know that I'm late to the party, but I think the most important addition to Drupal 7 would be automatic updates.. not only because it's easier but also because it's far more secure. OOP would be my number 2, custom nodes 3 and an improved Views feature 4. THEN media handling, then the rest.

Wim Mostrey (not verified):

The more Drupal 7 takes shape, the more it looks like neither Views nor CCK will make it into the release and I'm not really sure why that's the case. CCK and Views are two powerful modules that Drupal offers over various other content management systems and still we're not including even trimmed down versions in core. There are a whole lot more people waiting for Views in core than, for instance, having diff in core.

One of the arguments against Views in core mentioned during the Drupalcamp Montreal's presentation on Drupal 7 and other awesome stuff is that Views would not be mature enough. There's also the argument that modules flourish better in contrib than in core. While both arguments have a grain of truth, it's also true that Drupal lives on cutting edge technology. This is one of the main reasons why Drupal has (had?) such fast release cycles. So I really hope we're seeing at least a Views mini and CCK lite in Drupal 7.

EdgarPE (not verified):

I'm totally against OOP. It makes simple tasks harder to implement, now straightforward code snippets harder to understand. I really don't think it gives us more reusable code.

Another big minus for automatic upgrades. No way, I my code base changes, I want to know exactly what will change.

So for me, these are the most important:

1 Custom content types in core
2 Basic Views like module
3 Better performance
4 WYSIWYG editor
5 Better media handling

Anonymous (not verified):

My number one request for Drupal 7:
--non-anonymous caching
IMHO this will make Drupal sites fly and completely blow the other CMS's out of the water.

ibandyop (not verified):

+1 Advanced Forums
+1 Caching for Non-Anonymous pages

Miguel (not verified):

New Drupal should contain the most powerful module like Views, Panels and CCK, optional also: Rules, Quicktabs. Moreover should be more OOP. Something like Zend Drupal MVC, would be very nice ;)

Paul (not verified):

1. OOP - IMHO is a must for any enterprise level solution.

2. Asset management - WYS editors will come and go, but a good asset management API I think is key. Document and image security is a must.

3. External Database/Schema mapping - the ability to use a different database or schema to store your user/ecommerce information, that crosses platform barriers. The ability to read user info from a membership management system, like iMIS or the like is a must for clients that already have a membership system in place, but require a CMS front end. It would just be great to translate database fields to drupal, then you could tie all your membership/inventory/whatever pieces together with Drupal. This would also be fantastic for creating connections with the views/cck/civi branches, so it can read external schemas natively.

I haven't read a lot on D7 or D8, so please bear with me, but to me it just seems like going "Enterprise" for Drupal should be about the ability for Drupal to adapt to newer or legacy technologies easily. This includes older Drupal modules.

I don't know what I would do without half of the modules here, but I gotta admit, it would be fantastic to be able to easily replace somethings Drupal outright with third party solutions. AND I also think that having the end user community depend less on community developer's development track (which can protract out very far, or have no release, sorry no offense intended) it allows end users, especially non-developers, to use Drupal as their catch-all solution and use the 3P tools they are willing to pay for.

I just think that in moving forward with Drupal, you have to respect the fact that for every version change, we are setting back our module developers, which is the whole reason to use Drupal.

I guess I should say, one version of drupal to rule them all and that is how I would approach it.

Michel (not verified):

+1 OOP!
+1 ORM
+1 More powerfull User Management, ACL, etc..
+1 Better perfomance, Caching for Non-Anonymous pages
+1 Even better i18n

Scaffolding maybe also will be a good thing.

Anonymous (not verified):

What's funny is how many people here call for OOP as if (a) it is a magical wand one can apply to a codebase and all of a sudden everything is "better", and (b) at the same time, completely fail to offer an actual example of a part of Drupal core would benefit from the entire thing being completely rewritten OO style.

Zewa (not verified):

I agree with the previous post that everyone tends to OOP stuff up, just for no real need.

If you take some looks at code and performance comapring OOP with Proc style, than you have to realize that ones proc style is written clear, and bulky stuff is done with some object aspect it is always faster and more reliable than pure OOP or whatever else.

I'm quite new to the whole dev stuff with Drupal but the idea of Hooks is a really exiting and totally interesting part for me. I think that expanding that stuff is an investment far better than drilling some object paradigms into good and solid code.


Mark (not verified):

I have to say that automatic updates, similar to that in Wordpress, would be a major leap forward for D7. Also the blog and forum are good but I still use WordPress and phpBB. This is where I feel D7 can make up for lost ground and truly make Drupal a first class CMS and community orientated platform.

Keep up the great work : )

dbeall (not verified):

I am a newbe with Drupal since the first week D6 popped up. I think the whole system is fine or better than that.

* I have few text labels that i change with every core update. but whatever.. 'only a geek knows what tracker means' lol..

* Last wish first. Boost module all done up right. It is getting there and makes a huge difference for shared hosting.

* If I had to talk about a task that gets old, It would have to be the routine of putting modules up.
It would be neat to click the download link in the updates list and have it go right to the file system and unpack it's self.

I could make a nitpick list that would go nowhere, but the module thing is repetitive.

I can not say enough about the admin_menu ..nice..
The community has been amazing ever since day 1 ..cool..

Rock (not verified):

It would be good if D7 provides remote installation of modules similar to Joomla.

As an admin (Non developer), i should be able to download any module on my desktop and should be able to upload on to Drupal instance. The drupal instance should unzip the module, installs and enables it by itself.

weird (not verified):

Bad news for me yesterday. My client, also my boss,decided to drop Drupal because he finds it too slow (yes, even the pristine Drupal site without contributed modules installed is not fast enough for our users).

Please improve the performance (speed) of Drupal.

I think Drupal is really a good and well-designed CMS but it is simply not fast enough. Okay, it may be faster than Joomla or Zope/Plone (anything written in Python isn't fast) - but that's not good enough. It just isn't fast.

Jay August (not verified):

With all due respect: get a better hosting platform. Drupal isn't slow when hosted on proper hardware, with ample resources for Drupal to work with.

I do admit that speed can be an issue sometimes, but I found when giving Drupal enough resources to work with, it won't let you down.

eirc (not verified):

With all due respect: If it needs special hosting, that's a problem.

My experience is that when running Drupal on a local machine with more or less unlimited resources, it's often cruelly slow unless I've got caching turned on and am browsing anonymously.

Bill Bell (not verified):

My votes:

- Improve the admin UI. It would be good to see the menu items listed under a module. I often look at the module php file to see the menu hooks. Advanced?

- Integrate Panels and drag and drop into a page.

- REST and Web Services

- Zend and more OO

- Ability to see all hooks in the admin GUI, and put code there directly. (or call a function)

- Support for MS SQL and Oracle

- Better caching support including load balancers

David Karlin (not verified):

I'm currently on Drupal 5: at the moment, my custom modules tend to use my own database table and AJAX libraries, because I find the CCK and Drupal forms combination too restrictive. I just can't implement the flexibility of UI that I want. Furthermore, writing business logic to find CCK fields is really pretty tedious.

So top of my list is to get CCK and Views into core, preferably with some major enhancements.

Although I've done loads of OOP work in the past and I'm a big fan of OOP, I'm relaxed about the need for OOP in Drupal.

sun (not verified):

heh - did I miss that in the keynote eventually?

  1. Better media handling -- Done
  2. Custom content types in core -- Done
  3. WYSIWYG editor -- D9, maybe
  4. Better performance -- Fail
  5. Better tools to structure/organize content -- Fail
  6. Basic Views like module -- Fail
  7. Automatic upgrade functionality -- Almost done
  8. Improved node access system -- Done
  9. Better internal APIs -- Done
  10. Better external APIs (import/export, web services) -- Fail (AFAIK)
  11. Usability -- Done + Fail ;)
David (of Melo… (not verified):


> heh - did I miss that in the keynote eventually?
> 1. Better media handling -- Done ...

Wow! That's really interesting!

Since you're working closely on the Drupal development, could you please update this list now, 3 months later?