After working with Drupal for almost 3 years, I really need to vent somewhere how Drupal sucks. For a backgrounder, I'm more of a sysadmin type rather than a developer or a designer.
Just to be upfront, I clearly chose Drupal for a reason and I believe that Drupal is still the right choice, I love its strengths and it's clearly a leader in many respects. But at the same time, what I want to address are things that Drupal really sucks at doing and it really shouldn't have to be. And I'm not talking about UX at all.
Image support: Time and again I get complaints about how we can't do stuff with images like other sites (e.g. WordPress) do. Drupal 6 does not have image handling in core and I ended up spending a long time figuring out how to do images in a futureproof way. Drupal 7 has image handling in core and that's wonderful, but still, image handling has been taken such a back seat for so long that it really make Drupal lack behind the competition. I tested dozen of image gallery modules and most of them are like a throw back to 2005: no AJAX, no lightbox, no fancy slideshow. If I need anchor image for my node type, I have to define everything from scratch. Not that it's difficult, it's the fact that there's no uniform way to do it and such feature is pretty much expected of any CMS.
Too many modules: This is supposed to be Drupal's strength and it still is for the most part. But it's coming to a point where:
- There are so many modules that I have to test dozens of very similar ones to figure out what's best for my project and still come up short.
- The Drupal philosophy creates a scenario where it's very common that it requires several modules together to do one simple thing, which adds even more complexity. Pretty soon I find myself using 20, 30 or even 50 modules
- It's very difficult to know whether a module will be maintained. With so many modules installed, the risk of relying on a module that might be left unmaintained become increasingly higher, and so is the risk of a minor update (on core or modules) that will break something.
- It's understandable that Drupal wants to provide a framework and doesn't try to make any decision for you, but it's becoming so extreme that Drupal core provides so little of what's expect of a modern CMS and it that so much testing and configuration just to do those things that it's getting very frustrating.
- Many important, widely used modules (Views, Panels, etc.) aren't part of core, when other modules will make it more of a priority to work with them if they were in core. E.g. to this day I still have i18n issues with Views.
- If these modules can't be rolled into core, it really helps if there's a "preferred" status for those modules. E.g. Every user expects a WYSIWYG editor, Drupal has many WYSIWYG modules yet all of them has shortcomings. I'm all for choices, but it's all too common that there are too many modules to do similar things with not one of them that stands out.
- I don't think I'm unique in that I'd prefer a widely supported standout module even if it means I have to live with some limitations.
Over-Flexibility: Some modules (e.g. Views and Panels) literally have a hundred config options for one page. It's simply nuts. I use Display Suite to do node layout and that module adds 6-7 layout pages for each content type. The LightBox2 module adds dozens of formatters to the edit form even if you only have maybe 3-4 imagecache presets.
I'm all for flexibility, it's why I choose Drupal in the first place. But not every little thing needs to be configurable and some things are actually simpler to specify in a config file rather than the web UI. At some point the extreme flexibility becomes pure madness and completely unmanageable.
Obviously Rails shouldn't be compared to Drupal directly, but after using Rails for some projects I've come to appreciate Rails especially for its "convention over configuration" principle. Some people might disagree, but I think there's a huge value in providing sensible defaults and defining a uniform way of doing things that's based on best practices with no required configuration. It not only saves a lot of time, it leverages the community's knowledge and expriences, and developers have some standard practices to focus on improving.
Visual appeal: Most Drupal module developers are not as visually-oriented as WordPress developers, so most Drupal image/media/visual modules look relatively basic out-of-the-box. Sure the look is customizable using CSS, but it's one another unnecessary complexity added to a string of others. And no matter how often I stress the different strengths of Drupal and WordPress to my users, what Drupal is good at is always behind the scene and no average user would notice, while most of WordPress strength is in visual presentation and what the average user cares the most.
All these issues add up to the following very common scenario for me. Let's use photo gallery/slideshow for instance:
- first I have to define the implementation: image nodes vs imagefield vs file upload to a specific directory? gallery type or no gallery type? Views or no Views? (this is where a well defined best practice is badly needed)
- Then I have to test dozen of modules to see which one fits my needs. Turns out, most of them are either so behind the curve visually that I can't use them, or they plain break and doesn't work (e.g. most Views Slideshow plugins).
- After much testing it seems a Views-driven display with something like jCarousel works best, using Views means introducing a lot of config options to set just to get it to show anything at all, not to mention that I'll still have to theme the thing in CSS
- After all the trouble I had basically decided that I'd just integrate a javascript slideshow library myself
- Even the roll-my-own route has problems: Many newer javascript slideshows use jQuery 1.4+ but Drupal 6 uses 1.2.x (or 1.3.x with jquery_udpate)
At this point I'm basically throwing my hands up screaming why can't a slideshow module just work out-of-the-box? Why Drupal can't just bundle a photo gallery/slideshow? Or at least have one or 2 endorsed gallery/slideshow modules that meet the most basic expectations today?
Now rinse-and-repeat for content rotor/carousel. Rinse-and-repeat again for WYSIWYG editor.
I know most of you hate people comparing Drupal with Rails and WordPress. I don't believe they are comparable in any way, but both WordPress and Rails are widely used and create certain expectation of what a CMS or website can do and should do and how easy it should be. Time and again I ask myself why something so easy to do in WordPress or Rails is so needlessly complex and tedious in Drupal? Or that I get so frustrated with Drupal with all its configuration headaches that I ask myself why I didn't roll my own CMS using Rails or Django in the first place.
I still believe that Drupal is the right CMS for my projects: it's still one of the better CMSes for multilingual sites and one of the most flexible general CMSes out there. I love Drush. I love taxonomy. I love CCK. I think Views and Panels are very powerful indeed and there's nothing else out there like them.
But it comes to a point that after trying countless modules and all the configuration madness just to get something relatively simple to work at all becomes such a burden that it becomes no easier than rolling your own CMS in Rails or Django, while my users keep bugging me about how easy and pretty-pretty it is on WordPress.
And I haven't even gotten into the development-deployment integration issue.
Maybe I simply prefer Rails and my users just prefer WordPress and we are all expecting Drupal to be more like WordPress or Rails.
Anyways, I'm just babbling at this point. I should shut up.
Comments
I completely and utterly
I completely and utterly agree.... with your last sentence.
Just kidding. I do agree with the points you make, though I wouldn't say "Drupal sucks", as the good far outweighs the bad. (Though admittedly I am new to Drupal).
I think drupal is too open
I think drupal is too open source.. yeah open source is good and it works well with the linux boys because the get paid bucket loads to do what they do. A lot of the drupal startups struggle just to get by. Wordpress has a economic eco system which feeds the development and pushs the guys to created stable better looking modules.
This is not the case with drupal , there is no system in place for a free-market to drive the technology and i think this is a problem.
and for the last time WHERE THE F&*K ARE THE DONATE BUTTONS ON DRUPAL.ORG MODULE PAGES!!! this should be default ! even if some developer does set one up it should then redirect to the drupal association.
Hi Bukem, thanks for the
Hi Bukem, thanks for the reply.
What do you mean by too open source? Do you mean that there's not enough paid incentives? Development too decentralized?
Its just to free .. its uber
Its just to free .. its uber hippy. For example Merlinofchaos should not have to work for a company , he should be able to be full time drupal contributor and live very comfortably .. the more he works on views and panels the better they get, and this community should be his soul funder. But that is not the case. How do i even donate to views .. I have never made a site without it and it has made me a bit of cash , yet i dont even know how i can say thanks to this oke for what he has done besides a friendly email.
There is just no finacial system in place to drive this technology and i think that is a problem. It dont have to be a greedy drive but one where if you are good people pay and so you get better and those that want to do drupal full time only need to get really good at what they do , instead of struggling just to get by, and hopefully become a b!tch for one of the big boy drupal companies.
They should seriously have a good look at wordpress's model, not only the slick UX.
Are you just advocating for
Are you just advocating for donation or a comprehensive business model?
Donation button for core and contrib modules seems like a good idea. But I hope I'm not too dismissive in saying that most people don't donate at all, just ask any other open source projects that rely on donation. It'll be just a gesture. If I'm not mistaken WP themes/plugins are either free or paid, no obvious donation option for either core or plugins.
I should point out that the economics of WP and Drupal are quite different. Not sure how the typical WP dev makes a living, but seems like most big Drupal projects are developed by big Drupal consultants, so it seems there's plenty of financial incentives already for those situations, substantially better incentives than donations or paid modules. Drupal world has a much much bigger consultancy market to fund it, not sure how WP compares in terms of that. Smaller Drupal modules will probably benefit from project-specific donations more though.
Not sure what Merlinofchaos' specific situation is, but maybe you should run it by him first and ask him whether he thinks donation help him much or if there's anything else that might help him better. But I think funding him full-time via donations seems rather optimistic.
I'm just trying to have a clear idea of your motivations. Seems like to want to contribute and you think what you can give is donation rather than code, and I'm sure there are tons of people like you. Kinda got me thinking I should donate as well.
Well there could be a
Well there could be a comprehensive business model, but i find there are a lot of very useful modules that just become left to "die" either because the developer is too busy on other things or has left the drupal community. I have tried to contact a few to get options on improving the module with some sort of payment but they never really work out .. not sure why.
I personally think donations would work if it was clearer would worl, I think donations are an interesting driving model for any business model, Like natural selection it selects the best based on the communities need. Take a look at piecemaker.. awesome module , really makes the slider into something more then just the normal standard thing, but its only in flash, Now I know that if there was maybe a way to have a posting for this to become jquery ( i have seen the paid for jquery, but its outside of drupal ) and if there where enough users wanting this then ...maybe the developers could set a price .. all those wanting the feature could chip in .. wait a minute .. this sounds like kickstarter. So yeah .. kickstarter build into drupal.org would awesome.
I also think there should be a module store. I would be more then willing to pay for a stable module for a news letter system or other. I reckon drupal.org should have it so that the module developers can release a normal version and then have a paid for version with a bit more and maybe even have the module skinned already so the user can pop it into the site with is nicely layed out already with a nice .css template to work off of. I think this would help .
Also maybe some sort of voting system. There are so many modules that it is hard to search for modules. if the searches could be based on votes ( I know if already has "in use" but this can be deceiving - cause I could find a really good module but have no use for it in all my current sites ) to filter it out a bit .. and if it gets a lot of negative votes ( which will really help , I have install a few modules that just break the site completely ) then it has to go back to the developer for a major review ... or something like that.
I dont know .. I think there should be some sort of quality control and I know the coding standards help with this but maybe if the quality control was community based might help
Is there a limitation to
Is there a limitation to create a paid Drupal module? I don't think there should be a problem to create and promote premium modules. You can create free ones and use them to promote the free similar to how Wordpress devs do.
_
There's no limitation regarding charging-- it just doesn't make much business sense. drupal modules must be GPL so anyone you sell it to is free to give it away for free. It makes more sense to charge for development services than code distribution.
Wordpress plugins are also
Wordpress plugins are also GPL but this doesn't stop people from making business with them. The code itself isn't business - the business is in the combination of code, branding, support, and marketing. Besides that the original developer usually can provide the best support for their plugin, updates, etc.
Of course introducing other license than GPL would be nice.
Chipin
There's a Chipin here: http://drupal.org/project/views . Now you know how to donate. :)
You have some points
There are 3 or 4 critical points in the actual Drupal situation from my point of view:
- Memory usage of Drupal 7:
The actual requirements are high and sometimes you can't afford them. 128M once were a high standard configuration, Now i see that sometimes they are not enough. Higher requirements are often not affordable for clients and thus for developers.
So i studied Drupal7 API tried to upgrade my knowledge and i found myself stuck on memory. I decided to go back to Drupal 6 for the aforementioned project and then i remembered why i wanted to upgrade so bad:
- Jquery 1.3.2 is not an option
This is the other huge issue. Drupal 6 is almost dying on the inability to upgrade this library. Really, is there some way to improve this? Also Drupal 7 is packed with an older version of the same library and with the same problem of update. I think that opposed to his huge flexibility this is a big hindrance
- Over-flexibility:
Too many things to do. In too many different ways. I like it.
Really, but things to do became a lot more and the ways to do them grew consequentially. Don't know what's the solution though.
That said i love Drupal, and i'd like to know if the things i pointed out are true or are the results of my ignorance about some new/old Drupal features.
Memory usage of Drupal
Memory usage of Drupal 7
Can't help you there. Don't think the core dev can improve it substantially either unless there's a basic flaw in the memory handling. as anyone can tell you optimization takes time away from coding features and stuff. That said, d& might be at a stage where they can spend more time on optimization now.
You might want to look into your own optimization though, or whether a certain module is being a memory hog.
Jquery 1.3.2 is not an option
You mean you can't use Jquery 1.3.2 on D7? I did manage to mix JQuery 1.3.2 and JQuery 1.4.x on D6. You can probably add Jquery 1.3.2 to D7 and make them co-exist. There are some help on how to mix 2 versions (or more) of Jquery on the same page. Try asking Google.
Over-flexibility
I love it too, and most of the time it's great. But occasionally there can be a dozen modules that does the same thing but none of them meet even modern expectations. In those cases some direction and focus of resources are really needed I think.
Better explanation
Jquery 1.3.2 is not an option
Blame on my poor explanation.
Drupal 6 + jQuery update -> jquery 1.3.2
It's a bit problematic that the backend relies so much on an old version of jQuery and that there is no way to update without breaking something, mostly in backend
Drupal 7 + jQuery update-> jQuery 1.5 and that's ok right now.
But if updating is difficult as in Drupal 6 in a year or so Drupal won't be able to perform as expected from a front-end point of view.
So my 2 cents suggestion would be to think about a version of Drupal that can work without jquery. Maybe a version that works better with jquery and is some less performant without, but something that allows the real-time upgrade of the library.
Thank you for the advice about mixing and let cohesist 2 jQuery versions. I managed to mix 2 different versions but it seems i have still problems (mostly ie related) on the module i wanted to build.
For memory issues use VPS
VPS is the way to go with Drupal if you are not using shared hosting.
You can get a 1Gb VPS for $70 - $100 a year hunt around.
Now where is that affiliate link of mine?
I agree
I agree with about everything goofrider said and I think he did a good job at identifying the central issues. I can relate to what he says about having to try out dozens of different modules that do the same thing to see which one might work. And I like his idea that even if certain modules didn't make it into core they could still be identified as "preferred" and identified as the direction Drupal is going to help us poor users from having to pick through all the inferior alternatives.
I've been a software developer for 30+ years (C, Ada, X Windows/Motif, C#, you name it) and I left all that to focus on Drupal because the one thing I still enjoy and am interested in after many years in IT is the internet. I picked Drupal because it seemed like the best option and there are days I really like it, for example the Rules module is amazing - it's like visual programming in the truest sense, but there are many days, too many days where it leaves me cursing and frustrated and googling things like "drupal sucks"!
I think someone should make a site that lists the best modules/methodologies for solving all the common tasks that web site developers face. Where they could identify the modules that represent the future direction of Drupal. For a particular task they could also list other modules that offer a solution to the problem even if they aren't the preferred solution and the reasons one might choose them. I realize there are sites that offer some of this already but I'm not sure how much. I also realize that getting agreement on the best modules for a task is like getting agreement on religion. I know, I know, I could make that site but I'm still too busy trying to figure out how Drupal works!
I like having options. I also
I like having options. I also think it's good that people are wanting to do the same thing differently. Sometimes I see modules that no longer get maintained because there is another, similar one that is accepted as the better one. I think this can only a be a good thing.
too many options not always a good thing IMO
With other technologies I've worked with, e.g. .Net, there are usually a set of tools provided to solve the common problems the technology is designed to deal with. So your learning curve is going through the set of tools it provides and figuring out how to use them and we all know that with almost all technologies the learning curve is fairly steep. With Drupal you are faced with the added complication of having multiple choices of tools at each problem you are trying to solve so now the learning curve becomes exponential. You have to figure out which of these five different tools is the one to go with and will it work with the other contributed modules and theme I've chosen and will it be supported in the future. And maybe for this project and set of contributed modules and theme the solution works well but then your next project requires a different theme or contributed module which doesn't play nice with the tool you chose before.
I'm hoping I'll get to the place where I'm familiar enough with the popular and well maintained contributed modules to be able to build sites quickly and efficiently but my concern is that with all these variables, e.g. different contributed modules taking different approaches and changing their approaches with different releases that it will always be like shifting sands and that I'll have to keep fighting the same battles over and over again...
But I'm glad you enjoy the options!
I have a suggestion
Goofrider, I vehemently agree with everything you've said; I've been using Drupal for 3 years now, and have experienced all of the same frustrations. The only thing I don't really get is your antipathy towards the opensource movement, but that's immaterial to what I would like to suggest (and perhaps someone has already suggested it, I don't know; but I feel very strongly that we should get in touch and come up with a Best Practices Drupal... I've waited (and waded) for hours and hours through the same stuff all of us have, so wh not create a basic Drush-esque - in terms of knowledge and application, not module integration and automation - project page containing the best-current configurations for these (INFURIATINGLY recurring yet-so-simple-as-to-send-me-back-to-hand-coding-php....) problems?
I know what you're thinking: "Why the hell would I want to write tutorials when therre are already... blah blah blah"... And that's just the point: For years I've been saving complex configuration setups (which - and here's a point that I think you and everyone kind of missed: DON'T MAKE SENSE EVEN WHEN YOU KNOW WHAT YOU'RE DOING... lol... in fact, knowing what you're doing in D7 is almost as much a handicap as NOT knowing it in the first place)... Anyway... What I am proposing isn't so radical as a fork in Drupal, yet not so top-down as "prefferred" modules (which would be awesome)... Nor is it a "tutorial" (because God knows all of them are instantly out of date, all screencast, and seem to be made by speedtalkers who love to explain 10 minutes of the utlimate basics before getting to the point - bless their souls, btw; otherwise I would never have been able to figure out views/wysiwyg integration back in drupal 6)... What I want to do is establish a BEST PRACTICES paradigm that outlines the best modules and methods in drupal to achieve these otherwise simple tasks that seem to always become so frigging complex.
Let me know if you're in. Otherwise, I'll just do it myself (and have been doing it myself for years now: there's no reason that creating simple galleries and slideshows using views and taxonomies should be so complicated for the end user after so many years... BUT, course, I understand Drupals BRILLIANCE!!!... still... sooooooo many menus... sooooooooo many modules.... soooooo many problems... ... u;ltimatel;y, you go away from drupal to do some real coding for another project and all of sudden it's like a chemistry exam)... Anyway. Cheers, and even if you guys think that this lurker is a lunatic, I'd like to thank you for raising some excrutiatingly valid points (except for the anti opensource stuff, and maybe the theme's stuff - cause there's not much that can be done to simplify that... but blah...)
OK. That's my comment, and I'm... open for suggestions...
Drupal / image handling / photo galleries
Ouch. I just spent about 9 months learning Drupal (7) and building a decent looking site for a number of contributors. It was a long and sometimes tedious process, but I am happy with the results. I agree that the configuration options and number of similar modules are often staggering.
Now I have gotten to the last part of my site - my own section. This will be primarily image galleries and I feel like I have been spinning my wheels for four or five weeks. I don't want to create dozens and dozens of nodes for each gallery, and I want to have comprehensive captions that I can write out in paragraphs, not just an alt or title tag. There are very few options for this. I did find some options in this for Views, but then it's figuring out which ones are still, or will be supported, and which tutorial deals with the current version that's available.
I found one module that I like a lot. It produces adaptive slideshows, but has no real caption fields - except for one available as a patch. I've spent at least six hours over several weeks trying to apply a supplied patch to that module and finally have to give up or I will never have anything to show. I just cannot get it to work, even though I have applied a patch to a module in the past.
But I'm not a developer and not being overly critical (I hope), but I just wish some of these basic things were in place. I decided to use Drupal because I recognized what a brilliant system it is, but at the moment, I just feel overwhelmed trying to find what I hoped would be a basic and straightforward option that won't look like something created ten or fifteen years ago. It doesn't even need to be that sophisticated - I'm happy to style it myself, but I just need some basic things, like: separate captions for each image, multiple images in one place (node), navigation and responsiveness.
And, I did check out other options before getting here, namely: Wordpress, Joomla and Concrete 5. With the possible exception of Concrete 5, I didn't see anything much better there, though I only spent a few weeks on each.
Anyway, as I head into another weekend where I'm trying to accomplish this, thanks for letting me vent. And also, thanks to the many talented Drupal developers and designers who got me this far with: Core, Omega, Views, Adaptive Images, Context and Display Suite among others and the many bloggers who helped me zero in on them.
The Developer community are too focused on scratching itches.
Drupal doesn't suck, just too many Drupal developers scratching their itches.
To be fair it set out to be a "community plumbing" tool, not a blogging tool or a CMS, and now it is being labelled a CMF, content management framework. One also has to wonder how much its direction and priorities are driven by the commercial interests of its founders and leaders.
It has simply lost is way as an end user tool, and not enough attention is devoted to install profiles for end users, admins and developers. Module developers do not want to get burned out by having to rewrite their modules for the next version when they have hardly finished or optimized the current one. End users can't upgrade because the modules they need are not available, and may even been abandoned, then at EOL there are no more security upgrades.
Most of its issues can be fixed by "standard" or "official" install profiles for the most common use cases. There is not enough information on profiles on the Drupal.org itself. I guess Acquia Commons and Drupal Gardens fit the needs of end users, the Open XXXX profiles, for NGOs, companies etc.
The default install profile(s) are not good enough. Who knows that as an admin you've got to have stuff like Administation Menu, Coffee, Sweaver etc, well configured WYSIWYG, Backup and Migrate etc, etc. Most of this stuff should be present in the main Drupal 6/7 installations, rather than having a new user of any computer skill level having to learn about them the hard way.
Drupal will be hard to recommend if the use case install profiles are not good enough or tested enough, and more importantly the leaders don't realize the need for LTS releases. Consolidation and evolution of existing features is more important for end users especially individuals and SMEs. The simple fact that is the Drupal developer community have proven to big companies and organizations that they can deliver, and that want they don't have, they also can developer as there is clearly the depth and breadth to rise to any challenge. They have solidified their reputations and can ignore the small guys now. D8 will further their gains in that space.
What matters is whether some official or unoffical groups can settle down to deliver good install profiles for the D7 versions
I wrote these blog articles some some time ago,
http://devblog.brahmancreations.com/content/back-to-drupal-humbly-tailly....
http://devblog.brahmancreations.com/content/do-php-and-drupal-have-a-bri... and my jury is still out.
Thanks for this...
I have been working with Drupal for over 6 and a half years and this is one of the more eloquent and level-headed conversations I've read about the problems that are emerging with Drupal. I'll keep this short. I won't restate what has been said already. I agree with almost everything that has been said and the basic point -- that there are so many options that almost, but not quite, fit the bill.
Before I add to the discussion, I would say that I am indebted to many people in the Drupal community, particularly at the beginning, 2006-2008, when it seemed to have fewer options, fewer people and a whole lot of interest in building this CMS into something better.
I'd describe things this way: The user is missing. Things are not designed for usability or even with a sense of how users might perfer things. This lack is far more noticeable now than 4 years ago because design on the Web has improved so. And I don't see that that's happened with Drupal. If anything things have gotten more complicated, as the original poster pointed out, by having to join so many modules to do related tasks.
I would add that there is no real solution for audio. And what about the stampede to cell phones and apps? And what of the continual problem with Flash, made worse by Apple's refusal, to allow it on their operating system.
And sadly I do feel that the originators, the leaders of this CMS, have drifted away to commercial ventures. No longer do I feel there is a vigorous and rigorous community on drupal.org hence there are more and more problems from incompatible modules, or updated versions that don't mesh well with other modules, or more and more abandonment of modules. Case in point, an early Drupal developer started in on the publish / subscribe modules.. which could have tremendous use, but nothing in a year and a half. ... Organic Archive -- great idea that really is important to the success of organic groups (how do you smoothly retire an organic group, anyway?) ... audiorecorder field -- great idea but not quite there, yet nothing has happened in quite some time. ... Kaltura, which was touted and then turned out to be a disaster, but then what? is it now OK? certainly doesn't look like it in my recent tests ... I could go on and on. But three years ago, I felt there was kind of a group that policed code, made sure things worked properly, that standards were kept to. Now, not as sure.
So everyone has to earn a living. I feel grateful and lucky that so many fine coders have helped me (a non-coder) accomplish things for kids that I couldn't have otherwise. But for several years, there has been a loss of direction.
An answer, perhaps we should form a group. Perhaps we should discuss what we do, how we use Drupal and share what we've learned all these years. But even as I think about that, two things come rushing headon -- my own lack of time and the fact that Drupal 6, which I use extensively, is on the way out. And I really should be in 7 -- despite that it's a memory hog -- and holy mackerel that means I have to rebuild everything because no way will I ever do another upgrade; going from 4 to 5 was bad enough, but 5 to 6 took several years off my life.
I fear that this, too, has turned rantish. My apologies. Let me again thank everyone in this community who have helped me and my project (s). I run a small nonprofit dedicated to helping students write and teachers instruct better and I've gotten help from all over the world, via Drupal. And I do believe the spirit is still alive. But the size, the popularity, has made the community -- the modules, the choices, the policing -- a whole lot more complicated and less organized. And as a result, it has drifted further away from precision and usability.
If anyone has any solutions, suggestions for what we might do to help, I'm all ears.
g
geoff gevalt
http://www.youngwritersproject.org
http://www.ywpschools.net
http://geoffreygevalt.com
I agree that Rails makes a
I agree that Rails makes a few things easier than Drupal. Drupal also makes some stuff easier. For example, one place that Drupal beats Rails BY FAR is multi-valued fields. In Drupal, you change a popup menu. In Rails, you add a new model and connect the two together.
Paradigm
This is a very interesting debate. Briefly I am just learning Drupal after completing a year of college learning asp.net and MSSQL.
This debate about streamlining a clarifying a best practises system to reduce the confusion at the burgeoning complexity of many competing and similar modules and their dependencies sounds very similar to the Perl situation which they have been attempting to resolve.
However this is the blessing and the curse of open source unfortunately as a project becomes more popular more users arrive and more modules and development occur. This initially seems good until the development becomes divergent and every developer wants to scratch their own itch and instead of the projects progressing in orders of magnitude it splits in groups who each have to try and maintain interest and progression.
So anyway on the example people left Perl because of its CPAN dilemma so many modules all relying on others and lack of maintainers for some dying modules. Where did they go? Python or Ruby and off these languages went and Django and Rails were born. But now with the steam of interest the ecosystems explode with itch developers and what happens in Python development diverges from Django and it now also has Web2py, Pylons, Pyramid, Grok, flask, bottle and many more Ruby has Rails, Sinatra and many more. So when will they reach tipping point there are already articles of people leaving(outgrowing) rails.
Imagine the progress Django could make if these development efforts were more focussed.
In Perl's case they are discussing a more streamlined core thereby reducing the complexity and as a group removing the dependancies and complexities from their most used modules(class mop etc). There is also a proposed plan to distribute a core set, a must have distribution of the most used and best developed and maintained modules that would suit the needs of 80% of people.
Maybe Drupal if it is having this issue could approach it similarly. Just a thought?
Rails?
You lost me when you said "Rails". I understand your comparison to Wordpress, Drupal and Wordpress are different beasts but they're both CMS.
I worked with Rails for over a year and I hated every second of it. Then I found Drupal and I saw the light, I never looked back. I understand your "issues" with Drupal but comparing it to Rails which is more like a framework makes no sense at all.
In my personal experience everything about Rails was time-taking, difficult, undocumented, almost impossible to get help/answers, plugins were a pain sometimes just getting a page to show up or a link to work was a problem.
If you like Rails then just stick to that.
I love Drupal but it
I love Drupal but it infuriates me too sometimes.
I can however make pretty awesome things with fairly slim knowledge of php. The problem I have is knowing what modules do what when it comes to a fresh site.
The myriad of (similar) modules to me is a real down point. And what about uploading an image, simple? Of course not! IMCE with bridge, Media 1x, Media 2x.... which one? And if you go for Media 2x, you'll need another module or 10 just to make module 1 work. This dependency has always been a mystery to me.
Other than a few annoying things though, it's superb!
Sam.
At last! I'm not alone!
It's been wonderful to read these posts from much more experienced users who are just as frustrated as I am. I've spend weeks of time and about $200 in teaching materials trying to learn Drupal and have finally decided to abandon it. (I've got some books at great prices!) I'm no great coder but I can write pretty complicated sites in PHP and MySQL and they work far faster than Drupal sites. Drupal is hard to sell to a client when you show them how to edit a site and they realize how slow it is. I've been playing with Wordpress and find it wonderfully easy and intuitive. I honestly can't see why anybody uses Drupal at all.
Just curious. You've been a
Just curious. You've been a Drupal member for over 2 years. Why have you only just discovered Wordpress now?
.
People use Drupal because it fits their needs. If it doesn't fit yours, then use Wordpress. Ranting because a tool doesn't meet your needs is pointless. Use what works for you. Simple as that.
I also see you had a huge
@omigosh I also see you had a huge rant about how horrible Drupal is in February, 2011 saying:
Yet you're still here. I'm not sure what you're wanting people here to tell you? Just don't use it.
A few things that might help improve matters...
I agree with a lot of points you mention - maybe because we both look at the challenge from a sysadmin perspective?
Indeed, the lack of support for working with images in a decent manner astounds me. By now anybody writing any kind of CMS, should know that the days of the BBS are over.
The amount of modules available for any given functionality can be very intimidating and frustrating, it involves a lot of reading, trying, testing, dismissing, go to the next one. (oh, wow this one looks good, oh... it conflicts with something in core or another module or only works in Firefox version ancient). At the same time it is great that there are so many ways to get things done!
Hold on, I´m getting to a couple of things that actually might help to improve matters.
What? Solution-think? Yes, I like to look at this from a sysadmin/project-mmt and end-user point of view.
1 - Create a strict set of rules that every module author/maintainer has to follow.
Rules like (in no particular order):
Not adhering to these rules? Stick your module where the sun doesn´t shine.
2 - Clean up - & restructure - Drupal.org.
It is really not that hard, though it does require a lot of work and dedication, as well as people getting off their high horses and learning how not to feel personally offended when their creations get criticized.
_
Say goodbye to the currently ginormous contributed module community-- one of THE distinguishing characteristics of the drupal community btw.
I just love it when I see those that don't volunteer their time advocating for rules for those that do, lol. Total non-starter.
There's probably more valid points upon which to comment, but unfortunately that statement alone causes me to skip the rest of your post.
Your last line proves my
Your last line proves my remark about high horses.
Besides "...don't volunteer their time " ??? You know nothing about me or what I do or not do, alright? So, keep your remarks to the point, please!
_
My remarks are to the point and those on high horses should be careful themselves lest they fall.
You reinforced my point perfectly-- it doesn't matter what else you do-- as you don't maintain modules on drupal.org you don't get to tell those of us who do how to do it. period. Drupal is not a democracy-- it's a meritocracy.
If you want to have a say in how it's done, I suggest you jump in and maintain some modules and show us poor dolts how to do it correctly. Otherwise, posts like this are just noise that go nowhere.
Alright, let me put it this
Alright, let me put it this way: your remarks would be more to the point if they adressed the possible solutions I mentioned, instead of basically telling me that you simply refuse to read my comment.
Secondly, anyone who is not maintaining modules should keep their mouths shut about how it´s done? That is not a meritocratic approach, it is arrogant.
You obviously have the strange idea that a view that is not coming from at least someone of your `level´ can not even be considered valuable.
Well, in that case be happy with yourself, rest assured, you cured me from my good intentions.
I wish you a nice life.
Besides "...don't volunteer
To be fair, the suggestions of those who are contributing to the community are likely to get more traction, not least because the experience of contributing gives useful insights. So it is of course unfair to say you are not contributing to Drupal (though under your present screen name your contributions may be under the radar as far as drupal.org is concerned). But it is perhaps fair, or at least useful, to ask you to 'blow your own trumpet' a little and mention your contribution, since you are (understandably) unhappy with the suggestion that you are not giving your time? We all know there is plenty wrong with Drupal as well as a lot right with it.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Goofrider raises some good points
Goofride raises some good points.
It's clear in some basic philosophies that become clear once you use Drupal a lot, that you begin to see some systemic failures within it.
Image handling is a huge issue. Its clear that Drupal core programmers regard this by and large as a secondary concern. Remember image only went into the core in Drupal 7... Hopefully this is a good sign of change in the future and I have not reviewed 8 yet but I hope this is a key focus.
Comparisons to Wordpress are a good idea. Currently Wordpress shows how user-oriented a CMS can be, and most CMS websites are often created in mind with a client wanting to adminster them (whether they do or not is another story) and they just care about ease of use. We have to build to this.
It seems to me that so many, many modules rely on each other for use and there are many conflicts and issues with this. In contrast to the WP where most of the plugins I use there are self-contained solutions, Drupal modules seem to rely on many many dependencies. This is a recipe for disaster in my opinion in the long term, but I understand the exigencies that have created this situation.
Memory usage is another. I don't know of one host we use who doesn't complain about Drupal in comparisons to most other CMSs.
Finally, documentation is a nightmare. Sometimes it's non-existent, or even wrong. There is a lack of consistency.
But what I do like about Drupal balances many of these out. I like that I can build an application with Drupal that solves real-world problems. This isn't so easy with WordPress. I like that there is a vibrant developer community within Drupal. I like it's power. I often think about Drupal as the Ferrari of the CMS world. If you've ever owned or driven in a real sportscar, you probably know what I mean. There might not be a glovebox to keep your handbag in, or the seats aren't exactly comfortable, and doesn't come with a sound system - but these optional extras can be replaced or added to. You will feel every little bump on the road, but that at least makes you know about the road you're travelling on. The engine, however, and the build quality are unmatched, and can go as fast as you want them to go. When you put your foot to the floor, there's a kick in your pants and the car flies forward. And that's often the most important bit!
I highly recommend Larry
I highly recommend Larry Garfield's presentation from DrupalCon Portland, 'Is Drupal a CMS'. He highlights the distinction between a CMS and a Web Publishing Platform. In the DrupalCon Portland keynote by Karen McGrane she speaks about a 'war' between a true CMS and a blogging platform. For her, the implication is, Wordpress is not even close to being a CMS in the sense of being a tool for managing chunks of clean content (as distinct from a tool for building web pages). But as Larry articulates very clearly, Drupal is trying to do a bit of both. D8 is making its web publishing more user-oriented, but in the argument of Ms McGrane that is a wrong direction (unless a way is worked out to found it on a clear CMS architecture in her sense of the term, which is not the case). If that brief summary does not seem to make sense, check out the videos. I have written a longer (and therefore, I hope, clearer) article about this for one of my clients but article will not be out for a day or two.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
What if...
I´ve been waiting a while, to see if anyone would address the possible steps leading to solutions...
Unfortunately, I am not surprised that nobody has.
What I see, is technically advanced people, often being challenged at producing proper documentation as well as listening to constructive criticism.
I don't see any reason why blowing my own trumpet would make my comments more valuable. They are either valuable or they are not. Obviously, this highly advanced and very intelligent community feels they can do without feedback.
So be it, I've wasted more than enough time on people that already know everything.
_
Including you-- which doesn't surprise me either. In 50+ weeks what have you contributed? And then you actually wonder why no one else is doing your bidding or taking your 'suggestions'. really?
Not true at all... but feedback from those who wish to tell others what to do without putting any skin in the game? Yeah, you're absolutely right... cat > /dev/null.... where it belongs.
No skin?
What do you mean `no skin´....
My comments go to dev/null because I´m not a coder?
This is the typical coder behaviour .... not being able to see the big picture so shoot the messenger, because that is the safest thing to do. Keeps you from falling of your personal pedestal... Sit on it, I no longer care.
Coders shouldnt write manuals
One of the main problems of Drupal is its inaccessibility for non-coding users. One cause for that is the documentation. Apart from it being fragmented, incomplete and scattered all over the place it is also written without any understanding of the non-coding user and therefore mostly incomprehensible. Of course there are exceptions (and the authors there are usually female).
I have been using Drupal for 8 years now and I have the impression that most documentation is written by the coders themselves. That is not very wise, specialists usually do not communicate easily with non specialists.
So as a science journalist with 30 years experience I offered to write for Drupal documentation.
The offer was gladly accepted!
But as a journalist I am used to get in touch with the people whose stuff I write about. To check facts (yes it happens!). So I asked whether I could then get in touch with the author of that specific module and ask them questions. Well that was not possible.
So I can only hope WorldFallz increases his efforts cause there is a lot to do and of course I'll shut up. I am of no use.
As ,long as the Drupal coders keep behaving like an impenetrable sect this is not going to work.
I can only hope WorldFallz
Her efforts.
----------------------------------------------------------------
On the topic at hand, I actually agree. Coders usually are not very good at writing for non-coders. And I'd say that a lack of documentation, and difficult to understand documentation, are often Drupal's biggest weakness.
Contact me to contract me for D7 -> D10/11 migrations.
=-=
for coders not to write documentation others must step up and do it. Unfortunately there are many users who've spent years using drupal that haven't taken the time or just won't help generate the documentation they wish they had. Those users always tend to have a reason/excuse for why they can't/couldn't.
An after effect of the negative reactions to those who do take the time to write docs whether coder or not? Less and less documentation. README.txt files with only directions on how to install the module and nothing more. Personally, I don't blame anyone for not wanting to invest any more of their time to a task that winds up generalized and under appreciated.
IMO the documentation issue that is addressed so often in a negative way is a community at large issue and therefore the responsibility of the community at large to correct. Including when developers can't or won't provide time for interviews. In cases such as the aforementioned, outlines or drafts can be completed even if there are gaps. Gaps can be filled in by others.
Lastly, some of the documentation sought will likely never be produced outside of authoring books.
UI problem
I definately agree with you with all you said. But I would like to add one more thing that I personnaly consider as the primary problem of Drupal: the UI. To me, the admin interface does not look intuitive at all. The first time you install it, you need to read hundreds of support pages to understand how you can use it. It is true that you can do many good things with it, but it actually does not look very attractive to people that are not developers. The big difference with wordpress probably stands there, and that's why Drupal is not leading the CMS market. Although, compared to other competitors like Joomla or SPIP, for instance, Drupal is far away more complete, and allow doing much more things, in a more powerful way. Even though, that's actually where comes the problem of the amount of modules. 10 modules for a simple feature that would be not even a plugin in Wordpress but a shortcode or a hook. Of course, I am exagerating, that's just my opinion.
As you probably know a lot of
As you probably know a lot of UX work has been done on D8. I think it is better.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
Well I wouldnt hold my breath
Reading this page: https://drupal.org/drupal-8.0 I wonder how one could conclude that the UX is going to be better. Maybe it is, but on this page the problem isnt even mentioned. So whichever changes they made to the UX, they do not consider usability it a major selling point.
I formed this view mainly
I formed this view mainly from hearing a presentation by core UX maintainer Bojhan https://drupal.org/user/87969 which convinced me that the work of his team had been valuable. It is likely some of his presentations have online video, in case you wish to make up your own mind about whether his attempts to improve UX have been worthwhile.
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
I've always had the opinion
I've always had the opinion that Drupal is beautiful on the inside, ugly on the outside. And we all know that on the first date it's what's on the outside that gets you a second date. So to sum up, it's a bit like that film, Shallow Hal, where Drupal is Gwyneth Paltrow and Wordpress is the horrible nurse. That's my take on it anyway.
No really Drupal Sucks and should die
Drupal sucks because
1. it is poorly designed
2. it is incredibly hard to debug
3. the documentation sucks, in fact does not exist for most "contributions"
4. the forums are unsupported. When there is feedback, it is useless.
Nobody should ever use Drupal ever again.
1. it is poorly designed
This is incorrect. It is actually an extremely developed architecture, which makes for an extremely powerful system. That said, it is not an easy architecture to learn, which leads to frustrated posts like yours. But don't mistake difficulty for a poor design.
Yes and no. It is definitely hard to debug, but fortunately there are many tools out there that can help with this.
This is correct. It's Drupal's biggest problem.
Speaking as someone who helps out on the forums pretty much every day, I find this comment insulting.
Considering my business has been built on using Drupal for almost all of our projects, this comment is ridiculous.
Contact me to contract me for D7 -> D10/11 migrations.
Let's not kid ourselves...
The architecture has no 'unifying philosophy'. For example, the unifying UNIX principle was "everything is a file", which means that it's possible to use the same set of tools to solve different probelms. In UNIX, you can cat, grep, pipe and zip everything from text files to script outputs to device drivers. That philosophy allows you to use laughably simple tools to acheive extraordinary results, which gives the operating system its power.
In Drupal, you have nodes, comments, taxonomies, users, roles, views, menus, entities, variables, translations, panels and a bunch of other 'special purpose objects' in Drupal - and none of them talk to each other. This means that you can have a module that'll let you embed HTML tags in node titles but you need another one to embed HTML tags in taxonomy terms, and another one to embed HTML tags in Views titles, etc. Some modules will even only work on certain nodes (like Ubercart) and create their own taxonomies (like Ubercart) that only work with those nodes (like uc_products) and don't work with anything else. Or consider the forum module, which is implemented as a node for the OP followed by comments for the replies, which means that, to, say, moderate the forum or theme it, you need to maintain workflows and code for two incongruent types of data. Try explaining that to a client!
It's for this reason that version upgrades are a nightmare. Consider this two-year-old, unresolved issue https://www.drupal.org/node/1823414 in which the 6 to 7 upgrade process permanently breaks the Ubercart catalogue because upgrade.php doesn't know what to do with the catalogue taxonomy so it just shoves it into a generic field, and when Ubercart gets upgraded, it doesn't know to rebuild the products with the field that update.php used.
I've described the Drupal model to clients by comparing it to English common law (with emphasis to Canada's Income Tax Act): both are built on a few simple rules with exceptions and overrides piled on top until the whole thing becomes a spaghetti mess and the relationships between the parts becomes lost entirely. For this reason, both common law and Drupal, I find, are mantained by people who have a very narrow focus in how one specific area works because the system is way too complicated and nuanced to 'understand everything'. I know that this is true for software in general, but perhaps I've become aware of it on late nights trying to figure out how a module managed to work in the first place and from where it's pulling its values.
I've read about 4 books on Drupal and spent countless billable hours on Google trying to find these 'many debugging tools'. Each one is like a specialised kitchen device that they sell on late night infomercials: you have one that only cores and cuts apples, another that only seeds oranges, another that only cracks and separates eggs, another one that only rotisseries chicken, etc. instead of something like a properly-designed knife that can cut, core peel, chop, etc.
No, the poor documentation (including books) which seem to spend more time telling you how wonderful Drupal is than telling you how to use it is one of many its problems. I think the biggest problem with Drupal is its inconsistent paradigm that leads to spaghetti overrides and conflicts.
I asked my local offical Drupal group a few months ago how to upgrade a D6 site to a D7 site and they said that it can't be done. In their experience, it's best either to stick with the D6 site or write an elaborate SQL program that can transfer the content from D6 to a fresh D7 installation. Just forget about update.php, they told me. I'm sorry, but even Microsoft hasn't produced a Windows version so bad that the only way to upgrade it was to write an elaborate registry script that could transfer your files to your new operating system. Android is pretty close to being that bad, but I digress.
Sorry to besmirch your honour, but he has a point. Yes, Drupal is a volunteer community in which its members are overworked admins and programmers trying to get through life like the rest of us. I totally sympathise and I'm grateful for when they take time to help other users patiently with no expectation of reward.
Drupal needs to be more honest about this, though. Had I known before recommending it to clients that I would be completely on my own every time I ran into a bug, crash or missing feature, I probably would have kept researching. In some problems, I've even gone to the module developers offering to pay them to help me solve one bug that's preventing me from doing whatever I need the site to do. Alas, they were too busy and refused my money. Instead, I believed the sales pitch that Drupal has a steep learning curve but works when you understand it. Linux is like that and works. Drupal doesn't and should admit that it's a volunteer project with inconsistently-implemented features of varying quality. When Drupal promises to be the CMS cure-all, it attracts admins like me who become frustrated and panicked when a client demands to know where his site is after 6 months of glacial development hindered by Drupal's resistance to certain types of customisation and pervasive bugs.
I bulit a business on Windows because I had steady business fixing it whenever it broke. My biggest competitor was Apple because, once they sold a Mac to one of my clients, they didn't need my help anymore. Fortunately, Apple is adopting the Microsoft approach to software design so I'm being called out again to fix misbehaving Macs.
In some ways, Drupal is like Apple: as long as you use it for precisely what the designers wrote it for, you're OK. Once you try to deviate from that at all (by, say, allowing users to buy from your store without setting up an account first or posting to a forum without an account or changing some text in a form or having the results of a Views query show up in something other than a table or a list), then you run into problems.
Oh, there's a module for that? Probably. But there are also 5-year-old critical-level bugs filed against it that the developer has neither the time nor the interest to fix. Want to fix it yourself? Well good luck deciphering the labyrinth of hook calls to understand why it broke. Oh, it only breaks for you and nobody else? Ahh, that's right: it conflicts with some other module you need because one of the hooks overrides another hook that produces output that doesn't work in the hook that your defective module uses. And so on...
A lot of that is fair. Some
A lot of that is fair. Some consolidation between data objects on Drupal 8. It will remain complex.
Balanced against that, there is no other system which has the potential to build so much customisation so quickly, and if it is done well, reliably, without a (possibly very expensive) lock-in to a proprietory provider. So yes, Drupal can be a hassle. If you want a highly complex, highly customised site, without having the funds to build it from scratch, and without having the funds or inclination to build it from scratch, or to sign up for commercial system which is no guaranteed to work better, what are the alternatives?
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors
I generally agree.
I generally agree.
I should note that "nodes, comments, taxonomies, users" are entities in D7, and "roles, views, menus" are also entities in D8.
It is getting better. D7 is a CMS written in 2009, and it shows.
You also appear to be using Ubercart, which in D7 is a straight port of a D6 codebase, never made to work with entities,
giving you at least 6 years of code debt and bad decisions.
The architecture has no
Again, incorrect.
Again, incorrect. Nodes, comments, taxonomies, and users are all Entities. Views works by pulling data from the various entity types, and is extendable to work with other data types as well. Panels is a special case, and I don't use it myself as it doesn't tie in with the core data structure.
The underlying architecture of Drupal core is the Entity/bundle system, and with it, extremely complex systems can be built that link these data types together. To be fair, some developers don't work well with this system, and if you are using modules developed by them, then you will have orphan data as you describe, but that's not a Drupal core issue problem, that's a contributed module problem.
Then you need to learn to code yourself. I literally never have any of the issues you are describing here, as I don't use modules to provide this functionality.
I actually agree with this, and if/when I build a forum again, I'll create my own architecture by creating an forum post entity type, and allowing it to have parents/children. I've done this on a social networking site, with a twitter like structure, and it worked way better than trying to use core comments.
I sort of agree with them. It's easier to re-create a new D7 site, and migrate content than it is to upgrade. But you don't need to write an 'elobrate SQL program', you can use the Migrate module.
I think that it would be a good idea for this to be written somewhere. That said, if you sold a client on Drupal without knowing how to build a site in Drupal, that's your own fault. You should never sell skills you don't have. Do proof of concept first.
And this is where I disagree. There isn't a site I couldn't build in Drupal. I've gotten over the learning curve. I'd suggest you haven't. It's a very steep curve. It took me about five years to get past it, working with Drupal daily.
I kind of agree - if you understand the way it was developed, you can understand how to develop for it in the way it was meant to be developed. And it works very well. But if you don't understand the underlying architecture, then you may use it in strange ways, which won't work.
I could handle all of these, and have in some cases.
Part of the steep learning curve.
I sympathize with your frustration. Drupal obviously isn't for you. To be fair, I don't think that anyone who isn't a developer should really use it, as they will run into the same types of issues you have. Trying to mix together dozens of contributed modules to get a site to do what you want is like building a puzzle out of pieces that may not actually fit together. If you are dependent upon contributed modules to build a site, then you will end up with frustrations galore. But if you are developer, and willing to write code, and learn how the architecture works, it's a thing of beauty. I'm working on an in-house project over this week, while my staff has the week off, and I've put together an extremely complex system with multiple dashboards, linking together multiple data types, and displaying the data in relevant formats for different types of users, and it's coming together beautifully. I'm basically using a few core modules for this:
* Entity Reference
* Organic Groups
* Rules
* Views
* Date
* Calendar
With these six modules, and some custom coding, I've basically been able to put together the majority of the site. I've added a couple of other modules, and I have a custom module and a custom theme, and when it's done, I'll have a light-weight SaaS system that we'll be licensing to users. Our deadline is to have the first release, multilingual, with a full automated testing system by the middle of February. I don't see how that could be done with any other CMS.
Contact me to contract me for D7 -> D10/11 migrations.
If you sold a client on
I've been using Drupal since 2008 and kept telling myself, as you've told me, "It's not Drupal, it's me." You know, like when someone's getting beaten by their partner and they keep telling themself that it's their fault for making their partner angry. After 7 years, though, I'm trying to break free of this cycle, which is tricky because Drupal has all of my stuff and I have nowhere to go.
Yes, I just compared Drupal to an abusive partner.
However, before insinuating that I'm a script kiddie who can't code, I suggest that you look at the dozen-or-so bug reports I've filed and fixed myself which suggest that I've tried pretty hard to wrap my head around "the Drupal way". Granted, I haven't trained daily like you have. However, I wasn't told that I'd need the dedication and effort of an aspiring Olympic athlete in order to write a featured but not too complex website. I was, in fact, told quite the opposite.
I didn't sell a client without knowing how to build a site as you say. I actually explained to the client that, in comparison to Joomla, WordPress and other popular CMSes, Drupal seemed like the only one that could do the job most efficiently. So, yes, in Drupal's defence, it is more flexible and superior to Joomla and WordPress. Still, I think Drupal evangelists have to stop saying that handwriting manual solutions to get Drupal working are "features" rather than flaws. This is what I was told when I started using Linux: it was a perfect operating system and having to debug and recompile my own device drivers was a "feature" of the operating system. Fortunately, Linux has since deprecated those features in favour of stable, out-of-the-box functionality.
However, since you said you could solve all of the problems that I'm having on this site I'm working on, perhaps I can subcontract my laundry list of problems I'm having with my client's site to you? PM me with your rates and we'll see if we can work something out.
I bulit a business on Windows
that is also the business model for Drupal shop. It will BREAK and need constant maintenance from the shop. your customer will crawling back to you on every major update (or sometimes minor update). so why complaint when that is a good revenue stream?, not to mention every development will cost them extra money in billable research due to super complex system. more revenue at hand :).
customer want to cut cost and give their site to novice builder? guarantee broken site and crawl back to you for more billable fixing time... wonderful isn't it? like a vampire having a human cow stored in the basement.
in the end... prepare give away 2 years of your life to fully understand what makes drupal ticks... drupal ought to give bachelor degree like university does as the amount of time needed to learn it as a master is equal of the time you'll spend to earn cs degree.
--------------------------------------------------------------------------------------------------------
if you can use drupal why use others?
VicTheme.com
Dupals is a piece of shit
There is no confusion at this point that Drupal is the worst CMS system ever developed. Nobody with any development background should ever use this crap. I really sucks.
_
wow, you really must have a lot of time on your hands, lol. if you like java and drupal sucks so bad, why aren't you off using java instead of posting in the drupal.org forums?
Probably the posts meant to
Probably the posts meant to be a little tongue-in-cheek: Ilikejava says
Of course Java is not really performant. For a really fast CMS someone needs to come along and built it in C, or maybe Assembly language. Actually that is not a bad idea. My new username will be Ilikeass.
[Mods: fine to delete that, if you must!]
Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors