Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By sprite on
Looking through the modules listing, the vast majority seemed to lack 6.x support. This implies that people have abandoned Drupal in its current incarnation. What work is being done to support more modules in Drupal 6.x
None of the image modules have been updated for 6.x. How are people supporting image galleries in Drupal 6.x sites? What consideration has been given to making image management and at least basic image galleries a part of the Drupal core?
Comments
Drawing conclusions...
Actually, what it implies is that Drupal 6 is still fairly new, and that it takes a non-trivial amount of time to upgrade modules from version to version.
Drupal has nearly 2000 modules, and each one has to be upgraded by hand. It's not a small task.
Of course, it's more complicated than that, but 6.x is definitely not abandoned...
--
John Forsythe
Drupal Modules - Find the module you need for your project!
no image support/gallery modules available for 6.x
None of the image support/gallery modules has a release version that supports 6.x. What are people using for image/gallery support who are working 6.x? BTW, when was 6.x released?
I've been using Drupal since 4.7, as demonstrated by my posting history on this site. However, each major upgrade process has been almost too painful to bear, requiring major rebuilding of sites to endure. :(
spritefully yours
spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...
image.module
image.module has a dev release out and contains an image_gallery module too. Not released as stable yet, but they work.
So many "abandoned" modules
So many "abandoned" modules because each time there's a new release the modules need a re-work. Drupal kind of does it to itself.
yes - drupal seems to do exactly that ...
The Drupal development group seems to overlook the need to hold off release until an adequate group of its modules are ready, to make the core version adequately useful. The Drupal development group has not valued the need for easier upgrade processes at each major release. Between Drupal 4.x and 5.x I had to completely rebuild sites from scratch. It was very painful and laborious.
Currently, Drupal 6.x badly needs released versions of its various image and photo gallery support modules. Not one of the image support modules is fully working and available in release version for Drupal 6.x.
spritefully yours
spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...
There is no 'development group'
There is no road map or overall plan. There is Drupal core. There are people who contribute to core. There is Dries and the core maintainer who commit the contributed patches to core from hundreds of contributors. Core is released when it's ready.
There is no overall plan or requirement for upgrading contributed modules. None beyond that which the contributor and those who help them contribute. There is no community schedule for updating contributed modules.
So, while it is nice that contributed module maintainers have releases around the time or shortly after a Drupal core major version release, it is not now nor has it ever been a requirement. If people need functionality and support for certain features and want to use the latest, just released versions, then they need to help get that fixed. You do this by being involved with the modules you use and supplying patches when possible to update those modules. If you cannot do this, then testing patches others provide and providing feedback. And if necessary, supplying funding to get those modules updated.
This is how the Drupal development cycle has worked since it's inception in 2001. If using Drupal 5 works for you, then continue to use it. There is no rush to upgrade just because it is the newest release.
I suggest you and others check out the first chapter of the Getting Started guide for more information of exactly what comprises Drupal. Drupal core. The Features, Mission, and Principles of the Drupal Project. The first line of the principles stand out.
I also suggest you also read the text on the modules download page. Contributed modules extend Drupal but are not Drupal core.
I am unsure how this can be made more clear to people new to the community.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
incorrect presumptions ...
You incorrectly presume that the people making comments here are "new" to Drupal. To assess my longevity, check my profile.
It is also ridiculous to argue that there isn't a "group" or "team", because there is a "core" "group" of people who make decisions about when to organize release dates, as well as core features and architecture. In any event, no matter how that "core" "group" of people have done things in the past, a hallmark of "quality" is the ability for "groups" of people to be flexible, to change, to evolve. Maybe it is time for the people most "involved" with Drupal to consider improved ways to synchronize development of Drupal core with at least some of its essential modules.
spritefully yours
spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...
...
I do not presume people posting here are new. You've assumed incorrectly. I am asking how we can clarify it or make it even more clear for new people because you seem to have missed that and you stated your long term involvement earlier. If people using Drupal can miss this important fact of the project and all the notices and documentation we do on this, then we need to make it more prominent or more obvious somehow.
And I disagree, it is not ridiculous. There is two people who determine release dates. Dries and whomever the current branch maintainer is. No one else. Really. I can also tell you that the beta and alpha cycle of core releases was added specifically to accommodate those contributed module maintainers who were not paying attention to core development in the hopes that they would use this time to work on their updates.
The people who want/need/benefit from those contributed modules to get involved and contribute work themselves at that time. If you need a certain set of features, then you need to get involved with that modules maintainer so you can be sure that it is released in a timely manner.
Your list of required modules is certainly not everyone else's list. My list is different and I have a few contributed modules I'd like updated sooner than later myself, but this is a volunteer project. Work gets done by volunteers. If you need something _now_, then per the open source method, you can achieve your need. You can do it yourself, convince someone to do it for you, or pay someone to do it for you. Those are you options.
I have watched this process for several years now. A freeze date is determined. People work on things and contribute code, people contribute code, reviews, feedback etc. On the freeze date Dries decides and that's it.
There are people who influence things certainly, but this is not a fixed set of people. This is the people actively working on contributing code and reviews. This is not a designated team and saying that it is is not accurate and is very misleading. This is people contributing and you can see these people's work in the Drupal issue queue for core. The Drupal project is a meritocracy and that merit is earned by doing.
If you want change, then get involved. Build your reputation on the foundation of your contributions.
I do not say this as an attack, but as an attempt to educate. If at the end of all this we have a difference of opinion then that too is open source and all right.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
...
Aside from the "not gonna happen" which is the answer to this, there's also the "how could that happen" question. People keep saying D6 shouldn't have come out until contribs are ready. But what, exactly does that mean? Should development on D6 simply stop when core is ready to be released and sit there for 6+ months untouched until the magical number of modules are converted? Does that really sound like a better plan than simply releasing the ready core so people can use it if they wish? What benefit would there be to simply sitting on the code for half a year? Many people don't port their modules until they have a need to port their modules. Which means they need to be using D6. And even those who are porting them as a service to the community even though they themselves don't need the port are not likely to do so until D6 is stable. Otherwise you're chasing constantly changing code. And that brings us back to the original question. If D6 core is ready to be released, what's the point of saying ok it's done and ready but we're just going to let it sit there at RC4 for the next half a year while all the contribs catch up before we change the name to D6 final? Seriously, does that sound anything but idiotic?
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
positives..
There is a positive to all this.
In previous versions, the rush to get a new release out meant there was a lot of papering over the cracks ...'we'll do that in the next version' type thing. A good example of that is in the theming architecture. Drupal rushed from version to version, very aware that the theming system badly needed a revamp...but it kept getting kicked to touch, or worse, tweaked a little bit each time a new release came out. Ditto for some other core architectural elements.
The result of that approach means progressively bigger under-the-hood changes from version to version that adds more time to the module upgrade process. It was very noticeable in the leap from version 4.6 to 5 (anyone remember the revamp of how Drupal forms are handled?) and the leap from Drupal 5 to Drupal 6 is the first time I've noticed module contributers pressing pause and making sure everything is fixed and working well before rushing out an upgrade for the sake of it.
True, there are a lot of modules that require upgrading but what's going on at the moment is very positive imho. Module contributers are more concerned in getting existing modules free of bugs and issues before rushing on to the next version.
That's what makes community projects so powerful and for me that's a key Drupal strength. Drupal 8 could be released tomorrow, with a few new features and some nice eye candy, but, there won't be a mad rush to upgrade, because the community is ultimately in control.
It's fairly obvious that a lot of the key, larger, modules will probably skip version 6 and be upgraded for version 7. But that's okay. Because that allows more time for the planning of version 7 and tackling the under-the-hood fundamentals, rather than slipping in a few new features and some eye candy. It also allows more time to address the problems with drupal.org, the documentation and the forums.
A great example of that is the ecommerce suite of modules. Instead of rushing out an upgrade, they are revisiting the entire ecommerce framework and making sure that works properly before moving forward and upgrading. I've been playing around with the new dev version for the last week and it's looking really really good. It's also dropped in size from over 1mb to a few hundred k. In other words, the team are streamlining the modules so they are much more efficient with much less code. The result is that ecommerce version 4 (which will work with Drupal 5.x) will have huge improvements over previous versions.
"It's fairly obvious that a
"It's fairly obvious that a lot of the key, larger, modules will probably skip version 6 and be upgraded for version 7"
Speaking of someone who just had version 6.1 on multiple development sites (waiting for more module availability before flipping the switch from the current HTML versions of those sites), I certainly hope this is not the case.
I understand the benefits of a rewrite of Drupal with major versions, but breaking prior modules puts new Drupal users like me in a quandary - go through the hassle of installing v5.7, knowing that it's already been replaced, and some modules are only being further developed for 6.x onwards, or use v6.1, which may never catch up to 5.7 in the number of available modules.
It's a pity there's not some kludge/fix for 6.1 which will enable it to use older modules which aren't yet available for 6.x, because as it now stands, it's almost like there are two totally separate pieces of software, rather than an older and a current version of the same program.
Carl.
...
"I certainly hope this is not the case"
Don't worry, it's not. I haven't heard of a single major module that's going to just skip to D7.
Honestly, D5 works fine and has been working fine for the last year. Just because 6.x is out doesn't mean everyone Must Upgrade Now. If the modules you want are on D5, use that. I won't be using D6 for anything but tesing until this summer and I've heard a lot of people say the same.
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
I was thinking out loud
Hi Carl,
I was thinking out loud..so don't take what I said as 'the case' for everyone. Your need for contributed modules might be very different to mine, I was just voicing how I see the way development and releases are moving.
There are some modules, such as the jquery_update.module that allows you to get some of the Drupal 6 features in 5, but, I think that's just a once-off. In general you're right...I cannot think of any core functionality that has been ported back a version. Perhaps the exception is security patches that were discovered late.
From a project management point of view it's worth bookmarking the following wiki-page on groups.drupal.org that is an unofficial status list of Drupal 6 contributed modules. You can see pretty quickly where a lot of the contributed modules are at in terms of being upgraded
What are you talking about?
What are you talking about? What larger 'key' modules? eCommerce? They never upgrade their modules in a rapid fashion. It's an incredibly complex suite of tools that to few people work on. That they are revisiting is a good thing but is something every module maintainer has the opportunity to do with each release. Especially in light of the competition they have in Ubercart. I don't really consider eCommerce a 'key' module anyway. There are only two I view as 'key' to the community at large... Views and CCK. Both of those are being released for 6.
There is no 'rush' to get a release out, there is no 'papering over the cracks'. There is the freeze date. At which time, folks just have to live with the APIs they got and get them fixed. Draw down the critical issues in the core queue so there are none for a week and release. This schedule is on the time line of the folks contributing reviews and code. Not a rush at all. Oft postponed due to lack of either.
The original post contained serious FUD in the form of erroneous conclusions drawn from no evidence or a strong lack of familiarity with the Drupal community. This happens, no big deal, someone posts explanations on how contributed modules get updated over time for each release, nothing new. As to image handling in core, there are various people working at various speeds on various solutions. Connect with the community, learn your way around, you can find these things.
In each release new technologies, techniques and improvements are added that people contribute. Some are revolutionary (forms api, phptemplate, menu module, triggers, install profiles) and after they go in and a wider audience sees them, more people come up with improvements. Other times due to the complexities of the proposed changes, work is done of the API improvements for the changes to lay the groundwork. Many of the more complex changes evolve and are added in over two or three versions. Sometimes what seems to be a good idea at the time turns out to have some complications with broader use cases. This happens. It is not a sign of 'rushed out the door', it is a sign of 'NOT enough people helping test'.
This is not a rush from version to version. This is a no one contributed code to fix things they thought needed fixing thing. If you think something is broken, then fix it or try to fix it or try and test it and give feedback. If someone else things something is broken, then it might be, it might not be. Maybe it's not broken for most people, just something that one person wants to do.
Many module contributors press pause. Drupal 5 had JQuery added. Just added with a minimal use implementation. Why? So that it would not interfere and people would learn to leverage it. Drupal 6 saw the additional leverage of JQuery in the interface with AHAH used more extensively. This means that people now had more examples of how to leverage neat things. Each release
Lets just list the Drupal version numbers. Each of these releases is a full version release.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
you're right.
You're totally right Steven. My bad. I didn't mean to start an argument. I was just thinking out loud and don't see it as a totally terrible thing that some modules might 'skip' Drupal 6.
The ecommerce suite is a large group of modules and you make a good point about finding workarounds. there is the promising magentocommerce.com option, which may have a Drupal plugin soon and others, so it's quite possible to bridge the gap with 3rdparty solutions...in the same way many Drupal developers have tended to sway towards using 3rd party forums, rather than the out-of-the-box drupal forum (That is until the advanced_forum came along.). So, for me, it's all good.
Apologies if I said the wrong thing.
...
The way it was said. :)
One of the things that does happen is that contributed modules arise to fill a need, then some folks see a way to abstract the things and stick it in core or a more recent trend to abstract and stick into Views or CCK. Less work long term that way one hopes. The downside is less obvious how to leverage for new people. So, we will probably see some contributed modules drop off but new innovative ones rise in their place.
I really hope for some around AHAH and JQuery functionality (or at least more neat documentation/how to stuff.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
neither this situation nor I are new to drupal ...
I have been using Drupal for over two years.
My profile shows that I have had this very account for over two years.
I have multiple drupal sites.
The upgrade process each time has been horribly frustrating though.
This time, module support seems slow to appear.
What I need most are released versions of one or more image/gallery support modules.
spritefully yours
spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...
...
And image module as it is now works on a new site. Things needed are testing on the upgrade path. I have tested on my site, have you? You can find information in the module issue queue for each module of any current state, contributed patches, reported problems, unless of course, no one is reporting problems, supplying fixes or trying to help.
These things will not happen in an open source project unless people do the work. Your leap to a conclusion of abandoned in the forums really kind of came with 'not familiar with' kind of statements.
Drupal has had a wealth of conflicting methods and approaches to deal with and build image galleries. No one solution has yet risen above the rest. I myself am considering how I want to deal with images in the future. Work through the image module update or try something more fancy using JQuery or Silverlight.....
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
subscribing
Hiveminds Magazine | FireOrb | Drupal Street | Drupal offline manual
Drupal is not designed
Drupal is not designed around on maintaining backward compatibility. If you build a fairly complex site and use custom modules and patches to the core code, you are going to be using it for a long time.
Some of the modules may never be upgraded to the new version.
My advice is to learn more about the internals of the one with the modules you want and stick to it for the duration.
===============================
===============================
Yoga Redux, Yoga for Geeks
A True Story