Starting to work on Drupal 7
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:
- Better media handling
- Custom content types in core
- WYSIWYG editor
- Better performance
- Better tools to structure/organize content
- Basic Views like module
- Automatic upgrade functionality
- Improved node access system
- Better internal APIs
- Better external APIs (import/export, web services)
- Usability
Expect me to blog more about these in the next couple of months.
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.
February 4, 2008 - 18:26Web 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. :-)
February 4, 2008 - 23:34Usually 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.
February 5, 2008 - 18:48Usually 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.
February 7, 2008 - 13:05This is great to support RTL in core without any patch!
February 10, 2008 - 13:30Your website blocked in Iran! Many of blocked websites in Iran is left and socialist and communist organization and parties. Are you socialist?
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...
February 11, 2008 - 00:30In 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.
Extend forum capabilities.
February 13, 2008 - 16:04OOP? Please say Drupal 7 will be OOP, I wished 6 was. Let's make things beautiful.
February 19, 2008 - 16:46No 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.
February 24, 2008 - 01:30If 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...
April 8, 2008 - 01:30I 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.
April 12, 2008 - 02:50I 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! :)
April 18, 2008 - 11:42I 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.
April 18, 2008 - 12:18Drupal is a great system! I like it! Thank you Dries :)
April 19, 2008 - 12:36However 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.
+1 for OOP. I've worked with the Zend Framework for 2 years now and I'd like to see Drupal 7 use MVC.
May 29, 2008 - 16:24Post new comment