A couple weeks ago I wrote a post on why customers complain about Drupal -- the short version is that they either had incorrect expectations, or "developers" who were in over their heads. Nothing wrong with Drupal there. There are some very legitimate downsides to Drupal from a technical perspective, however. Here are our top 6, and why they're not enough to keep us from recommending and using Drupal for nearly all our work:
6. Drupal is a total memory hog.
Under the hood, Drupal has a really powerful hook system, which auto-detects and auto-loads functionality. All a developer has to do is follow a specific naming convention, implement a specific hook, and the code gets auto-discovered and called in the appropriate spot. This power comes at a cost -- Drupal has to load every single enabled module on every single request to see if it implements a necessary hook. Since PHP is process-based and doesn't have any long-running threads, this means there's a performance hit.
On low-end commodity hosting, there may not be enough RAM available for the web server to load a large Drupal site. Generally we need to allow PHP to use at least 128MB per request, and on some large sites running lots of modules, even more. If you only have a couple GB of RAM available, you could run out with 20 active requests.
Fortunately, hardware is relatively cheap, and with the various caching strategies we typically use with Drupal, we can get sites speeding along. But this does mean you need quite a bit more hardware to run a large site than you would with a static site or a leaner, more efficient framework.
5. It's PHP.
I actually really like coding in PHP -- it's easy to learn, easy to understand, and pretty powerful. But it has a number of flaws. Historically it has had a slew of security problems due to a bunch of convenience things that went so far as to conveniently include remote code in every request, if you passed a certain GET parameter! These are pretty much a thing of the past -- PHP 5 did away with most of the glaringly easy ways to hack PHP sites. But PHP has kept the reputation for having shoddy security baked in...
I would really call out 2 weaknesses of PHP: no threading/inter-process communication, and very poor Unicode support. Lack of long-running threads, worker threads, or other things along those lines means that a huge percentage of the Drupal framework needs to get loaded on every request -- it can't just sit there in RAM waiting to get called. Drupal does not really have a way of registering functions that implement hooks -- it does cache many of them, but not all.
The Unicode issue almost seems criminal. We've had UTF-8 for way over a decade now, but PHP cannot accurately tell you the length of a Unicode string? This is supposed to be fixed in PHP 6, but for the time being, this means doing much localization work in PHP involves having your own string management functions.
So our assessment: Security issues are no longer worse than most other available languages, caching can mitigate some of the lack of threading (and it does make it a lot easier to program), and Drupal works around the lack of UTF-8 support with its own functions (but why should it have to?).
4. Version wars.
Drupal 7 has been out for 10 months now. Drupal 8 is in development. Drupal 5 is no longer supported. And we're still building most of our sites in Drupal 6. Anybody who has built a Drupal site starts out with the big question: what version should I use?
Drupal 7 isn't yet the slam-dunk answer. The reason? There are still a ton of very useful modules that are not yet available for Drupal 7 -- and many that are not even close.
Drupal 7 is a far better platform to develop on. However, there is so much already done on 6 that we can roll out D6 sites much quicker for our clients, at much lower cost, for all but the most simple brochure sites. We have done 2 D7 sites so far, and over 50 D6. D7 isn't even faster it turns out -- the main reason for going to D7 is that D6 is going to get left behind when D8 gets rolled out -- but at the current rate that's still a couple more years.
Drupal has a horrible reputation for painful upgrades. I would say that's largely an issue of the past -- most module maintainers provide decent upgrade scripts, upgrades tend to happen with no data loss and very little functionality change. But as a highly commercial platform (not proprietary, mind you, just used by lots of businesses) customers need to pay to get modules updated to the new releases, since most of the development of contributed modules is done by companies like Freelock, who get paid to do the work. And as long as it's cheaper to roll out a D6 site, and few other compelling functionality reasons to upgrade to D7, not many clients are willling to foot the bill to get the job done.
3. Abandoned modules
Or worse, modules that get replaced by an entirely different approach.
In the early days of Drupal, most site building was done by people programming custom modules on top of the Form API and the various other parts of the Drupal internals. Enough of these were generalized and shared back to the community that the next phase was characterized by thousands of single-purpose modules -- install exactly what you need for each feature you want to provide, and perhaps need over a hundred on your site.
Now the number of modules you need is getting far less -- we have more general purpose, extremely powerful modules like Views, Rules, Display Suite, Features, and Context. As a result, the single-purpose modules are becoming obsolete, and developers pretty much abandon them.
This is actually a good thing -- these power modules really let a site builder build exactly what they want. But they also each have their own learning curve -- it's not as simple to drop in and turn on the functionality you want, you generally need to configure the behavior you want after installing the power module. This makes the Drupal learning curve even tougher for people who just want a site -- if you don't know how to use the power modules effectively, you can easily get frustrated when you find exactly the module you want -- but it hasn't been updated for 2 years. Or if you've been using a module for years, and it's no longer supported -- and there is no clear upgrade path to something else.
This is where Drupal has turned professional. Site building in Drupal takes a lot of knowledge to do rapidly. And that's not knowledge even the best non-Drupal developers can get quickly -- so much of this knowledge is very specific to Drupal. Knowing which power modules can address the shortcomings of Drupal core, knowing when it's time to drop in a power module, knowing how to use the interface -- these you can figure out. But how do you even know the power module exists?
That's why good Drupal freelancers and shops are expensive -- they're in demand, and they can do amazing things very quickly. We may have a high rate, but we know how to get the job done...
2. Caching
Caching in Drupal is perhaps the biggest thing that mitigates the memory hogging, the performance issues, and so much more, making Drupal as fast as most any other platform out there. But it's also a curse.
In short, if your Drupal site is misbehaving, a surprising number of times clearing the cache fixes it. Drupal caches things at a lot of levels: during a request it caches every node it loads. The menu/URL system that drives every request is cached. Blocks and pages can be cached -- but by the time you reach the page level, you can no longer use caching if you have anything personalized on the page (such as shopping cart contents). Drupal also combines javascript and css into compact files.
Then there's system caching. We run a PHP opcode cache to get more out of PHP. We tune MySQL so that most of the database is cached in RAM. On some sites we set up file-based caches to skip Drupal entirely, or set up reverse proxies. And then there's Memcache for yet another layer of caching.
The problem with caching is making sure it gets regenerated when something changes. Generally the system is pretty good about clearing out changed data, but there are definitely lots of cases where this doesn't happen correctly.
Caching is really a band-aid for the poor performance of Drupal, the dark side of having so much programmer power. The upside is that it works surprisingly well, and makes Drupal competitive. But it takes knowledgeable system administration to get the maximum performance, or to scale to handle large traffic loads. And it is a source of quirkiness, a bit of an X-factor that can make problems harder to identify and locate.
1. "Drupal Developers"
How do you know if you've found a good Drupal developer? Lots of people claim to develop in Drupal, but there's a huge range in the quality of the result you get, and it's very hard to tell without working with somebody a while whether they know the platform well, or whether they're going to be learning at your expense.
We are all going to be learning at your expense. Development is about solving problems -- once they've been solved, they don't need further development! This is largely a question of experience, but I think there's an element of talent as well -- the talent to see where the crux of a problem lies, and be able to sniff out the heart of the matter. That's a talent, but more important is experience. We have learned a ton by making mistakes. We know how to roll out changes to production sites without breaking them (or at least keeping the broken time minimal). We know how to undo our changes if something goes awry. And things go awry in complicated systems more often than we would like. Experience has taught us to build systems to protect every move, much like a rock climber scaling a tough wall -- while there are a few "rock star" climbers who may free-solo El Capitan, most people who attempt that end up dead. Smart climbers use protection so that if they make a mistake, the rope stops their fall.
Making changes in sites that are already live is quite similar, and to do this smoothly, the protections need to be there from the start -- you don't scale half the wall before putting on your harness and trying to find your ropes.
The problem with inexperienced Drupal developers is they don't know how to protect themselves from the future. In Drupal circles, there's a phrase "killing kittens" -- if you're modifying Drupal core code, that's what you're doing -- something terrible. And the reason is that the next upgrade will clobber your changes. There are safe ways of changing just about anything you need to do -- but "Drupal developers" who are just trying to get your site launched and don't care about long term consequences don't bother with doing it correctly.
A lot of our business comes from cleaning up the messes left by developers who did not build in a future-proof way.
That's our list... do you have any others? Can we help you out of a jam from one of the above? Please comment below -- we moderate comments to keep out the spam, so it might be a few days before we post it, but if you're leaving something constructive it will show up.
Sounds like you've
Sounds like you've experienced my #1 reason -- Drupal "Developers!"
There's a great many really competent people working in the Drupal community. But there are an awful lot of people selling themselves as Drupal developers who really don't have a clue about how best to make the system work in a supportable, maintainable way.
I agree with you -- if you're not comfortable using git, configuring servers, doing all the dev-ops stuff, you'd better make sure you have someone handy who is, and treat them well. That stuff is critical to the success of any large Drupal site. We started out with a strong Linux system administration background before ever getting into Drupal, and had full-time systems administrators administering servers for other companies as well as our own. We still call that role "Systems Administrator," though the people we have in it become Drupal devs as well -- perhaps dev-ops is a better job title for them (and I count myself as one of them...)
But then again, people come to us for security scans, performance and scaling consulting, and more, and one of our key products is an ongoing monthly maintenance plan -- we make money doing dev-ops work. So we take it seriously!
Typical article and comments
Typical article and comments by non-developers and non-coders who think they should be able to "upload via ftp" and everything should already be done for them. Just because you learned how to use FTP doesn't make you a "coder" or a "developer". If there's a bug, fix it. Simple as that. Don't blame others for your lack of planning, experience, or creativity.
Wow, after a long weekend
Wow, after a long weekend stemming the tide of ~1000 spam comments and users, an actual, real comment!
@Drupalista, did you actually read the article, or just the headings? If you had actually read it, you might realize we're very pro-Drupal, very capable of addressing any shortcomings, and actually doing what we can to recognize real drawbacks that many uninitiated Drupal customers have experienced, while offering solutions.
Drupal has a mixed reputation out there because so many projects have gone awry. And they've largely gone awry due to "developers" not competent in how to build in Drupal -- like you said, people who have learned how to use FTP and call themselves a developer.
And the other factor is not understanding the full nature of the project the customer wants delivered, or having a realistic budget for it -- "I want something like Facebook, and my budget is $2000."
With proper budget expectations and competent Drupal developers, we think it's a great platform.
"I want something like
"I want something like Facebook, and my budget is $2000." is exactly my circumstances here.
John, do you think Drupal is the right tool to build community sites? I'm trying to bring a system (made by third-party developers) to the finish line.
It was built on Drupal Commons. Could you share some tips for newbie like me? At the moment, I am treasure-hunting every day trying to find where this and that piece of code come from. I used to code in CodeIgniter where everything is in your sight.
Drupal is an excellent
Drupal is an excellent platform to build community sites. I don't know of any better.
But $2000 is simply not enough to build a quality site with any level of complexity on any platform. And community sites get very complex, very quickly.
Expensive Drupal
You're right - Drupal isn't good for every website. It's dedicated to more complex services!
what is meant by "complex"?
I've done a few community sites with Drupal, and I'm slowly getting better at it. I chose Drupal initially because of it's fine grained permissions - other CMS don't seem to compete in this area (or at least they didn't - has that changed?).
There is a lot in this thread about "complex sites" - but what does that mean? My sites typically have 4 roles, 20 content types, maybe 5 - 10 custom views, a few hundred pages. The design is done by committees (!!) so that can be a trial. I'm not a PHP coder, and so far I've managed to keep all my customising to CSS. Because they are community sites, all the community members have to be able to access and/or update the site. Maybe any CMS wouid have worked, but the permissions were the deciding factor when I committed to drupal, and I don't do enough to want to learn multiple tools.
I love Drupal but Spam is killing my Site
Hi guys , really nice comments here, i am new to drupal, i really loved the whole architecture and the way things are done there, but as soon a smy site is finished, SPAMMERS have almost ruined the whole site even with CAPTCHA enabled comments.
Please can anyone help me with this - Am almost losing my mind here !
1) Ensure you have Mollom.
1) Ensure you have Mollom.
2) Have recaptcha if the issue persists.
3) Finally ensure login to post the comments. You can use the Facebook/Twitter login in the site.
AND
Funny site is made with Drupal and comments Why Drupal Sucks :-) Very Funny!!!
I totally agree with the
I totally agree with the point about caching. It's really a mess when it comes to troubleshooting. But it also has a silver line: it works well. I have some sites that I don't even look at over weeks and still they have up to date cache.
A developer asked me to help him with some advanced development work for a university site and I "shipped" the functionality (it was about content moderating) as a custom module and they were quite happy. I wasn't allowed to access their site in anyway so at least I could add some rep to drupal hooks system. But it costs server resources.
Nice article and comments. Keep it up!
Most systems suck
Hi there,
me - beeing a CMS integrator over 10 years think: Most CMS Systems sucks. Especially the big open source ones. I do Drupal multisites, multilanguagesites with workflows and so on and it sucks ^^There are so many times we´re discussing Drupal and it always results in "Drupals structure is not good since the beginning of time" we have developed a CMS and we had to rebuild it in the past years even we have dipl.informatiker (real coders) who are thinking about things before they do it. Most of the systems out there were something like a news database that grew. Sry i have to laugh but the drupal developers never heard about oop when they "developed" Drupal. So why do i drupal? Well it´s cool in some ways and after a really hard work and much modules it behaves a bit like a good CMS. But the development time IS yet high cause there are more screws to turn to have a good result.
And it seems better than typo, WP and the kiddy-system joomla so Drupal is like a one-eyed under blinds.
Once i thought, we have 2012 and the systems are a bit better. They are, but i think systems like CONTENS are way better.... if they had stopped dev in 2005 (and they did not).
2nd reason why we use drupal is that there are many addons out there and it´s popular ( well and we have not only customers who spends 50.000+ in building a website^^).
For those who are beginning with a cms and have customers where you are able to say "use the cms we have for you" give PimCore a try.
It won the Most Promising Open Source Project Award ( i think in 2010/2011). PC has a good structure. There are good possibilities to do things. But the award is not only saying that PC is good, it also says that there are only stinky OS-CMS out there ^^ (yes it does!).
Well me for myself know some cool (!) systems out there but unfortunately they are not ready to use (in my perception of usage) or are not growing fast enough or were simply not told the award referees^^ (Anyway.. we have 2012!). Surely there is the one or the other four star system out there which i don´t know. Sorry to you!
Ah and I have one more thing for your list: the learning curve. It takes much time to handle the Drupal api (for example) (which makes -as a sidenote- obsolete to talk about typoscript). And everytime you introduce a new module you have to learn again because you´re not only adding features, you change Drupal behaviours.
Greeetings
Lars
I drank the kool-aid
I just love these XYZ Sucks! threads. Ruby/Python/windoze/crApple/Java/PHP/jQuery sucks!! Is there anything that doesn't suck?
Of the 6 criticisms above, most of them have nothing to do with Drupal per-se and could be applied to any number of other technologies. The fact that Drupal developers can be hard to find or that PHP has a history of poor security aren't really criticisms of Drupal. Drupal caches lots and uses lots of memory. Well, these are issues with all CMS platforms. I don't know absolutely, but I bet Drupal, Joomla, Wordpress have similar resource requirements out of the box.
Bottom line, it's a trade off. If you want dynamic content generation, customized user pages, configurable widgets, etc... there is a price to pay. If you have mostly static content, there are many options to reduce memory and database usage (boost module, for example).
CMS haters gonna hate. They typically favor custom solutions. A lot of snobby, cms-hating developers think they're better off building up a rails solution from scratch. Well, talk to the company that buys into that in 5 years, and see how swell of a time they're having maintaining that, improving it, finding people to work on it. I've done it both ways, and I'll never build from scratch again unless there is a solid dev team and endless funding in place to do it right.
Building a large site is a lot of work. CMSs handle much of that work for you. All the time you save not building an authentication system, content interfaces, forums, etc... should be spent taking the time to learn how to use your CMS properly.
And quitting hating so much.
Uh, er, um, hmm...
Your site is on Drupal - so - er, hmm, well... WTH? :) But I totally understand the frustration. With new versions, people hope to 'release' themselves of the developer-debt they've left behind while picking up some new liens on slicker technology - without the forethought on "gee, how are we going to carry-forward and make modules fit into the new system?". :) Instead - it's a... "hey, let's make it so good they'll WANT to do it..." and as you pointed out - the challenge with most developers (including myself...) is if it ain't broke - don't fix it! And why would a developer push their module/plugin/theme to a new version that hasn't even been seasoned as of yet... (ok, i'll stop here before I go change all my drupal sites to something diff ... possibly static html sites? :) :P ).
"Your site is on Drupal"....
"Your site is on Drupal".... FUNNY.
John, you are self-contradictory. If you think Drupal is suck, why you use Drupal? You can use Joomla or Wordpress. But I don't think they are better than Drupal.
I think if you read elsewhere
I think if you read elsewhere on this site, you might find answers to your question... :-)
All systems suck. They just suck in different ways! This article was attempting to express how we deal with the sucky aspects of Drupal, because overall it's a great system. But we like getting the straight scoop out there -- there's so many Drupal sucks stories that are filled with mis-information, I thought it was worth setting the record straight!
But you'll find lots of other stories on this site describing how/why Drupal beats the pants off Joomla, WordPress, and even custom development with a framework.
Right on John. No framework
Right on John. No framework is perfect. And for me drupal is still the best because it does not assume what you are going to build. You can build anything with it. That's what makes Drupal different from everything else and that's I think the reason why developers continuosly develop modules for Drupal because of it's flexibility. There might be a steep lurning curve but I consider this probably trade offs. But from Drupal 5 to 8 in how many years time? For me that's enough to say something outweighs more than any other arguments. If people does not love Drupal we would not have 6 7 or now even 8.
Drupal is a disaster
Going to 'Drupal Rock Star Developers' does NOT fix the core problems of the platform. We spend close to $ 100 K on a custom site, hiring some of the top Drupal designers and developers, very involved in the community, and authors of various popular modules. What we learned is that most Drupal devs don't know shit about OO programming, unit testing, deployment, respecting deadlines, reading UML diagrams and so forth.
After enduring 3 years of an unusable site (a large portion of our 30,000 members also author content, but can't figure out their way through XDrupal's admin mess and don't have the patience for its abysmal performance), we've decided to bite the bullet once more and move away.
I also have to laugh at the amount of excuses from the Drupal community regarding Drupal's piss-poor performance. You make it sound like it's a developer problem, yet your own static web site averages 800 ms per request on 100% static pages. The simplest web sites in you guys' portfolio gets 1000ms response time on most pages (and that doesn't account for any external files, I'm only referring to the initial request). That's just unacceptable.
Drupal is a mess, developed by PHP amateurs, and any business or non-profit should stay away from it.
Either you have simple needs (a blog and a few content types), if so Wordpress is something worth looking at. For all other complex requirements, find a hosted SAAS answer that solves 80% of your problem, and consider changing your business processes to fit the software instead of the other way around. That way, the custom work you'll have to pay for is simply an integration job.
Hi,
Hi,
Thanks for your comment!
Those are definitely valid criticisms. But you haven't pointed out a better approach -- do you really want to risk your entire business to a SAAS vendor who may go out of business or pull the plug on something you rely upon? I would argue that SAAS carries a huge, often unrecognized business risk in that you don't directly control the functionality of your site, and you're relying on the SAAS vendor to get it right -- with what might be a very difficult migration if the vendor decides to take the platform in a direction that doesn't meet your needs.
So I think any organization that cares about risk management should be very, very careful before going with a SAAS platform. At least with an open source or custom solution, you've got full control over what your site does, and nobody can take that away from you -- you can always decide to roll back to a prior state.
So what's left? All CMS solutions, as well as frameworks, have some performance implications -- they tend to get optimized for one kind of performance, and suffer in other areas. I'd say where Drupal is optimized is in terms of developer time to get to a feature-rich, functional prototype very, very quickly. And in many cases, developer time is the most expensive thing to pay for.
If you're developing from scratch, you can optimize for page load speeds, have minimal code in page generation, and eek out actions in fewer milliseconds. Do your customers really notice a difference between a site that loads in 1/10th a second vs. 3/10ths a second? (Yes, our average page load time is more like 8/10ths a second when you visit pages not recently cached, but for our home page and popular pages with fresh caching, we're seeing more like 300ms.)
If you're using a framework like Rails or Django or Symfony, it's going to take a bit longer to get a functional prototype with as many rich features as you can get with Drupal, but over time I'd say the total cost is going to be quite similar, given competent developers. With a Drupal site, much of our time is spent on simplifying interfaces, removing clutter, smoothing out the user experience on a system that largely works out of the box, aside from a ton of tiny integration bugs that always crop up. With a framework, you tend to have to build more in the first place, but you can also leave out the cruft as you go, and keep it simpler.
Regarding what "Drupal Rock Star Developers" know or don't know about programming practices, you can extend to the entire web development community. You'll find a huge number of amateurs turned pro on every platform out there, a vast number with no professional training. That's not a problem with the platform, that's a problem with web development in general. True, Drupal isn't OO (but take a look at what's going into Drupal 8, where you can actually do much more conventional OO programming). But I think of it as more of an event-driven architecture, with its extensive hook system. Deployment is a challenge, when you have structural configuration stored in the database (again something promised to change in Drupal 8). Unit testing is built into Drupal 7 core now, and we're making quite a bit of use of the simpler UML diagrams to plan out what we build and make sure we're on the same page as our clients.
In short, if you have a complicated problem, a $100K site might not be a bad deal. You can very easily spend that much on a single in-house developer, and many custom applications are built by teams that can burn through $200 - $300K a year at least. Lots of enterprise applications cost more than that in yearly licensing fees alone, and then you're still spending more than that on implementation.
There's no magic bullet out there. I've seen enough under the hood of proprietary systems to know that just because some software is commercial and expensive, it can still be total crap.
Your developers are more important than the platform. And if your problem is complicated enough to need a major amount of their time, it's not going to come cheap.
Cheers,
John
Point taken. My gripes are
Point taken. My gripes are with Drupal 6. We simply cannot upgrade to Drupal 7 without an extensive re-write of a bunch of modules. We'll spend that money on a different approach. The Drupal 6 effort was just way too painful., and the end result too disappointing.
Yes, most web devs fit that profile, it wasn't fair for me to single out Drupal devs. And you are correct when pointing out that there are no silver bullets when it comes to CMS platforms. We used to have an awesome custom portal developed in C# / .Net, but adding functionality was too expensive since it required someone to know the intricacies of the platform and we couldn't justify the costs of a full-time dev team (we're not a software company).
In the end, we're just going to simplify our membership and permission architecture and CRM / e-commerce integration to fit existing hosted solutions. Although third-party systems may be crap under the hood, at least there's guaranteed support. If stuff breaks or doesn't perform and needs fixing, it won't be at our own dime.
Drupal's event-driven programming model might be very powerful, but it creates code that's difficult to read. When trying to make the smallest technical change, I find it very time consuming to find where the problem is located. A custom module? View? Block? Theme template? CCK? Text formatter? It's absolute hell. A pure MVC approach is much easier to test and maintain.
Finally, when regarding performance, it seems like caching efforts in Drupal are done with scale in mind. So yes, for a 50 pages site getting 1000+ visitors a day, performance will be alright (FYI, 250 to 300ms page load is usually my target. As you mentioned, anything below that is not really noticeable). But for a large specialized site with 10,000 pages, directed at 500 to 1,000 authenticated users per day, most hits end up loading the page for the first time, which in our case takes up to 4 seconds. Yes, 4 seconds. 2 if you're lucky. That's just asinine. The reason? Way too many db queries (200+). So the answer tends to be 'turn off a bunch of modules'. Well, if the only way to run Drupal properly is to stay close to initial config, one has to wonder what the purpose of Drupal is since its only real strength is module availability and management.
Caching and optimization should be first-class citizens in any CMS IMO. A good write-through cache with efficient serialization (protocol buffers do wonder) should be part of the core data store so all modules take advantage of it. This alone would solve 75% of performance problems.
And you have hit the nail on the head right there
With your comment ...
"We used to have an awesome custom portal developed in C# / .Net, but adding functionality was too expensive since it required someone to know the intricacies of the platform and we couldn't justify the costs of a full-time dev team (we're not a software company)."
Always the downside with bespoke development.
I'm a bear of little brain and by no means consider myself a guru developer and my opinion is worth what you paid me for it. But I think it's worth looking at the narrative of why you would adopt Drupal as your chosen CMS in the first place. The number one reason for me is that you get so much bang for your buck, you would be crazy not to. As a sole developer I know that if I use drupal I can build a lot of stuff up quite quickly, within an hour or so I can have a fully fledged community up and running that has a tried and tested completely secure registration system at it's backbone. That I can create a myriad of content types, allocate roles and permissions, use views to easily build an infinite number of data screens, all with very little effort.
OK so that's your first decision point. And that may be all you want your site to do. You can easily argue a case for WordPress/Joomla etc here and for many sites I think any of these would be acceptable and because Drupal can be an ornery old thing, I think for a lot of sites WP would be the way to go. I personally think using a framework to get this far would seem an unnecesary expense unless you want much more fine grained control of the application in terms of the performance/caching/sql/code structure etc but if you could find a framework that provides out-of-the-box all these things that Drupal does or you you can stomach the extra development costs for these, then maybe a framework is the way for you.
The next decision point for me would be the predicted size of the site. I am currently working on a site that has about 20,000 registered users and about 150,000 nodes. By no means an enormous site, but the strain is showing and this site could not operate effectively without all the extras outlined above ie Varnish reverse proxy, memcache for some of the tables and APC for opcode caching. The beauty of Drupal though is that all of this is possible, the downside is that it's not always straightforward. Again though if a big enough budget was available I would consider a framework if I wanted more control of the application as there is no doubt about it, with Drupal you have to do it their way.
The next decision point for me would then be future development requirements. If I knew for example they were looking for e-commerce, greater usage of localization data, multi-language, extended profiling etc I know that for these and many other features that there will be a fully fledged working module that I can plug and play or one that will give me 90% of what I need and I can code the rest. I suspect that for a platform most of this may have to be written from scratch.
The final issue for me then is the amount of bespoke coding. As always you are at the mercy of the people who write the code. If you cannot afford to have a dedicated team who take pride in producing well structured, well documented and well tested code, then using a framework will not save you from the expensive maintenace legacy this will result in. If you have good code review processes in place this should not happen of course and that is true of writing Drupal modules too. They have best practice guidelines and I follow these as well as walking through any contractor developed code. So I see this as a draw.
Now so this brings me to Drupal's downsides. It has a steep learning curve. Version upgrades can be a pain, minor ones, less so, major ones more so. Some critical modules like views can be really,really inefficient (as always you can override with hooks - but see learning curve point) Documentation for modules can be plain rubbish, either badly written or not there at all. There are lots of little perverse elements that annoy me, the biggest gripe that I have is the lack of a built-in out-of-the-box wyysiwyg editor with a built in media uploader. This too me is insane. I have never had a site where I didn't need this and cannot countenance not needing this. Afficiandos would argue that that's because it lets you choose, but as I seem to have trouble every time rememebering whether to use the WYSYWIG module or not to use it or to use the standard fckeditor or the fckeditor with/without WYSYWIG, the forums are full of people equally confused. More experienced developers will use installation profiles and features, but for the low to mid-ranking technically-minded I think this can be baffling.
I have a constant love-hate relationship with Drupal, but I would not consider using anything else and though many of the comments above are interesting none seem to address the issues that I as an often one-man-band development agency face in terms of resource constraints
Page load
John, we´re talking about high load sites. Believe me, some companies are spending 10.000s of getting some ms.
They develop frameworks to minfiy, collect CSS/JS from the different systems, error-routines, mimimizing threads (for example the use of one big image which is positioned via css instead of many little images) and so on. The speed (and Caching System) is unfortunately a big issue in Drupal imho. As far as i know it is impossible to cache sites but do not cache some blocks (for example: we have a site, where we wanted a random slideshow). But anyway: i think Drupal is cool and we are able to realise alle requirements - even for customer with 80 Million business volume p.a.. (okay, i´m thinking hard about the speed at the moment and in Drupalcommerce the language of products generated in display types are not correct BUT WE CAN DO IT, Chakah :-)
Cheers
Lars
C'mon
There's too much crying going on here. Drupal developers contribute their work to you for free and now you want to cry about it?
Hmmm no, based on my
Hmmm no, based on my experience, that's not how it works at all. Drupal devs make money as consultants, good ones charging about $ 175 to $ 250 / hr. Every custom module developed for the project gets released as open source - I was told by Drupal devs that's part of Drupal licensing model. So technically, those modules are not 'contributed for free'. It's more of a pulling of resources in order to avoid redundant work. In the end, everybody wins - devs, clients, and the community. But let's stop with that whole 'Drupal devs are all saints' rehtoric.
Generic IT complaints, not just Drupal
Reading through the comments it is difficult to work out what issues can be attributed to Drupal or just IT problems in general such as:
In short there are many problems within the industry that have nothing to do with the tool. One could get into quoting examples where a particular language/technology was successfully used to create a successful application, e.g. Facebook was built using PHP. The statement can be misleading and should be, "Facebook was built by a knowledgeable developer using PHP". Yes there is a difference.
Hi,
Hi,
You nailed it. That's exactly the point here -- the vast majority of the complaints we hear about "Drupal" are problems with the industry, not with the tool.
This blog post does acknowledge what I think are the actual short-comings of Drupal, and how we handle those shortcomings -- every tool has shortcomings, after all. The prior Drupal Sucks post brought up more of the complaints we actually hear, which really have little to do with Drupal, and everything to do with poor planning/execution.
Thanks for your comment!
Sorry John, but these things
Sorry John, but these things apply to lots of software. Besides, everything has pros and cons, I don't think it is fair to say it sucks because of its cons.
Drupal
For us, the single biggest nightmare with Drupal has been using it to implement a discussion forum. Requiring administrator approval for new users is the ONLY way we've found to avoid being deluged by literally thousands of Chinese and Russian spambots that have new Drupal account creation down to a science.
For companies that have a dedicated list of users, Drupal is fine. For those that want to interface with the public, I say RUN.
Thanks for your comment.
Thanks for your comment.
Have you found anything better to "interface with the public?"
Spam is certainly a big problem these days, across the board. There are a bunch of tools to help with that -- we've found the "Are You a Human" captcha we're using on this site to be the most effective thing we've found yet to combat spam. It still seeps through, a few a week, but not the hundreds or thousands per day we were getting last year (at one point Mollom was blocking nearly 8000 spams a day for us, but still letting batches of 50 or so through at a time a couple times a week).
I would say combatting spammers is one of Drupal's strengths -- there are lots of tools to deploy. Doesn't mean that's an easy job, but if you've found something better, please share!
Quite some truth in here
Disclaimer: I work almost exclusively with Drupal.
Yet I can still see why people might hate it. To really get the benefit out of the tool, you have to spend a lot of time with it.
If I wanna hire a dev for a job, mostly I would end up with one that does Drupal exclusively, which is a problem in itself. You have to work your way into the Drupal API, all the gazillion modules, workarounds and best practices.
So if people are using multiple tools and just wanna use Drupal for one or two projects, I cannot see a way for them to succeed. The people that complain here mostly fall into that category, I guess.
But as others said: this goes to blame any complex framework. We simply have not come far enough to have industry standards that are so widely adopted that you can switch from one CMS or Framework to another and expect to have the same workflow. The situation may be better with more low-level Frameworks like CakePHP, Symphony, Zend or Rails, but I stil guess you won't expect to adopt a new one and launch an important project with it within a months time.
So as sad as it is: If you wanna succeed with Drupal, you will need to put in a lot of time and basically build your business on it. Or at least have a solid Dev division (this means more than two or threee people) in your company that has that expertise. Else you are most certainly going to be disappointed.
I like your comment about Drupal Developers
Working with Drupal I have seen as many ways to develop Drupal as I have seen developers of Drupal. As a reluctant developer of Drupal my approach has been a hard sell to clients because I am not so much developing as un-developing or trying not to change Drupal. As a non developer, I do not have the flash and pizazz of other high and mighty developers for clients that seem to prefer big bloated complicated sounding ways to do things. I have found however that my sites perform well and do not break.
I got punked by drupal
Thank you for showing the rest of the world what I came to know most painfully. Back in 2008 we paid a drupal developer to develop a cutting edge technology driven website, comprised of the drupal platform, php, mysql, with a custom database with a pretty extensive but simple algorithm,
It took almost 7 months of development to be able to do a launch. The guy we worked with, Bram M. of Game Face Webdesign, LLC was just god-awful and used over 30k of our money to build a cob-job of a website that in the end didn't function properly and looked like crap.
The website was to bring alot of people in and I'm convinced it would have definitely done just that.
But, he messed with the registration process, he changed the core code. There would be times if you hit the wrong button in the CMS it would change the theme and crash the whole website and lock it up. The only way to get the website back would be to do a set back on the server.
Years later and after much heart-ache AND months in court trying to get at least a little bit of our money back (which we did win in full), I'm stuck with a website that cost a fortune, that is stuck in some old fashion drupal program, and that no developer can figure out because he killed the core code. To fix it would cost a lot of money, we'd have to completely build the site from scratch again. As a start-up company, we only had that one shot.
Man, it would be my ultimate dream for a developer to help me pro-bono or based on future income. Doubtful though.
Coralyn, I would be
Coralyn, I would be interested to know more about this website and its functionalities - would you be able to provide a link or even leave a contact email?
Yeah, what's the site do? I
Yeah, what's the site do? I have enough training I need to do something.
Right on the dot
But Drupal is still one of the best platforms out there. If the whole community were to abandon Drupal I would probably be the last developer standing to support it.
Nice post
I usually find lots of biased opinions on Drupal and long lists of supposed problems that are not quite very accurate.
Yours is a very good list of problems with Drupal that anyone that is considering using it should take into account.
I myself love programming with python and I'd really like to spend all my working time with Django powered sites. The problem is our team can build Drupal websites in no time, thanks to all the excellent modules available.
Most of the projects we deal with need nothing else than Drupal. Django is nice, clean and considerably easy to learn and maintain, but even with its problems Drupal has the great advantage of having so many features ready to use.
Drupal CMS
I think Drupal CMS has problem with the flexibility and site architecture as compared with other CMS.
But, don’t think it is not powerful. Recently, there are 19,964 modules, 1,605 themes, 534 distributions and 23,111 developers in Drupal worldwide.
Cacheing just needs tweaked
I've had great success with the following techniques regarding Drupal cacheing.
http://www.rklawson.com/blog/2012/04/14/caching-drupal-7-varnish-apc-an…
Using Varnish, APC and Memcache, with their related modules show great promise. Sites that I have implemented this on have extremely fast page load times.
APC really rocks in small
APC really rocks in small vagrant box. Turn off all other caching, just use drupal apc module.
Hi,
Hi,
It's not quite that simple. You do get a noticeable speed boost by using APC, especially as you near the capacity of your server. But it's a small boost, especially when compared to other caching techniques like Javascript/CSS aggregation, image sprites, page caching, and front-end caches like Varnish or Boost.
APC mainly makes the PHP run slightly faster, so this will likely help logged in users who cannot use page caches more than logged out users, if the other caching options are in use.
Drupal issues are management issues
This is what I've got to say. Drupal's issues are learning issues. For one Drupal 7 shouldn't have been allowed to interfere with Drupal 6. Drupal 6 was when Drupal began to mature and instead of consolidating the gains made in Drupal 6, all the developers saw was the problems Drupal 6 had and then turned to focus their attention on Drupal 7, which also resulted in a split effort on the part where instead of improving and honing their Drupal 6 modules the developers turned their attention to Drupal 7.
Even at this stage a lot of Drupal 7 modules are not as good as their Drupal 6 counterparts if they exist at all? Take this module - http://drupal.org/project/select_or_other. A lot of Drupal 6 modules did the same job and much better, and it is still being maintained along its question able path. The edit list below should be a lookup list which will select the item being added if it exists or add it if it doesn't. It is as though the developer never knew Drupal 6 to base the module on it, what you may know as http://drupal.org/project/taxonomy_super_select which has a good write up here. http://pages.uoregon.edu/vid/2011/01/21/put-taxonomy-super-select-check…. This is the kind of module that should be adopted and incorporated as standard into Drupal, but somehow it seems to be overlooked in the rush to develop Drupal 8.
It really begs the question whether it is meaningful now to describe any particular version as Drupal. It seems now to be a name associated with a group of developers rather than a clear cut product. Drupal 8 looks like it is going to be so different that other than being able to load your data into it. it will be questionable to regard it as a successor to Drupal 6 and 7. Using Drupal is more a question of what developer community and philosophies you work with, rather than a clearly defined product.
As you can tell I have engaged in my fair share of Drupal Sucks debates, http://drupal.org/node/1603830#comment-6384644
http://devblog.brahmancreations.com/content/back-to-drupal-humbly-taill…;
http://devblog.brahmancreations.com/content/do-php-and-drupal-have-a-br…;
http://drupal.org/node/1299736#comment-6168028.
My conclusion is simply this - if Drupal is going to be an end user tool after Drupal 8 is finished more effort should be dedicated to end user install profiles. They ought to decide on a version which is more or less frozen for upgrades so that all effort goes into replacing existing parts with better written parts transparently. Without development of stable and durable installation profiles Its days as an end user tool are more or less over. After Drupal 8 the community needs to consider whether Drupal 10 should be written in PHP. The language is so awful. It has already turned into a developer tool and for them to learn a new, simpler clearer language shouldn't be difficult for them. The community is their strength, not their unwieldy legacy codebase. Ditching a lot of it will be a boon.
Great point.
Hi, Frank,
That's a really great point. I keep hoping that we'll smooth out the upgrade challenges between major versions, but inevitably it ends up being a migration/rebuild than a straight upgrade, because how you solve a particular development challenge ends up being substantially different between the different versions. Perhaps an easier migration than from other platforms entirely, but to a certain extent, you need to rebuild your theme, re-create the functionality in the current set of preferred modules, constantly adjust your recipes with new best practices.
I still find myself asking, well, what is the alternative? Drupal may suck, but so do all the alternatives, they just suck in different ways! And sometimes even in the same way -- take the Python 3 upgrade, for example. I've been doing web development since 1995, and Drupal development only the past 5 years or so -- I've worked with or been exposed to a lot of other platforms. And you're right -- what's compelling about Drupal is the community and philosophy.
I'm terrifically excited about what's going into Drupal 8, but it really is a different application than 7, and 7 is an entirely different animal than 6. The problem with ditching the old stuff is that people are building businesses on this, and you can't force a major upgrade every couple years without having major defection from the platform. At least the time frame seems to be lengthening -- we're telling our new customers they'll be able to run 3 - 5 years before they need to be prepared for a major upgrade...
Is there something wrong with
Is there something wrong with the page numbering of the comments? There is a problem which seems difficult to fix in Drupal.
A case of the cobbler's children?
Cobbler's children, indeed.
Cobbler's children, indeed. Haven't had a chance to clean that up yet!
To do a simple task may take a lot of time
I'm sorry John but my conclusion that Drupal sucks big time.
For example using your own javascript takes a lot of preparatoins other
than just including it.
In 1 of my D6 projects I had to add hierarchial select. To do that I had to make
a lot of coding due to form cache issus.
I use now Codeigniter in my projects, developing is much faster and flexible.
Hi,
Hi,
Thanks for your comment! We often find that some simple tasks do take a lot longer than expected -- but we also often find that for some really complex tasks, "there's a module for that" and development goes much more quickly than expected.
There are widgets that will do hierarchical selects for you, no Javascript necessary. Yes, cached forms can cause problems with Ajax callbacks -- I'm not a fan of the Drupal patterns for doing Ajax myself, I think they're generally bloated and confusing but adding Javascript to Drupal is not at all difficult. Drupal 7 with its renderable arrays are a big improvement for attaching custom JS behaviors to elements. And Drupal 8 with web services at its core promises to make Ajax a much more first-class experience.
I generally find Drupal to be great for rapidly developing a fully functional, large-scale application. Usability is where you end up spending a lot more time in Drupal, to the point that getting a really polished, usable end result is likely to be similar cost on Drupal compared to a framework like CodeIgniter -- with Drupal you get working but confusing things in very quickly, then spend a lot of time polishing out the rough edges and tracking down strange conflicts. With a framework, you spend a lot more time developing functionality, but you can keep the user interface strong and consistent as you go.
Overall, I stand by my original argument -- the end result is going to depend far more on the developers doing the work than the chosen platform.
Cheers,
John
OneCebu.com Loves cause it sucks!
As this article says, it hates Drupal! But heck we love it! And we highly recommend it. Drupal is not for the faint hearted, and we totally understand you. ;)
Yet another poster who didn't
Yet another poster who didn't actually read the story ;-)
Whatever
PHP SUCKS!
(Says the developers who got thrust into a project primarily consisting of PHP--something they likely know nothing about but if they do, then they forget that every language sucks sooner or later.)
DRUPAL SUCKS!
(Says the Wordpress, Joomla, Concrete5, et al people who know nothing about the general architecture of Drupal, it's API, etc., etc. or those who simply forgot how complex CMS platforms can be... It's nice being humbled, right?)
CPU consuming more memory in plain drupal setup
Hi,
after many issues with performance issues (cpu utilization), i started testing with plain setup /standard setup of drupal-7.20, when i tested by browsing the plain website (http://192.168.110.215), in putty using 'TOP' command it's showing (httpd) 30% of cpu usage, and i created 3 concurrent users using jMeter it gong more 90%, if it behave like this, my application will not go live any more.
I appreciate your suggestions and instructions, i have to do for this.
Regards,
K.S. Vedhamsh
I'm been using drupal for
I'm been using drupal for years now and compared to what I was at the beginning and what I am now, I can tell you there's a huge difference between an expert drupal developer and a professional PHP programmer who is just gonna start your project with drupal for his first time.
Reasons I always shouting this to friends who want a simple/huge web site are mentioned at this very article/comments.
Your #1 reason is actually every client biggest problem here, means(mentioning drupal long learning curve, how to use API, how to handle and configure your server and...) a drupal beginner developer can burn you to ashes and an expert drupal developer can make you gold real fast.
If you don't want to pay for expensive team don't ever play with drupal, this is the best advice I can tell to customers here.
And about #2-6 reasons, compared to MVC framework and every drupal developer goal which is to build every site capable of everything real QUICK it's a head up. It's a fact of knowing how to use it, you may like or hate it.
And I always see people complaining about modules versions and updates. Not telling this isn't a problem but working with every other CMS or framework you almost need to write a module from scratch. I mean if a drupal module doesn't have what you need, we can always edit and develop it the we want and if you want to develop with Yii you got to develop almost everything from scratch. That's the beauty of drupal, hundreds of developers with thousands of code standard modules.
Add new comment