Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By Dries on
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 first final 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.
For maximum effectiveness, feature requests for Drupal 7, should go in the the list of feature requests. 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, the community's collective wishlist looks like this:
- 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
Just like with the Drupal 6 branch, I probably won't pick a Drupal 7 branch maintainer until we're a few weeks or months down the road and people have picked up core development.
Comments
Time flies..
Seems like just last year 4.7 was still new! The list of possible features for Drupal 7 looks very promising, I think integrating editing and content handling will bring in a large audience, and better upgrade functionality would be great.
--
John Forsythe
Need reliable Drupal hosting?
Error?
Did you you mean that you just opened the Drupal-7 branch? Hasn't the Drupal-6 branch been open for a long time?
DRUPAL-6
Hi!
Dries means the "Branch point for: DRUPAL-6" have been created. In other word, DRUPAL-6 is now separated from the "MAIN" branch. This is great news since it means there won't be any RC4.
Before "DRUPAL-6" we had "DRUPAL-6-0-RC-3", "DRUPAL-6-0-RC-2", ..., etc. Drupal 6 finishing touches goes in "DRUPAL-6".
There are no Drupal 7 branches, not yet. But you can consider "HEAD" being Drupal 7 dev, since today.
I do not have any CVS access, so feel free to correct me.
Cheers.
/*_*/
http://www.xmacinfo.com
there could very well be an RC4
The branching does not mean there will be no RC4, there could easily be an RC4 on the DRUPAL-6 branch.
Link to D7 issues
Here's a handy link to all issues in the 7.x-dev branch.
wow
Wow, one and a half page already RTBC, good start :)
and a half page RTBC
actually, it is only 14
what are the odds?
ok
Would it not make some sense to NOT turn it into a "free for all" just yet on Drupal 7 development,
but to keep the code semi-frozen until all the features that ALMOST made it into Drupal 6 have been included.
(eg proper timezone support; finally getting rid of the 'book' paradigm, etc.)
Proper timezone support, for example, missed Drupal 5 and Drupal 6 ... and it seems kind of basic doesn't it?
So, wouldn't it make some sense to only allow that type of stuff for now... so it can finally actually make it in
Otherwise we WILL miss again out with Drupal 7
If you want it in, you need to help
The way this works in open source is people have itches, they scratch them. Other people don't scratch your own itches for you... at least unless you're paying them. ;)
Step 1: Take a look through the issue queue, groups.drupal.org, and the devel list archives and identify places where people have already discussed and done work on your itch. For timezone support, at least two major discussions/issues stick out in my mind, but there could very well be others.
Step 2: If you're a developer, roll up your sleeves an dig in. A lot of the work/thought has probably been done for you by other people with your itch to scratch. Seek out the developers who've come before you and see if they're open to being asked questions as you go through; often times they will be.
Step 3: If you're not a developer, don't despair; there are still ways you can help! For example, you can make a public commitment to thoroughly test the solution, which will in turn make developers more likely to work on it. You can talk to the main developers who are working on those issues and see if you could help raise funds to get the patches coded faster. You could offer to do time-consuming research tasks (e.g. are there other timezone libraries that other projects are using) and take the results back to the group.
But, demanding that others to work on something, despite how "basic" it might appear to you, is not the correct approach. That's the strength of open source: the power is in your hands to change things.
I don't remember the details
I don't remember the details but solid time zone support is not basic and the feature freeze for Drupal 6 was in effect for a looong time now.
But here's a tip for anyone with an itch they can't quite scratch themselves. Monitor the issue queue with the keywords your interested in. Go into advanced search, type your search terms and leave everything at its defaults. In the results pages you'll see an rss icon & "#" sign.
Click the rss icon and push it into your feed reader or bookmark the pound sign and monitor it. When someone comes up with a solution then test it.
I've seen tons of patches get lost because no one reviews them. Let's prevent this and review more patches.
⎋ joon park
Excuse me if this is already
Excuse me if this is already on it's way (I'm a newbie, so excuse my possible stupidity)
- nested lists in menus secondary_links should loop into each primary_link ... I would like that to be very easy
Also RSS. A seperate feed per page as default is weird IMHO. I expect feeds to be site wide (unless stated otherwise, like section wide).
Let's not close this too fast... we need to see what issues arise in Drupal 6 first
Drupal 7 branch maintainer
A simple question about branch maintainer: is it still a one man job? I think, there are more and more patches coming for drupal core with every new release. Do you think one man will be able to handle all of it without a problem?
And here I would like to thank Gábor for maintaining Drupal 6 branch, incredible work. Amazing speed and quality with handling all those issues and patches.
I believe Drupal 6 will be the starting point of drupal massive expansion.
One branch maintainer - two more branch committers
I think the concept of having one branch maintainer has proved to work out well. And Gábor really did - and still does - a great job! Under rather hard circumstances he kept the whole D6 development process rolling, which obviously cost him an incredible amount of energy and time. We all hope he won't be completely burned out after D6 finally releases, but steps a little back and focusses on the missing translation features, where we need his knowledge so bad...
During the last weeks we all were faced with the fact that Dries needs to split his time between the Drupal project and his new company. While I fully respect Dries' decision, this meant that Gábor was more or less the only core committer accounting for some 90%+ of committed patches (see: #216077, Dries' commits start with "- Patch", Gábor's commits with the issue #).
As this is probably unavoidable in the future as well, we would need to give the branch maintainer support by one or two more branch committers. This would enlarge the actual bottleneck in the patch process.
PhD defense
I was actually defending my PhD last week. Plus, I talk and coordinate daily with Gabor so it's not like I've been terribly slacking, eh.
C'mon Dries, not for a
C'mon Dries, not for a fraction of a second I thought you would be slacking! It's just that even with a 24 hours working day, you can't save the world all alone... :)
Seriously, this is nothing less and nothing more than a proposal. If we do have three people experienced enough for such a role, I think that it would be a good idea to take some of the burden from the branch maintainer.
No offense, just an idea :)
Pancho
If we have more testers then
If we have more testers then comitters have to spend lest time.... testing? no need for extra comitters, need for more testers.
Sometimes something interesting appears on http://litwol.com
branch committers
I like this idea. If there would me more people they can pass decision on issues to each other depending on their expertise.
Is it open for discussion, or is it determined, that the actual state remains?
Will be there 2 more acceptable volunteers for this top position?
How do you pick the right people?
Yes, the testing is a problem also. But I am sure you can find issues which stayed too long in RTBC state, without a comment what is the reason which holds it back from committing.
Maybe we can ask Gábor what he thinks about the work spent on core issues and committing patches. He have the most recent experience with maintaining drupal development branch.
Yes, the testing is a
It's not "also" the problem. It is the problem.
Compare all the RTBC for 6.* & 7 to those that need review.
Actually, a better comparison omitting 7.
RTBC | Needs review
⎋ joon park
it is not that simple
I would like to wait for Gábor's comment, because I really think that this task must be overwhelming.
right now testing is the barrier
Right now, we need testers and reviewers for critical core issues. I spent the whole day yesterday (including over hours) testing, reproducing, coding fixes, etc. for critical core bugs (while I could have been working on better marketing for the Drupal 6 release as well for example). It would have been great if we could release RC4 yesterday, yet, the only two remaining criticals got very small attention. Instead of lamenting on Drupal 7 maintainers here, I'd be happier if we can get to the ground and get Drupal 6 done first. What's most lacking is strict focus on the criticals queue.
This is your link to follow: http://drupal.org/project/issues?projects=3060&categories=bug,task&prior...
This is not the right benchmark
This is not the right benchmark. Committing patches that are RTBC from my point of view is not even the most time-consuming duty of a branch committer.
The most important and most time consuming duty of the branch maintainer is guiding issues (and patches) into the right direction. Comments like "We can't do it this way. Stay in line with... and use function xyz." or "This is a good idea, but you need to elaborate on this and that" are often needed for a patch to reach RTBC status. A "Don't waste your time on this. This patch won't make it, because..." is equally helpful. This is something only very experienced and/or very professional core committers can oversee.
While this doesn't release core contributers and reviewers from doing their job, it prevents them from working into a wrong direction and enables them to making the next steps.
Maybe the one or two assistants I propose, shouldn't be called committers, but guides. They would guide the patches all the way to RTBC status, and then the branch maintainer would have the final decision and commit the patches (or reject them). The guides should be able to step in for the branch maintainer, though, while he is on vacation, takes a long weekend or even a week off (which should be possible to avoid burning out the branch maintainer). So we need a team of equally experienced developers with a 'primus inter pares'.
Surely, Gábor's (or Killes') experiences would be extremely valuable to this discussion.
One API expert, one functionality "enabler"
Yep! That would be a strong argument for this.
For example we could have one expert for APIs, databases, general code structure and enforcement of the "General Drupal philosophy". This might be the maintainer of a preceding branch.
The other one could focus more on new functionality and usability. That could be the preparation job for the next version's maintainer.
Just an idea, but maybe a good one...
Better media (and file)
Better media (and file) handling and much better performance would be nice. I'm just learning Drupal 5 now :), but I'll look forward to find ways to help. Maybe core dev one time. For now I'm just testing.
Mysql 5 feature
Hi,
I want better APIs and better performance.
Is Drupal 7 is going use Mysql 5's advance features?
---
Sharique uddin Ahmed Farooqui
Web Developer
http://it.Managefolio.com
Sharique Ahmed Farooqui
http://www.openahmed.com
I want a pony
and a billion dollars.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Pony's are messy
But with that billion dollars, you could hire someone to clean up afterwards :)
Doug Green
Well the obvious answer to
Well the obvious answer to your conundrum is... chx has a pony! OMG PONIES!!!11
But seriously, if you want 'better APIs and better performance' you'd better help the rest of the community achieve it. There's really no point demanding things, then complaining when they don't happen.
Is Drupal going to support MySQL 5 advanced features? Or put another way: are we going to drop support for MySQL 4? Don't think this has really been discussed, you should get on the dev mailing list and state the case for transaction support. If all the Drupal project cared about was 'advanced features' though, MySQL support would have been dropped long ago. :)
You'll get out of Drupal 7 what the community puts in, and you are part of that community.
----
Web Design, GNU/Linux and Drupal.
Well said!
"You'll get out of Drupal 7 what the community puts in, and you are part of that community."
I like that. :)
Ask for suggestions, you'll get suggestions.
Perhaps instead of a post asking for suggestions on what people would like to see in Drupal 7, it would've been better to say "Have some ideas about what you'd like to see in Drupal 7? We don't want to hear about it! Get to work and maybe someone will take you seriously, user."
Hm?
Nowhere in this post did it ask what people would like to see in Drupal 7. It simply reported the results of a survey months back that asked that question.
The Drupal community doesn't work off the concept of "wish lists"; instead we work off the concept of "battle plans". See http://drupal.org/node/216301 for a list of what everyone's planning to work on. Feel free to add things that you're planning to work on to the list as well. :) There's a whole lot of things that "users" can do, and many of them aren't currently being focused on by existing contributors.
The Drupal community doesn't
Then why does the form allow you to submit feature requests? Some authors definitely only take patches, of course. But it seems that the feature requests which get the most attention have driven development to some degree.
That said, asking for performance updates is pretty silly. I don't think anyone is thinking "hey, the web is fast enough. let's stop here."
Agreed with Chick-o-the-Web
(that's her name in Gaelic!)
To rephrase your statement:
There's plenty of work, and plenty anyone can do! Even working on items unrelated to what you need is important, it will help clear the path so developers can get to what's important to you faster. Remember: together we stand, divided--bitching over who does the work--we fall. :)
----
Web Design, GNU/Linux and Drupal.
Make it Enterprise class
Make Drupal enterprise class CMS.
User transactions, stored procedure, views, etc.. to make Drupal more suitable for enterprise applications.
--
Sharique uddin Ahmed Farooqui
Web Developer
http://it.Managefolio.com
Sharique Ahmed Farooqui
http://www.openahmed.com
"Enterprise" has no meaning
"Enterprise class" is a Star Trek reference. It has no actual meaning in the real world. Just because an application uses SQL stored procedures does not in any way shape or form make it "enterprise-ready", nor does not using them make it not enterprise-ready. "Enterprise" is a marketing term with no useful meaning except to declare something "not enterprise-ready" for arbitrary reasons.
Drupal is already running sites serving millions of pages per month, with complex application logic, integration with 3rd party systems, and rich multimedia. Drupal isn't just ready for large sites; it's powering them already.
--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
WYSIWYG editor & Document
WYSIWYG editor & Document Management are must for Enterprise CMS.
beam me up Scotty
It would really nice to have better integration with Wysiwyg for two main reasons. 1. I'm tired of hearing this argument. 2. Some of the projects I've worked on demanded TinyMCE and I always cringe at the thought. Anything to make it easier I hope would eventually lead something lighter weight and efficient. I think we'll get there soon with jQuery.
⎋ joon park
–www.dvessel.com–
What is necessary for WYSIWYG "integration"?
What's wrong with the current modules? I've used three of them (xinha here, fckeditor, and tinymce) and they all seem to work. I have tinymce installed on my D5 site and will play with fckeditor on my D6 sandbox.
The CAPTCHA module seems to have an ideal method for adding itself to forms (although I could use a little more modularity, like a weight control... but this is not the place to talk about that) :) Perhaps an approach like its is a better solution for selecting where WYSIWYG is used.
Honestly, I don't see what the Drupal project can do about this aside from adopting some WYSIWYG editor as its own. Which, I think, is unnecessary.
From what I've heard (on the
From what I've heard (on the grapevine) is that a WYSIWYG editor should change it's functionality according to the input filter in use. Currently this is extra overhead for a Webmaster. :)
----
Web Design, GNU/Linux and Drupal.
I've often fantasized
I've often fantasized (sadly, yes, probably the right word) about having an input filter system in which you simply set access rights to permit users to use filters, gave all filters weights in a single master list, and then the user could simply use any features to which they had access. Unfortunately you'd probably need some sort of exclusion rules on top of that, which would be ugly. I wonder if anyone else has been thinking of the same thing.
I do not however see any reason why the editor module could not see which input filter is selected when the editor is invoked (walking the page tree if necessary) and then find out what filters are set for that input format, then activate any appropriate plugins. While it would be nice to see this in the core, perhaps there is room for a single contrib module which does the first part; the module's plugin setup can handle the second.
nice ideas
some ideas of the feature request list are looking realy promising.
I am curious which features will do it into drupal 7.0
Foreign Keys and Transaction support
Transaction support (if not provided) would certainly help in making drupal cms a serious contender for transaction safe applications.
Yashesh
Yashesh Bhatia
Comment system
Is comment system going to change?
Having comments as nodes (along with advanced caching) would be a great opportunity to open up node APIs to comments.
Also, how about advanced views caching?
Extended theme API (improved Zen).
Delf.
Based off personal battleplans...
The direction that Drupal 7 goes in and the features that are put in is directly corresponds to what people end up working on. You can get a broad sense of this in the Drupal 7 Personal Battle Plans post, where various contributors talk about things they would /like/ to work on, which may or may not be what they actually manage to accomplish. There's also no reason anyone else can't also have their own particular "itches" they'd like to work on as well.
I doubt you'll see comments as nodes, however. But you might see forum replies as nodes, if a couple of people who are working on forum improvements make it so.
My vote for better performance
I know drupal 6.0 comes with great performance improvements. But Drupal 7.0 must also keep performance on top of the list.
I have not tried Drupal 6.0 yet largely because of the dependent modules. Once all the modules support Drupal 6.0 I will be able to move this free press release distribution site to Drupal 6.0 and take advantage of performance improvements. It will be nice to have more module, block, view and theme level caching. We are already using sql query cache, eAccelerator etc for our site. Page level caching is not flexible enough for our site. Category module and all dependent modules are one more performance bottlenecks. We have already done enough hacks to improve the performance of category module. I wish I can improve response time by 100% with Drupal 7.0.
Forum
I honestly thought the Forum module part was one of the most requested parts that users wants since the current is too much blog-a-like and doesn't contribute any positive for the most who wants a real forum under their site.
Advanced Forums project and DruBB group is though a good project and group, but still it should be considered as part of Drupal 7 development.
Roberth Andersson
Administrator/Developer @ Jump-Gate and Webworqs, Inc
Forums
http://groups.drupal.org/node/8598
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
subscribe
subscirbe
Cool, I am newbies in
Cool, I am newbies in Drupal, but I plan to bulid all my Internet Marketing related sites using Drupal, and glad to see a passion team to improve the product.
Feature requests
- I'd like the admin interface in the CMS to not clash with theme styles
- Views can so much simpler. It takes too many steps. Also views in blocks.can be much easier.
...
"I'd like the admin interface in the CMS to not clash with theme styles"
This FR makes no sense because there's no way to make a default admin theme that won't clash with any theme out there. But since you can choose what theme to use for admin, it's a bit of a moot point.
"Views can so much simpler. It takes too many steps. Also views in blocks.can be much easier."
The new views UI is nearly done so it's too late for FRs on that. While it's 1000% better than the old one, there are still a lot of steps involved. I don't see how they could be shortened any and still have views be flexible.
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
Actually, good point about
Actually, good point about the CSS class names clashing with admin and theme styles. I think Drupal should uses a few fixed class names. If we know what they are we can avoid them. Those class names that Drupal would use should not be names like .content or .news which is used at the moment. That is a name most users would like to take and which they use on most sites... maybe .dp-content and dp-news are a possible alternative
Also I'd like to be able to avoid the jquery issues from Drupal 5, but then in a wider scale. It should be possible to upgrade jquery as well during a Drupal version without it messing up the admin functions... possibly by protecting the jquery functions to administration with namespaces dp-whatever.
Oh, that way
By clashing I thought he meant colors/styles. As in not matching the rest of the theme. Avoiding namespace collisions makes sense.
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
Those class names are fine
The problem is that they are sometimes nested in elements which are classless. And depending on where you're seeing some content it might be different. So making sure that every element has a class and/or ID and that everyone uses sufficiently complex selectors to be unique should be plenty.
Now, what I'd like to see is some scheme for preventing module authors from trampling each other's page variables, like forcing everyone to have their own namespace. That way you could only trash someone else's variables intentionally (which might be useful.) At least in D5 this is currently causing an interaction with like half a dozen modules which all use
$pid.hmm
there are 47 issues in RTBC for drupal 7
.....
subscirbing
-- Sree --
IRC Nick: sreeveturi
Backwards compatability
I know this has been brought up elsewhere. I'm adding my voice here.
I would like more emphasis placed on migration paths.
I'd love to see a new enforced rule for checking into Drupal 7:
You can change anything you like, so long as you add to some sort of script somewhere something that automatically updates modules from the old way to the new way.... just like the install script, but for modules, not for the database....
(This would only affect changes to API's of course)
People should - of course - be free to change whatever aspects of the data and API they think fit, (Break backwards compatibility) in order to take advantage of new thing, BUT...
What I'm asking is that people think of ways of transforming old into new, programatically.
For sure, this isn't always going to be possible, but, as I say, I'd like to see more emphasis on it. Indeed, for me, I'd rather see this than "testing" - as I think it could greatly assist in testing!
This would mean - we could all install 7 today, using '6 modules, then, as time goes on, fixes will be made, changes will happen, and - theoretically - things will keep working.
Yes, this increases the work load, BUT....
This does a whole lot of very good things:
Frankly, throwing everybody off the train once a year, and hoping they scrabble back aboard, just before they are thrown off again isn't such a pleasant experience...
I used to believe web sites were "written once" - that's clearly wrong - so upgrading, and moving forward, and staying "on the train" is HUGELY important...
I would really hope that the extra level of work isn't soo high, that the API's can be kept similar as much as possible, and that the extra cost of changes to the API is worth the huge benefit.
Cheers
Mark.
won't fix
http://drupal.org/node/65922
You can change and break anything you like, as long as you can convince others you are making something useful, and your changes get committed. The simpletest is an useful extra load on development. I am sure there will be no extra compatibility code or code transformation requirements for contribution..
If you care about faster module upgrade path, you can help with the development of coder module, and help upgrading modules.. that is less work, and *should be* much more better code than any auto upgrade can generate.. software can't write itself..
Drupal is an evolution, better and better solutions comes, what can't survive simply dies out.
And upgrading drupal websites is easy, I really don't see the problem here.. There is only one case, when you have problem with the upgrade, if you use too many self made modules without contributing them back to the drupal community. But whose fault is that?
Go enterprise class
Let's make Drupal enterprise class CMS,with the best usability even grand-ma able to use!
Ajax should be implement in back-end to increase usability.
www.designers.pro
"Design Professionals Community"
My plans
Hi! I'm a developer. Were it would be better to post some suggestions of system improvements? Now my foremost interests are perfomance and caching system. Unfortunately I don't found principial improvements of this components in Drupal-7-dev. Main disadvantages of Drupal's cache system (for my mind :) ):
1. ALL cache entries flushes after ANY administrative operations.
2. Caching works only for anonymous.
Now I'm tying to bring caching mechanism for all users (2) in the simple way. Also I want to try to develop frontend for nodes advanced filtering / examing. I.e. I want to try to use Drupal as CMF.
May bee, It wolud be worth-while to organize absolutely all content (comments, menu items, nowadays nodes ... ) with nodes. Every node will have any variants (not revisions, but variants, for example according to it's language). All components that generate output must be stored in one place. Any set of such visual components (views in the MVC-therminology) = theme. Of course, Drupal's architecture changes dramatically :))
I think, new ideas wold be appear :)
Sorry for not very excellent English :)