Top 6 reasons Drupal really sucks -- Developer Edition

Fri, 10/14/2011 - 11:12 -- John Locke

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.

Story Type: 

Comments

Submitted by BrianBurnham (not verified) on

Wow. Agreed! I'm still glad I went with Drupal though. I imagine things will get better over time!

Submitted by Jason (not verified) on

No, storing everything in the database is the #1 reason Drupal sucks. Trying to coordinate database versions among a team of developers across dev, staging and production environments is the single biggest pain point in developing a Drupal site. Drupal might actually be a decent platform when this problem is solved.

Submitted by John Locke on

Hi Jason,

Thanks for commenting. But there's a module for that!

We use Features module to coordinate staging structural changes that are in the database, to export configurations to code.

It is a bit cumbersome, and doesn't cover everything -- but more and more it covers the vast majority of what we would want to deploy between different instances of the site.

Combined with drush to update or apply the features quickly, and git to merge in any conflicts, most database changes are completely manageable.

I would definitely agree that deployment on Drupal is challenging, but that's a flip side of the power and flexibility that comes from being able to change the data structure on the fly through the interface -- and with the current tools, a lot less of a problem.

Submitted by Simon (not verified) on

There are so many things wrong with Drupal I really have no idea why any decent company would use it.

We tried it where I used to work about a year ago, we had numerous issues with it, a couple of which were:

- Modules not getting bug fixes / support, which then meant we had to delve right in and in some cases it would have been quicker to simply write the module ourselves.

- Flexibility, or rather lack of, primarily due to the terrible performance / heavy resource usage, we found it quite limiting in what sort of site Drupal was suited to, ideally it seems to be for content sites that have enough traffic to warrant a dedicated server and where most of the content is not updated that much so caching can act as a crutch. Which was pretty useless for a lot of "social media" sites which are updated a lot as Drupal's performance was simply unacceptable. Same goes for when we were being nice and doing say a site for free, for a small charity, they don't have the money (or traffic to merit) a dedicated server that Drupal seems to need.

- It is a badly written mess, not just in terms of code, but the actual mechanics of many aspects of it, for instance implementing the design, all our designers who are quite at home with templates / HTML, could not stand the bitty, over complex, all-over-the-place nature of Drupal.

In the end we went back to a framework, they perform better, are written better, they are easier to debug, are more flexible and once you've got a some basic common modules/plugins/admin written then they are quicker to develop with.

Submitted by John Locke on

Hi, Simon,

Thanks for your comment. Much of what you say is true -- modules getting out of date, heavy performance/resource needs, and some over-engineering in many places that make it more complicated to do things than should be necessary. And I'm finding with Drupal 7 that some of these things are getting worse, not better.

But at the same time, I disagree that going with a framework gets you there quicker. I would say that if you are proficient and experienced building on Drupal, you can get a lot of functionality deployed very, very quickly compared to a framework.

The main reason to use Drupal is to get moderately sophisticated sites up and providing value to your organization quickly. To do this successfully, you definitely need to be very knowledgeable about what works and what doesn't, what modules to use and which to avoid, and when to just write some quick custom modules from scratch. But you also need to be knowledgeable about a framework to develop something solid there, too -- and I would argue that you have more work to do to get a moderate level of functionality built and deployed quickly.

For large custom sites, either Drupal or a framework can get extremely successful results, with different development challenges along the way. With Drupal, you're going to be dealing with caching strategies, memcache, custom modules -- but it certainly can scale up to the largest scale. With a framework, you have to build more (and if you're not careful can still end up with performance issues).

Cheers,
John

Submitted by Guest (not verified) on

"- Modules not getting bug fixes / support, which then meant we had to delve right in and in some cases it would have been quicker to simply write the module ourselves."

Oh no, that means you have to write some code yourself :/

Submitted by Simon (not verified) on

Having to the write the code yourself rather flies in the face of a major alleged selling point of Drupal - i.e - that there are all these modules that provide functionality saving you the time / effort, but of course that would require them to be kept up to date, which seems a big issue with the non-core modules.

Which leaves you in the position of having to write modules yourself, I can do that in frameworks, that are much better written, more flexible, can be run on half the number of servers (sometimes less) and are generally more pleasant to work with.

Submitted by ñull (not verified) on

A complaint about missing bug fixes is one thing, but the question is if all the complainers who had to fix it themselves are then also contributing their fixes? Drupal.org is a community and I get the feeling that after Drupal 7 something went wrong with it. I think that there are working drupal systems out there with bugfixes that were never committed back to drupal.org. When the community breaks, then drupal.org breaks and we all suffer.

Submitted by Steve Tidebeck (not verified) on

That about sums it up. The biggest problem I had simply learning Drupal was dealing with modules used as examples in the learning books I was using that were out of date and not maintained. Then, when I finally learned the software, I discovered that I was going to be spending (wasting) a huge amount of time testing and maintaining modules. It is truly module madness, even with GIT.

Submitted by DC (not verified) on

I cannot understand why upgrading Drupal from one major version to another has to be such a royal pain in the ass! When I work with Wordpress sites its only a matter of a few clicks and zero coding or anything.

I'm so done with Drupal I cannot tell you. :-(

Submitted by Todd Lockhart (not verified) on

Ummm... you clearly haven't used drush. Upgrading even major versions is relatively painless in drush - you'll still need to deal with the fallout of modules that are no longer compatible, but that's to be expected.

Submitted by Leo (not verified) on

Ummm... you clearly haven't read (or rather understood) what 'DC' was saying. When someone says there's a feature in WordPress that isn't in Drupal, this isn't an opportunity to jump in with some command-line solution. I mean, your answer in itself points to one of the biggest problems in Drupal: namely, the fact that self-described 'developers' really have no idea what a user-friendly solution even looks like. Pathetic.

Submitted by John Locke on

It's not quite that simple. Yes, WordPress can make very nice user-friendly solutions, for their relatively simple problem of providing a blog/news/brochure site. But for any site more complicated than that, upgrades are never a simple button-push process -- at least not without carrying a big risk of something going drastically wrong.

Drupal has an entirely different philosophy of upgrades. I would argue that most Drupal developers (at least competent ones) are working on far more complex sites than a typical WordPress site, so the assumption is that upgrades should be done very carefully, in a test environment, with code management and deployment processes in place. Not a single button click-and-hold-your-breath type of operation.

In this context, a command-line solution is far more preferable -- it lends itself to scripting, automated testing, and catching things that break before they become embarrassing problems in a production site. To me, WordPress's single-button upgrade process carries so much risk in it and puts so much out of your control that I would be terrified to use it. See this post for more...

Where i work we are maintaining several Drupal sites.

Out of all the sites we maintain many of which are built in Wordpress, Joomla, Expression Engine and so forth, the company accountant had the most unbiased view. ous

From a purely economic perspective our accountant sees the word Drupal most frequently in over budget timesheet entries. This involves many developers spanning several years so I see this as a legitimate issue.

If you are a Drupal guru and work primarily with Drupal I am sure there is not a problem you cannot solve. For the rest of developers who work on a wide range of platforms that would not be the case.

Submitted by John Locke on

Sorry, I've been neglecting the comment queue, and it's nice to see some real comments instead of just spam!

@ DC a couple points: first of all, upgrading in 7 can now be as easy as Word Press -- go to the update page and click the update button and all updates will get downloaded and applied. However, this is a very bad idea for security reasons -- if your site is set up on the server to allow updates, it makes it pretty easy for an attacker to plant code up there and hijack your web site. This is part of the reason we see a lot more exploited Word Press sites than Drupal sites... and now that Drupal does it too, I fear we're going to see more compromised sites.

@ Peter I would ask whether the Drupal sites are doing much more than the Word Press/Joomla/Expression Engine sites. Not all sites are equal, and it may be that your Drupal sites are trying to address a much more complicated problem. Or maybe your developers are learning Drupal on your dime (or otherwise suck).

Submitted by Guest (not verified) on

Please stop using Drupal, you will make me less lucrative which will drive down my daily contractor rate :-)
yours faithfully, a happy drupal developer since 2006 :-)

I often see Drupal developer get a little too enthusiastic and telling clients that Drupal is made out of angel farts. This can make life miserable for everyone, especially those who have to clean up the mess later.

My only wish is that when building a website with any CMS, developers are honest with client about a CMS versions end of life, which is typically 4-5 years.

I am currently fixing a Joomla site that requires a complete rebuild to upgrade from 1.5 to 2.5. Drupal isn't the only CMS that sucks. All CSM suck after a while.

Submitted by Sigal (not verified) on

I've been using Drupal a few years ago, and did a site or two.

In the last year I started developing with Codeigniter and Fuelcms and since I love coding I had lots of joy.

Now, I am going back to Drupal, since I have an opportunity for work with Drupal.

But I get so frustrated trying to do simple styling, simple jquery calls or other things around the site, that at the end of the day I'm ready to chope somebody's head off. I find myself sitting for hours reading tutorials, books, blogs, posting in forums and still don't find the solution for a simple problem that would take me an hour to solve not using a cms.

I don't know, I keep moving between using cms and not using cms. I guess nothing is easy in life...

Submitted by John Locke on

Hi,

This sounds like you've hit the learning curve wall on Drupal. It has its own patterns that make it extremely powerful, but also make things much harder if you don't use those patterns. And... these coding patterns change, sometimes substantially, between major versions.

But I would say, stick with it -- Drupal 8 is becoming much more like other frameworks you may have used. In fact, it is basically becoming a Symfony application. Aside from becoming much more object-oriented than it's ever been in the past, there are a huge slew of improvements -- configurations managed in code, a REST server in core, page-wide context objects, an entirely new theme engine using Twig... really exciting stuff from a coding and site management standpoint.

No system is perfect, there are always tradeoffs. But if you're a coder who ran screaming from Drupal in the past, take a look at what's going on in Drupal 8 -- you might find a system worth revisiting!

Submitted by Yoke Lee (not verified) on

OMG exactly my sentiment!
I used to play with CodeIgniter and I love it soooooooo much.
Now having to code with Drupal Commons, I've been having nightmare for a week...

The choice whether to use Drupal CMS should be given to the client instead of forcing them to use one and dictate the technology instead. Who decides that Drupal CMS should be used? Clients probably don't have a clue and instead hear someone saying Drupal is the solution for all of their problems, then quickly jump on board to find a developer.

Each application is different and has different needs. These needs need to be taken into account before selecting a technology. We ended up rewriting half assed Drupal mess too many time. Sometimes Drupal is the choice, but not always, be careful what you wish for.

Sayonara

Submitted by John Locke on

Hi,

I think you've packed three different issues into this response:

  1. Should the client choose the technology platform, or the developer?
  2. Is Drupal the right choice for the problem?
  3. Does Drupal mean "half assed mess?"

All legitimate concerns.

For #1, choosing and architecting a solution is definitely a more strategic decision than finding a developer to implement it. While there are things Drupal doesn't do -- desktop applications, or native mobile apps, etc.-- we think Drupal stands up well as a web application framework, and in the right hands it can greatly reduce development time. It's not extremely performant, but there are lots of ways to scale it as needed. And so for us, people either come to us because they have selected Drupal already (which is a huge number of our customers, and a big reason we've chosen to specialize in it) or because they have a problem we can address with a Drupal site, and they are selecting our team.

  1. This depends on the problem. For web applications, it's pretty good, and it's getting much better for web services in Drupal 8. As a data warehouse, it's decent into the hundreds of thousands of rows of data, but if your problem involves millions or hundreds of millions, I would be using custom data structures, perhaps just getting to my custom code via Drupal. It doesn't integrate with Office like Sharepoint does (but does pretty much everything else better). It can't handle thousands of open connections like node.js (which we're starting to use for certain parts of the problem). It can't be taken offline on a mobile device (which we're starting to do with Dojo Toolkit). But overall, it's decent -- and by specializing in it we have lots of tools for getting jobs done quickly.

  2. Depends on your developers. If you have half-assed developers who don't know what they're doing, you'll end up with a half-assed mess. If you get some decent developers with a clue about how to leverage Drupal effectively, it can be done very well.

Hey guys,

I've been trying to get a solution going, and maybe this is the right place, seems like everyone leaving comments really knows their stuff! I myself am a CPR instructor first, and business owner second.

So I have kind of a mess of a few websites:
http://www.funcpr.com is the old ugly main one
http://www.funcpr.com/newsite is supposed to be the newer design
http://www.funcpr.com/newyork is the NY site where we have classes
http://www.funcpronline.com is the online training side that will have user registration to view content, then a shopping cart to pay for a certificate.

We even have a back end that we use to keep track of students, clients, and schedules, and I've really wanted to add access control for instructors and clients that can only view their data, but no clue if there are modules for that.

This is done with a programmer coding in PHP and JS, and a mysql database. I have zero coding knowledge, but I'm tired of relying on the programmer for every little feature to add that I feel a good CMS will offer, either by default or with a module.

The "Products" we sell, are actually spaces in CPR classes, so we show a schedule, # of spots available, etc. Currently, I don't use a shopping cart for this, just a custom script done by a programmer, so no fancy newsletter, facebook integration, nifty payment gateway, and other bells and whistles that are found with a cms and good shopping cart.

So I'm thinking of bringing the website over to Drupal, and when the purchase needs to be made for the class registration, a shopping cart will be used, so I can add functionality in the form of modules ON MY OWN! I realize the custom pages can't be altered on Drupal (by me at least) but at least I'll be able to add functionality with a shopping cart module, right?

So what say you, experts, not sure what to do. I thought about wordpress, but heard with more of a complex website like mine, it might not be the best idea.

Any info would be greatly appreciated. Wheew! Finally done :)

Jason

Submitted by John Locke on

Hi, Jason,

I'll connect with you offline, thanks for commenting!

Meanwhile, here are some thoughts:

1. Yes, absolutely, a Drupal site can do everything you're looking for, and more.
2. You should be able to change content pretty much anywhere on the site, if it's built for you well.
3. I would not suggest playing around with modules on an e-commerce, production site -- there are a lot of crappy ones out there that could open you up to problems.
4. Before doing a custom e-commerce site, read this post about the costs: http://www.freelock.com/blog/john-locke/2011-09/hidden-costs-e-commerce-... -- you are entering another realm of cost to do this well, without exposing yourself to a lot of risk.

Hope that helps, and feel free to contact us directly at 206-577-0540 or through our contact form (http://freelock.com/contact).

Cheers,
John

Hi John.

I ever played with Drupal for some months a year ago. It's very powerful, but I faced the upgrade problems when Drupal 7 were released. Yes, Drupal suck!

I'm an amateur in web design. I use WordPress but now I wanting to try and learn others that are more flexible and powerful than WordPress. What will you suggest me? I know a bit about PHP but don't want to dig it deeper. The software should be beginner friendly, easy to update and powerful (like Drupal has CCK, Views, Rules, etc).

Handoko.

Submitted by John Locke on

Hi, Handoko,

All systems suck in one way or another. The important thing is to recognize clearly the shortcomings, and how to deal with them.

So in spite of the title of the article, we love Drupal here, and would completely recommend it for nearly any web project.

And Drupal is getting easier and easier with each version -- try Drupal 7, you'll probably find it quite a bit easier to use...

Cheers,
John

Our accountant told us cannot use Drupal anymore due to the fact that over the last 3 years, with various developers, every project that involved Drupal lost money. Project using Wordpress, Expression Engine and PyroCMS have been and still are profitable.

Now we have former clients coming back asking us to help them "upgrade" since that nasty orange box now appears on their outdated site dashboards. In many cases it is simply impossible to upgrade without rebuilding the sites since many of the older modules no longer work with Drupal 7. From an economic perspective we simply can no longer go down that road.

Developers who "LOVE DRUPAL" take that long learning path and end up in a place they think of as the Temple of Drupal. Non-Drupal developers (accounting for 96.5% of the community - http://trends.builtwith.com/cms) see them simply as people who do not use OOP or MVC and are generally difficult to work with.

All I know is that if I was a Drupal developer (or a Flash developer), I'd be keeping my options open by learning something else.

Submitted by John Locke on

Hi, Peter,

Thanks for the comment. I would ask two questions about the Drupal projects that cost more:

  1. What sort problem were the Drupal sites built to solve?
  2. How competent were the Drupal developers engaged to build the site?

In many cases, the problems that people choose to solve are not the simplest -- the complexity of a project can have a lot to do with its eventual success or failure. It might well be that the Drupal sites that did not pay off were ones that would have failed in any system, with improper planning.

If you're doing a complex web application, proper planning is critical to its success, as well as a full understanding of the system. Not just how it's to be built, but how its users need to interact with the system.

Having come from a non-Drupal background with plenty of exposure to other systems, I see how Drupal has a unique architecture that can be confusing/counter-intuitive to many experienced developers. And there are a great many Drupal site builders or freelancers who don't have a full understanding of how best to accomplish things in Drupal. Both can lead to a crappy end result -- the experienced developer may engineer additional systems that take a lot more time to develop than leveraging the Drupal API, leading to much higher costs, whereas the non-developer "Drupal developer" will get stuck somewhere unable to smooth some rough edge the client really needs smoothed.

I do think a Drupal site will cost more than a Word Press site. That's because competent Drupal developers are in great demand, and charge more for their services, whereas there's a flood of lower end Word Press developers driving those prices down.

However, as the complexity of your need goes up, the cost of doing it in Word Press quickly rises to match or exceed that of doing it in Drupal.

I would say Expression Engine is more on par with Drupal, though it's a lot smaller market and there's less power available out of the box (if you consider Views and Rules and some other critical modules to be "in the box" for Drupal), but it's more of a niche player -- we get a ton of business because we specialize in Drupal. I'm not familiar with PyroCMS.

If you're comparing to an MVC framework, I think you can get to an early deliverable far quicker in Drupal if your need is at all content related. For more specialized sites with very specific workflows, the cost of a competent Drupal shop compared to a competent shop around a framework of their choosing will most likely even out over time, and won't make much difference in the long run -- frameworks might get a slight edge if your biggest design principle is simplicity, while Drupal gets the edge if you want to support adding a lot of additional features/connect to other services.

Whatever the case, you don't want to be the first Drupal project for a developer or shop, just like you wouldn't want to be the first Rails project for a developer or shop -- it takes experience to be able to consistently deliver a quality product. It also takes a proper development process that includes planning and testing, and an appropriate budget.

We lose a lot of potential projects when we quote a price, because our recommended budgets include planning and testing. We gain a lot of business from failed projects, people who have gone with a "cheaper" alternative unable to deliver in the end.

So Peter, we'd be happy to assist your former clients with their upgrade needs. We offer ongoing maintenance plans, and set proper expectations about ongoing budget necessary for sophisticated sites. There are a huge number of very successful Drupal sites out there -- most of which have regular attention from dedicated staff or a firm like us on retainer keeping them going. Yes, that's a higher cost, which means the site needs to deliver more value to the organization. With its better security controls and broad applicability, we think Drupal is a great platform for custom e-commerce needs, client portals/extranets, vendor management tools, companies with a moderate-sized marketing team with an appropriate web strategy, and much more.

If all you need is a blog and a brochure site, and you don't already have Drupal talent on hand, Word Press will be cheaper. But I'd still encourage you to check out Drupal Gardens as a way to easily start with Drupal in a place where you can easily export and grow into a more sophisticated site down the road.

Cheers,
John

I agree with many of the points that you've raised, as well as with some of the other posters. The biggest issue that I see, is that Drupal tends to be advertised as a CMS like WordPress, when it's really more of a Content Management framework. I'm a big fan of Drupal, but only when it's used in the right context, and when Drupal fits the project at hand. If you're just trying to set up a blog then you do not need to be looking at Drupal. On the other hand, I feel like a non-developer could set up a fairly complex site, fairly quickly using Drupal along with some contributed modules. Sometimes it seems as though once people learn a tool, they try to do everything with it. You wouldn't use a screwdriver to drive a nail... So why would you use Drupal to build a simple "business card" site.

Submitted by John Locke on

Hi, Richard,

Thanks for your comment. And it's a great point you raise -- pick the right tool for the job.

But I would modify your metaphor a bit. Drupal's not a screwdriver, or a hammer -- it's a professional tool that takes a long time to master.

In the hands of somebody experienced, Drupal can be a very quick, effective way to get a simple "business card" site launched. In the hands of somebody who doesn't know Drupal well, they're going to spend a lot more time figuring out the tool than it will take to build a site in an easier platform.

I've built and launched simple sites in Drupal, with content, in under 3 hours. And we're working on systems to roll out site skeletons in under a half hour.

If you gave me WordPress to do the job, I can certainly do it, but it would be like taking away my tablesaw and screw gun, and giving me a skillsaw and hand screwdriver.

It's not that Drupal is the wrong tool for the job -- it's just the wrong tool for novices. And professionals of all kinds generally bring their favored tools to the project, whether it's construction or web development -- if you trust the professional, you should let them pick the tools...

Cheers,
John

Submitted by swati (not verified) on

I have site in drupal 7. The site is very very slow. It consumes almost 100% CPU resources even if only one user is surfing the site.

The site has multiple content types. I have to migrate data from other site so I am using few modules for migrating data.

I am using few more modules like Image cropping, Autosave, Page title, Module for Meta tags etc

I dont think I am using any module which can slow down the site.

Pls help to figure the root cause of slowness and improve the performance of the site.

Submitted by John Locke on

Hi,

We'd be happy to get to the bottom of your performance issue. You can see our rates here: http://www.freelock.com/products/217 .

Most of the time, performance issues are related to not having enough RAM for the resource-heavy nature of Drupal. But if you have enough RAM, it becomes a matter of tuning the database and web server to use that RAM effectively and not swap to disk.

Let us know if we can help!

Cheers,
John

Submitted by Judge Penitent (not verified) on

I hacked webforms module before I knew about, or had time to know about, the Rules module or even content types and theming... 2 drupal trainings, 1 drupalcamp, 2 drupalcons and a preconference tutorial later I still do not consider myself competent at drupal, although they do throw me some sys admin tasks once and a while since I do know vi. Now I have to diff the webforms security update with my hacked version of webforms. I do know command line diff, lol... webforms was recommended for the job by a very very very experienced drupal developer. With all this sys admin work generated from the Drupal zeitgeist(varnish, php-fpm, git, mysql tuning, memcached, mongodb for field storage, blah blah blah) I wonder if I will just slide into devops full time to support the last mile (no actual sys admins will come within a mile of drupal devs) how can I go back to worrying about breadcrumb trails and wysiwigs and theming after all this, but then do I really want to be a concierge to these drupal devs who won't be budged from their macbooks and other nice things which they should not have, after multiple linux trainings are still a million miles from having access and lurking through operations and hosts and getting files moved around, learning or even having interest in chef, vagrant and similar stuff, and doing it without hosing the system and calling devops to fix the mess. Devops is recently being denigrated as a term not to call yourself if you want to be taken seriously, well what is the term to be then? "Loser"? It's good money...

Submitted by John Locke on

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!

Submitted by Drupalista (not verified) on

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.

Submitted by John Locke on

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.

Submitted by Yoke Lee (not verified) on

"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.

Submitted by John Locke on

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.

Submitted by Tosin (not verified) on

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 !

Submitted by Vittalasm (not verified) on

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!!!

Submitted by Ayesh (not verified) on

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!

Submitted by Lars (not verified) on

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 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.

Submitted by Bill (not verified) on

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 ).

Submitted by Guest (not verified) on

"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.

Submitted by John Locke on

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.

Pages

Add new comment

  1. Freelock computing is, in my experience, unique in that they have assembled a comprehensive, well-rounded team of technical specialists yet they function on a high level together as a team. The Freelock team is adept at speaking in human, non-technical terms  when discussing projects with laypeople.
    Throughout the development process we inevitably came to many decision points in terms of which direction we would continue, and Freelock was always instrumental in counseling us through the merits and liabilities of the choices in front of us.

    Jon Stone, Owner
    Littlestar Prints

Need More Freelock

       

About Freelock

We are located in Pioneer Square, in downtown Seattle. 83 Columbia Street #401 Seattle, WA 98104  USA [P] 206.577.0540 Contact Us/Directions | Site Map Get Updates ©1995-2014 Freelock Computing