Ok, it's rant time so bear with me. Yup, pulling my hair out today with D6 CCK bugs.
Really annoying little bugs that should and could have been caught with a modicum of basic testing.
Stuff like field labels not displaying for the check box element.
Above/Inline display choice not working all of a sudden, when it used to.
Moving fields around (above the Meta Tags ;section and Revisions section) doesn't work.
Some of us are actually trying make a living at this with demanding clients, and it's embarrassing to have to explain to a client that there's a bug that seems like it should have been caught. That really destroys confidence in Drupal after you went out of your way to promote it to the client, and hurts my credibility too.
CCK was released, it's not beta, so it's not like I was asking for trouble. Now my project schedule is shot and I have to table some promised features. The real problem though, is my confidence in Drupal isn't so great either, and I'm just wondering what the next annoying bug will be - maybe a real show stopper. Just as a hypochondriac shouldn't read medical journals, it's gut wrenching for a web developer like me to read general bug reports - leads to sleepless nights....
I'd like to see as a matter of project policy that the current version, D6 in this case, be free of major bugs (whatever that means - need some objective test) before significant work on D7 continues. I know that's probably not going to happen, since top notch programmers don't want to be bothered it seems - fixing bugs isn't cutting edge.
But really, the timeline of introducing major new upgrades like D7, especially if the transition involves deprecating major modules like CCK that already had most of the bugs worked out, is just too aggressive. As Drupal expands in size and capability, the bugs increase exponentially it seems, and the roll out of major new versions should stretch out to reflect that.
It's great that recent usability studies will influence D7 and it's too late in that respect for D6 obviously, but is there some standard for reliability? Does anybody use standard software testing protocols? I'm not a programmer, so I'm just asking. Is there some basic accountability for bad code? Is there a way to better judge the viability of a new module other than the usual perusing of the issues? Should it be acceptable to have a 19 year old programmer suddenly walk away from his module because of work load demands in college, and/or the new baby and marriage? Should there be some code of ethics that says, don't start a new module project if you cant commit at least a year to it's progress, or if you can't assure that, at least be ready to appoint another person to take it over?
Yeah, yeah, I don't have a right to complain about free software, I know, but I'm merely trying to improve Drupal's stance. Releasing buggy code is bad for Drupal's image and professionals are just going to walk away if there isn't more of a focus on stability and reliability particularly now that Drupal is in the limelight and is getting used in a lot of places. I love those code sprints, but haven't heard much about usability or bug sprints, but that's what's needed the most. Love the new features, but pleeeeze make the old ones work first!
Just my 2 cents.
....Jeff
Comments
Maybe it is better to do the
Maybe it is better to do the opposite. How about skipping D6 and focusing on D7 so that it arrives as soon as possible and with high relalibility, including CCK? It looks like many module developers chose this way, too. It has been a year since D6 arrived, but many important modules do not have a stable D6 version. Many developers do not even start D6 development. D7 is coming closer, but even Drupal.org website is using D5.
...
The only issue you were specific about is with CCK, which is "not" Drupal (yet). If you've found a bug, have you checked the Issue queue about it, and if it's new have you posted a bug report? What "major bugs" in Drupal core are you talking about? The reasons for CCK (and Views) being reworked for Drupal 6 and beyond are good ones, and you can find various discussions about it. Reworking them impacted many module's ability to port to D6 as quickly as would have been ideal, but that's not the "usual" (e.g. Earl said he remade Views in such a way that starting over won't ever be necessary again). People keep saying "modules" aren't released for Drupal 6, but I'd really like to know which modules they are referring to. I run seven Drupal websites, half of which are Drupal 6 (and the rest will be the moment I have time to upgrade them)... it is rock solid, and no "standard feature" modules are lacking at this point. The theming system alone is reason enough for Drupal 6 (not to mention Views 2 compatibility, drag and drop everything, enhanced performance options, etc). If a contributed module is esoteric or only useful to a small number of sites, it is not surprising if it doesn't get upgraded (quickly or ever, until someone who needs it takes on the responsibility). Contributed modules do entail a certain amount of risk in regard to upgrades, so you should be "picky" with them and only use those you really need - and be "aware" of the possibility of any one of them not being upgraded in the future. Or use as many as you want, planning ahead to either upgrade them yourself when necessary, or pay for it to be done.
No, there should not be a rule or policy about people "having to" support a module they contribute for any given period (definitely some screening to keep out and discourage duplicate modules would be nice though). It is a kindness that they gave the code to us in the first place - if the module is worth it, the community can help maintain it. And yes, it would be nice if some module developers would actively give away their module to another maintainer (at least post about it being available) if they intend to abandon it for any reason (versus just disappearing). However any module can be taken over by anyone who volunteers, once a process of confirming the absence of the maintainer is followed.
You also mentioned you have paying clients (e.g. you make money from Drupal). Though you say you aren't a programmer and can't make the fixes yourself, in FOSS you sometimes have to scratch your own itch one way or another, or else be content to wait for others to do it (e.g in your case perhaps round up some programmer friends in the community to work together to tackle that specific issue that's bothering you, do some group fund-raising to pay someone to fix it, or even consider investing a little revenue made through Drupal into fixing the bugs you need fixed for your clients).
You mention Drupal development needing to slow down and get 7 right... but that is exactly what they are doing. Drupal 4.7.0 came out May of 2006. Drupal 5.0 came out came out January 15, 2007. Drupal 6.0 came out February 13, 2008 (each has been about 1 year or less apart, give or take). Drupal 7 is not likely to be released until 2010 (e.g. up to, or even more than 2 years from Drupal 6). Also as Dries said, Mark Boulton is being hired to work on Drupal 7 usability.
The best of luck.
-- David
davidnewkerk.com | absolutecross.com
View my Drupal lessons & guides
Yup
Yes, yes, and... yes. I agree with everything you say.
Like I cautioned, I was ranting - an emotional outburst following frustration.
It's good to stimulate such discussions once in a while though.
That said, there's one module that's taking it's sweet time to convert to D6 that I really could use.
Hierarchical Select with compatibility for CCK, and Content Taxonomy - has functionality that a whole lot of web sites use - dependent drop down lists, like selecting and capturing country ->state ->city with very large taxonomies. There are other ways to accomplish this but they're all D5 and dead in the water as far as D6 is concerned.
I'm in the process of submitting bug reports, but the very frustrating issue is the repeatability of bugs - they don't always occur when trying to reproduce them, a fact of life when you have a lot of installed contrib modules that can interact in unpredictable ways.
Not sure what you mean about CCK not being Drupal yet. It was released in November. Do you mean the part that's in core is old?
www.drupalmodules.com has a rating system and comments on modules that is invaluable. Drupal's site should do that and more, by categorizing modules in such a way so people can compare modules with similar capability. As the number of modules grows, it becomes damn near impossible to find what you really need. The module situation needs to be distilled down. Create a collection of modules similar to what Acquia has done, that are known to be stable and reliable. And as for paying people to fix and/or upgrade their modules, why not institute a donation bucket on the project's page, with a link to a central page for all projects where programmers might bid on jobs.
Anyway, sorry for the rant, and I'm glad to see that D7 is taking longer than usual. BTW, the developer of Hierarchical Select has taken some heat for spending time on new releases for D5 and the expense of D6. His argument of course is that there are still plenty of active D5 sites out there that would benefit from this module. True enough, but frustrating nonetheless. It's also heartening to hear that D6 is groundbreaking enough that we won't likely have another situation where all modules are rendered useless, for quite some time. Not sure I could have pulled off what I'm trying to do with this complicated site I'm building, without D6's new capabilities though, and that's the frustrating part. It's like buying a hot new car with a great engine only to find out it doesn't work in reverse.
....Jeff
Re:
By that I mean CCK is still currently a 3rd party module, and is not part of Drupal core (therefore if you're referring to "bugs in CCK" you are referring to CCK module, and not Drupal core... though CCK is a very widely used and important module, it's still an optional contributed module like any other. It of course receives more attention and work than most modules though). CCK has been "partly" in Drupal core since Drupal 5. The "core part" of CCK that facilitated the creation of new content types without creating a new node module by hand to handle each new type is what was reworked out of CCK and put into Drupal 5 core, while all the remaining functionality has remained throughout both Drupal 5 and 6 in a contributed CCK module (e.g. adding any custom fields, plug-ins, etc). The goal is to next add CCK's field-making/handling abilities to D7 core... after which I wouldn't be surprised if a separate CCK module still stays in existence with yet more functionality.
Have a read here also: http://buytaert.net/predictions-2009
(since this post, the news about Mark Boulton was later posted, and since he isn't able to start immediately I wouldn't doubt that changes the 4th quarter 2009 D7 prediction into Q1 of 2010).
I don't know precisely what/how, but the new drupal.org redesign includes many of your requests regarding module ratings/etc. I believe actually the owner of drupalmodules.com was one who submitted ideas and UI examples for drupal.org based on his own work.
I started with Drupal right about when 4.7 came out... it was hard then. You had to manually install it with SQL queries (and each module too if I recall). Before then... I don't even want to know ;) Early on with Imagefield/Imagecache you had to manually code every little thing directly in your theme for it (now it just does it all for you with a few simple point and click options... and hey, want an instant Lightbox too? Just click here). Many more examples :D We have it good now, and it's only getting better.
-- David
davidnewkerk.com | absolutecross.com
View my Drupal lessons & guides
Kane's book explains D7 road map
I should have read chapter 13 in Victor Kane's great new book first: "Leveraging Drupal"
There he quoted Dries:
"While we have made incredible progress with the test infrastructure as well as implemented dozens of usability improvements, we're still light on feature improvements (such as fields in core). Combined with the late arrival of CCK and Views, and the many Drupal 6 books that are currently being written, it sounds best to postpone the code freeze [for Drupal 7] a little longer. Given the current state of things, the proposed July 15th deadline seems a bit too aggressive to my liking."
Kane talks at length about the road map for D7 and the efforts with "usability sprints" and independent usability studies. He cites the architectural improvements of D7 and lots of other related stuff.
Most of what I was ranting about is covered in this chapter.
Good book to get.
PS. I sent you an email through your blog about a Steinway piano I have for sale in San Diego.
....Jeff
People keep saying "modules"
Michelle has created a module list for a social networking site in Drupal 6. Half of the modules are still in development or not even released for D6. You can see it at http://socnet.shellmultimedia.com/upgrade-status
...
Some modules in Drupal are in almost perpetual development (alpha, beta, rc... even a few that rarely if ever get past -dev), and even in such a state are fine to use in most cases. For instance, do you think the fact that Imagefield is still "alpha" has stopped Sony from using it on their new Drupal 6 sites for major bands/artists? Would it be "nice" and feel better if they had final releases? Sure... but right now it's not the case, though they do work with few or even no bugs that are of consequence to average users.
With possibly a very few exceptions, every module highlighted in yellow on the list is stable enough for production use.
Almost all of the modules highlighted in red in that list technically should not say "not ported yet" but rather "deprecated" as they will never be upgraded (they have been replaced by new solutions in Drupal 6)... the list is automatically generated by Upgrade Status module though, not written by hand by Michelle, so it just shows the labels it was made to show (it doesn't know those modules are deprecated). To name a few deprecated modules on the list: Bio (replaced by Content profile), Buddylist (many replacement options), Dodge (Facebook-style statuses), Usernode (no longer has purpose in light of Views 2's ability to connect with the user table), Views Bookmark (replaced by Flag module). Most or all of these have an upgrade path to their D6 replacements.
A few on the list I see that would be "nice" to have but aren't ready, are mostly those tied in some way to Panels module (e.g. Panels itself, Organic Groups Collections/Blueprints, Tabs panel style). Panels is cool, but certainly not "must have" for everyone: here's a guide I wrote the other day on how you could create a panels-like layout using a CCK type and regions/blocks. MySite module is cool also, though also not "must-have" for most people. I don't use Panels much, but people have been saying that Panels 2 in D6 is quite stable for most uses. The Panels-dependent modules though are a bit up in the air, due to Panels switching gears towards Panels 3 (I guess they decided it was best to rework some important parts, which they didn't want to muddle up version 2 for people while they're working on that).
With a few exceptions after those, every remaining module on that list is ready (and IS in use) on production sites right now. Several on the list are not in any way "critical" to a good social network site (e.g. so what if "avatar blocks" is not ported... should I hold up my entire social network site over that? Not to mention you can likely reproduce most or all of its functionality with Views 2 now... in any case, a quick peak at the issue queue shows there's a working patch that for some reason no one has committed as a release yet). A few others I see "would" be done if people would just test the patches to port them to D6 (so if it's a module you need... you should be helping).
Anyhow... back to work, on my D6-based social network site hehehe ;)
For instance, do you think
I do not care whatever Sony did. "Sony did it" does not mean it it is correct. I have been visiting Sony's websites for a very long time and I have seen tons of errors.
Yes, but they do not.
Final, alpha, beta, dev. releases have different meanings in software development. http://en.wikipedia.org/wiki/Software_release_life_cycle explains them very well. If alpha version means mostly "ready for live production sites" in drupal terminology, I think this must be expressed more clearly on this site. I did not see such a statement, but maybe it is written somewhere. Or maybe these terms do not make much sense in drupal. Maybe, Sony is aware of this in drupal so dares to use alpha modules in their production sites.
Also, many developers do not even support these alpha, beta, under development modules. Copied this from Advanced Profile Kit's description:
Feel free to use D5 or
Feel free to use D5 or another CMS if you prefer. I am done with this discussion.
Definitions
Yeah, alpha/beta/rc can vary quite a bit depending on the maintainer. I used the alpha tag on my modules to indicate tested dev snapshots as I went along. But they weren't really alpha because the module wasn't finished. Other maintainers just keep their modules purely in dev until they're ready to release. I always strive to keep my users aware of the status and will tell them if I think something is safe to use on production. In the case of APK, it's not so much that it isn't safe to use as it's complicated, not documented yet, and will be changing when panels 3 is ready. As such, I don't want inexperienced people thinking it's ok to use and then getting into trouble.
Michelle
Panels tabs
FWIW, panels tabs works fine in D6. You just need to update the .info file. :)
MySite is one that's a loss in D6. It really was a nice module that didn't get the attention it deserved and now the maintainer has no time for it. Pity because there isn't a good replacement for it yet.
Panels is a big blocker for me. My site is going to be heavily panels based and I wish P3 was further along. But I know Earl can only do so much so I try to be patient.
Michelle
Not a good test anymore
I forgot I even made that page. LOL! I wouldn't go by that anymore. It was more useful last fall when I made it. As Keyz pointed out, though, a lot of those modules are either useful already or have been replaced by others. Advanced Forum is listed as simply "in development" and yet it's basically done and just waiting on a final bit of testing before release. APK, on the other hand, still needs a lot of work in D6. So you really need to look module by module to tell what's ready and what's not.
Michelle
Much needed discussion
Drupal is a good start, but is plagued with some really serious issues that its user base seems to put up with as character flaws. There are some real user interface problems in the standard implementation and, in general, most modules are not that usable. Drupal's UI framework is to blame here; someone trying to create a module with a really good UI will have to bypass all of Drupal's UI API.
Documentation is in general lacking. The core documentation is not really enough and most modules have little, if any, docs.
And then there are the bugs... while the Drupal core has been bug-free in my experience, it is typical for modules I download to have a couple of issues.
The three of these issues create a large burden in deploying Drupal to end-user clients. These are people who need to be abstracted from Drupal's internal workings, and Drupal does a fairly poor job of accomplishing this. So, I have to pick up the slack in every project because there are no generalized solutions.
Also want to point out...
I also want to point out the problem with this mentality of "it's not core, so it's not our problem." CCK and Views are basically required for any useful Drupal installation, so releases of Drupal are inevitably intertwined with releases of CCK and Views.
.
pkrecker, your profile and track page show almost zero involvement in this community, and no contribution of any kind. Perhaps that is part of the issue. Drupal is not a piece of magic software that you can throw an infinite amount of complex modular functionality at and expect it to "just work" without having to understand it, or taking into account the immense amount of freely offered time and work people offer towards the "goal" of taming that complexity. A few years ago, the same functionality would have cost you tens or even hundreds of thousands of dollars just to license a proprietary CMS. And even if you did, it probably still wouldn't be anywhere near perfect (many companies who licensed such software in the past are now turning to Drupal, in fact). Now however, you have this free, excellent, and yes imperfect software to use in any way you please. You said you have clients and therefore make money through use of Drupal. Drupal gives a lot... give back. As you said, Drupal core itself usually does "just work" relatively bug-free, but to expect the same from every single contributed module (of which there are thousands) is not realistic. Regarding CCK and Views - aside from an occasional issue here and there, they are very solid. Small modules offered freely by single individuals though are often as good as that one developer can make them in his/her free time - the rest is up to the community to help. If someone hasn't even submitted a bug/issue they've found, much less offered any code, thoughts, ideas, or whatever skills they have to offer on the issue... then they do not have the right to complain.
Core documentation is quite good - in which area do you find it lacking? Please be specific. Documentation for contributed modules can range from terrific to non-existent... sometimes extensive docs are important, other times a module is self-explanatory. Again, if you are specific about where you have found something lacking, others are more likely to help. I (and many others have done the same) on many occasions have responded to a specific request for improved documentation of a "specific" module, by writing or improving documentation for it (even installing and teaching myself how to use a module I otherwise have no use for, in order to document it). If you just say something like "there's no good documentation for modules"... that's not actionable or specific. No one can help you with that. Be specific about which modules, and if possible the exact aspect of them that you are stuck on, and the likelihood of improvements is much better.
So far as UI issues... they are definitely an issue, but are not insurmountable. Views 2's UI for instance has set a strong precedent in gathering a huge amount of complex functionality into a sane UI (whether it's right for Drupal overall is more for the usability groups to test and decide). CCK's UI in Drupal 6 has improved greatly as well. These were testing grounds where new UI ideas have been put to the test, and now a lot of the improvements are heading back into core in the next version. Things will likely be revamped even more extremely due to the significant push for usability improvement in D7: usability testing groups, hiring Mark Boulton, Acquia putting its paid developers on the task, etc. As you have opinions about the UI flaws, it is also part of your responsibility as a user of this open source software to help come up with solutions to those (or, if you are content on the sidelines not helping, you cannot complain about the issues). Instead of as you said "picking up the slack in every project", consider investing some time in assisting in fixing what you believe are the actual issues, by at the very least clearly pointing them out in the appropriate setting (e.g. usability testing group, bug report or feature request against Drupal 7 core, etc) and if you have solutions to propose for those areas, all the better.