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.
And finally:
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.
Your turn
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.
Industry
Higher barrier to entry
This touches on a lot of the above, but I think it's worth spelling out in its own right.
In short, the barrier to entry for Drupal is higher than other options- it takes more planning to do it right, frequently takes more of an up-front investment, often takes more client involvement, and- especially if you're working with an inexperienced developer- can take substantially longer to implement.
There is, however, a trade off. Where you can have a static HTML or WP site whipped up and ready for traffic in roughly no time flat, the capabilities of those options are also correspondingly much more limited. For users who don't need or don't understand that additional capability and see only the difference in price and ease-of-setup, that might seem to be a trade worth making.
It really depends on what you want out of your site and whether you think there's value in having a site that can expand and adapt to meet your needs as your organization grows and changes.
I love Drupal. I see its
I love Drupal. I see its flaws and I see its strengths, and I use it. A lot. If Drupal isn't quite 'there' yet for your needs... don't despair. It might not be ready in time for your current deadline, but that's only because it's busy meeting a few dozen others. If you'd like, stick around. Dip your toe in. A few months down the line, you might be able to make it work for you, too.
All the drupal developers I
All the drupal developers I have come across are too much money for me, so I don't think I will wait around to see if things change.
Andy
I played on WordPress and on
I played on WordPress and on drupal.Wordpress seems to be easy as you said.But doing a project on drupal is very interesting.But learning drupal somehow a bit difficult to me.I am trying .But the way they( drupal ) used is nice.Doing a hard work it will come to our control.
And your article is very correct it is very difficult for client to do anything
Please excuse if my writing has anything wrong because my English is not well
Thanks anyway
Re: #4 (as well as #3 & #5) -
Re: #4 (as well as #3 & #5) - "Design changes usually take a developer or skilled themer to make -- but everything else you should be able to change yourself." But it's too complicated and takes custom code.
I find that a lot of people, probably most in fact, don't and often can't make the distinction between content and design. They've spent years fiddling around with layouts and fonts and images in their office suite software and simply expect their web software to work the same way. So it surprises them that they need a skilled developer to make that change, or that their graphic designer, who knows a little HTML, can't do it.
Add to that the fact that there is still no good browser-side WYSIWYG editor for web content. Some are better than others, but even the best are still about 20 years behind WYSIWYG editors in desktop software, and not at all oriented towards content management with structured content.
Then you add to that the fact that we're talking about a content management system, not a page management system, it causes even more confusion and hapless customers. They see a page and think of it as a document, as if it were a single file. Relatively few people seem to actually think in terms of structured content. They have no metadata for their content and all of their data is in Excel files, prettily-formatted for printing, but nearly useless for importing. Explaining that people need to think about content first often gets blank stares or worse.
And it can be really hard to grasp that different parts of a page need to be modified in totally different ways (and how many ways there are!). (Adding images in the WYSIWYG body area is different than in an imagefield which is different from an image in the theme. This chunk of content has the Nodequeue interface, but that has the Views interface, and this one's a block; this is a core setting, that's a setting in this module, this is sitewide, that only affects this page, etc.)
I find that there are major barriers to a non-techy feeling that they are 'able to change everything else yourself', even on fairly simple sites (and it approaches impossible on complex ones). Educating the customer is critical, and very difficult because even the basic concepts (content vs design) are so foreign.
This was a good helpful tip.
This was a good helpful tip. Not all Drupal developers are equal. Not all developers are equal. Successful projects may cost more than failed ones. You can learn a lot from failed projects and see what you need to do better and how to hire better developers.
Add new comment