At Freelock, we're huge fans of Drupal. But we keep running into customers (or potential customers) who are terrified of it. So here's our take on why.
5. I just want a web site! It's too complicated!
Drupal is not just another web site builder. In experienced hands, it's easy for a Drupal developer to spin up a simple web site on Drupal -- I've done it in a matter of a couple hours, complete with initial content. But if you're not experienced with Drupal, the learning curve to get something useful is steep.
It's getting better all the time -- Drupal 7 is reasonably straightforward to deploy and get a basic site up. But it's not easier than Word Press or any of the dozens of hosted site builders out there.
The reason? You have to make a number of decisions right out of the gate, and much of this has to do with what kind of information you want to put in your Drupal site. Drupal is very bare-boned to begin with, and relies upon a lot of add-on modules to put together something useful.
However, if you're building something to manage information, the tools that are available for Drupal really exceed what's out there for other platforms. Modules like Views, Rules, Commerce, OpenLayers, Workflow, Calendar, Signup, Context, Fivestar, and Drush can be combined to build powerful sites with very little custom code.
If you only need a basic web site and don't already have a Drupal developer, I would say Drupal is way overkill. But if you need a bunch of web sites, or a web site that does something unusual, check out Drupal.
4. My Drupal site is hard to change -- I always have to call my developer to get it to look right.
Two possibilities here: You're either really picky about your design, or your developer took way too many shortcuts in your theme.
We've seen some horrible custom themes out there -- functionality that should be in a custom module, dropped into a theme. That means when you change the theme, parts of your site breaks. Or if you turn on a new feature, it looks really bad. Hint: if there are 100 individual template files in your theme, YOU'RE DOING IT WRONG!
I am not making this up. We have a client who outsourced theme development to an offshore firm (actually 3 different ones) and the resulting theme has overrides for individual views (and lots of duplicate views that should be combined and set up with an argument).
At a certain point, it's easier to scrap crappy custom work and implement something clean using standard, powerful modules and a solid base theme than it is to make simple changes to a horribly implemented theme.
Done right, Drupal makes it really easy to change any content anywhere on your site, while locking down the design to keep it consistent. Design changes usually take a developer or skilled themer to make -- but everything else you should be able to change yourself. And if you don't know how, ask your provider for help -- we generally lead our customers up the learning curve with enough training/knowledge as they're interested in having.
Of course, if you're just really, really picky, it's going to take time to dial in no matter what platform you use.
3. The one feature I need takes custom code!
There are well over 8,000 contributed modules, but it always seems like the feature you want isn't quite there. Or it's there but it no longer works. Or it doesn't work the way you expect it to.
For example, there's a couple modules that we deploy regularly to handle paid event registrations. The main one, uc_signup, can be set up so anybody can register any number of people for an event, and pay for them. The catch? Each attendee needs to have a unique email address.
One of our clients wanted to make it so conference attendees could register their spouse and kids without needing to specify their email addresses. Because of the underlying architecture, this turned out to be extraordinarily hard to accomplish, at least while preserving the ability to sign up other users with an email address.
This turns out to be a question of options. Option 1: have users enter a dummy email address. Option 2: Make a customized version of the module that attaches user profiles to the main account, but no longer allows anonymous users to sign up, or for one user to sign up another user. Option 3: pour several thousand dollars more into rewriting the module to make it work for both.
There's not a good answer for this one, unfortunately. If what you want is there and working the way you want it, lucky for you. If not, lucky for Freelock, if you have enough budget to get the job done!
2. My site constantly tells me to apply security updates! It must be insecure.
Not necessarily. The Drupal security team does a fantastic job of identifying issues that could lead to your site getting taken over by bad guys -- but the vast majority of them are very hard to exploit and usually take a series of attacks to break through. In fact, most of them depend on an attacker getting your password or the password of some other user with elevated permissions, and then they can attack the site to gain more administrative access than your account already has.
But the real answer is, all programs that come near the Internet need to be maintained, need to be updated as vulnerabilities are found. And for programs that run on the Internet itself, this is even more important because your site might be used to attack thousands or millions of others.
We don't recommend automatically applying updates unless your site is small and doesn't get much traffic -- too much can go wrong. If your site is big and busy, well, those are challenges you want to have, and we're here to help make updates more reliable, less likely to take you offline. And, of course, you're going to be dealing with upgrade issues no matter what platform you choose.
1. Drupal developers are expensive!
At least, experienced, good ones are. If you only consider the hourly rate.
But if you consider how much can get done for your budget, and how much extra value you gain by having a huge amount of control over the information in your site, it might not be so expensive.
Again, you do need to consider what it is you're trying to do with the site. If you're just going to put up 5 pages and not change them for the next 5 years, paying somebody to do the appropriate security maintenance is going to be expensive.
But if you're going to have an information-rich, living site, you'll be hard pressed to find a platform that is flexible enough to start relatively small and grow with your needs to the same degree. Start out with a blog, add product reviews, add a store, add affiliates, add social media, add digital downloads, set up membership subscriptions, add event registrations, show nearby upcoming events on a map, add private groups, import data from other systems -- Drupal can do it all, with one piece bolted on at a time. Unlike other systems, these new items get deeply integrated into your existing site, not just skinned to look the same. This can all be done on an incremental basis over time -- if it's planned for, if your developers don't take shortcuts that box you into a corner, if your developers leverage the power modules with a future instead of picking dead-end, abandoned, one-off modules with only a sordid past.
Not all Drupal developers are equal. Not all developers are equal. Successful projects may cost more than failed ones -- but they also may become the cornerstone of your business and pay back your investment many dozens of times over.
The crazy thing about Drupal is that often what people think should be a big, expensive, difficult problem to solve turns out to be a solved problem, and can be deployed in an hour or two. Meanwhile what should be a simple tweak is maddenly complicated and takes far longer than you might think.
Before you give up on Drupal, perhaps you should talk to other Drupal developers? It might not be a problem with Drupal you're hitting -- it might just be a problem with your developer.
I'm sure I missed a bunch of reasons people shudder when they hear Drupal. I'm going to write another post that covers what we consider to be the technical, legitimate developer concerns about using Drupal, but meanwhile I'd like to hear if I missed the single biggest reason you won't consider Drupal for your next project, as a non-developer who feels burned by a project gone awry.
Please leave a comment below, and check back in a few days -- all comments are currently moderated due to a lot of spam, but we approve non-spam comments a couple times a week.