Home » Php » php – What are some of Drupal's shortcomings?

php – What are some of Drupal's shortcomings?

Posted by: admin April 23, 2020 Leave a comment


Drupal is very much a “Do Everything” CMS. There are modules that allow you to add almost any functionality, which is great. However, it feels like a lot of the features (v5 and v6) seem scattered around and unintuitive for the user. As a developer, I’m left with the feeling of having patched a site together using bubble gum and string.

For example, to add text to the default search box (that disappears when clicked), you have to either add some jQuery code OR override the theme. I’ve also found the menu system more complicated than it should be.

Am I the only one with this opinion? What things (if any) would you change about Drupal’s core?

How to&Answers:

The lack of true object oriented design means that you frequently have to rely on other developers’ foresight to leave “hook” functions to let you alter a certain behavior.

Using Drupal 5 I’ve also run in to situations where the only way to complete a relatively simple design change is to patch Drupal itself (and then be sure to reapply patches with each new official Drupal release). But, to be fair, you should have seen how bad it was in Drupal 4.

I’m also annoyed that when I take the time to identify a bug or quirk in the current production version of Drupal, I submit a patch, and the patch is never committed because, basically only security bugs get fixed in the current stable release.


To me, the biggest shortcoming of Drupal is that large portions of a live Drupal site are stored in the database. Since there’s no automated way to migrate content or configuration between systems, rolling out changes to a live site must either be done manually or dealt with by excessively complicated code.


One of Drupal’s biggest shortcomings is that it dances on the line between a turnkey tool for nonprogrammer site builders, and a framework for developers building complex webapps. It has some cool stuff to offer both groups, but the concessions to one crowd always tend to trip up the other.

The growing trend in the Drupal community is to explicitly build developer APIs, then layer administration UI and end-user UI on top of the APIs. This is a good thing, but there’s also still a lot of legacy architecture. The project turned 8 years old this week, and every site requires a mix of modules that are evolving at different paces.

If someone hasn’t already built a module that does what you want, effectively leveraging the system without hacking core code requires grokking a lot of different internal APIs, a lot of unique-to-drupal data structures, and studying up on some occasionally funky workflows. A lot of terribly bad and impossible to maintain sites are floating around in the wake of people who needed to do tricky stuff and didn’t have the expertise (or the time) to research the “right” way to do things.

(Disclaimer: I just co-authored a couple of chapters for a book about Drupal, and I do Drupal work full-time, so I’m about as far from ‘unbiased’ as you can get. But I do like to think that I keep perspective. I heart Django, too.)


Drupal will get you 80% of the way there out of the box, but that last 20% will take months and months.


Drupal is an impressive system. It’s surprisingly small for all it does, and it’s module system is extremely powerful. But as Eli said, a lot of your tasks are going to rely on other developers doing something in a particular way.

There’s a debate within the Drupal community over it’s design. Drupal was around before PHP’s OOP features were strong, but now that they are, there’s frequent discussion about changing the system to use object-oriented data structures. Depending on your tastes, this could be a downside to you as a developer. I’m of two minds about it myself.

The system can also seem to be very “magical” to newcomers, in that somehow it does all this crazy stuff with little explanation. “I only just defined a function, how the deuce does Drupal know how to call it?!”

However, I must say that in general I’m a big fan of Drupal. It’s a good system that gets loads better with each major version. I for one can’t wait for 7.


Drupal is good to get started but you spend more time ‘undoing’ than actually getting things done. This has been changing especially with the release of Drupal 6 and to be fair it’s more apparent in contributed modules.

Managing migrations is also a problem as Sean said. I still don’t know of a good method of moving changes from a dev site to a live one.

I am not sure there is anything I would change in the current core and most of the deficiencies are being worked on. Image management needs work, the default admin interface is a little cluttered making more complicated layouts without getting views/panels, etc. involved could use some work.


i find it awfully complex. as a php developer im tearing my hair out on a daily basis over issues that have nothing to do with php but with drupal itself. how / why / when does it do X? its a big beast that needs to be tamed. documentation is limited to a few very good guides, a whole lot of shitty ones, and even more useless forums threads that always seem to pop up in google.

usability on the backend is crap. a custom theme will also alter the layout of the “admin” part of the package which can be extremely frustrating and results in less than pretty layouts.

if you’re working with html slicers, its impossible to use html that has not been created specifically for drupal. it pretty much forces you to use drupal-html, with lots of divs, 5 verbose classes per div, etc. by nature, html/css guys can not be expected to know drupal at this level.

i dont like the way it relies on filenames (10 words long, with very subtle differences between them) to build a theme.

having said that, some of the stuff it can do is very cool and saves you days and days of custom php development


Drupal gives powerful tools to Non programmers ,They can easily build up a full featured site with less time. But the problem is that learning curve is too high for Drupal.

If a person is new to drupal and want to make something customized it will take lot of time if he wants to do it in proper way. There are lot of ways to do a single thing in drupal,Finding out which is he best or proper for a new comer is a head ache.


I think it’s high learning curve is the only shortcoming as most companies struggle finding good Drupal talent. http://drupalize.me/ and http://buildamodule.com/ are doing very good job to reduce this high learning curve.


I find that the default admin interface isn’t very intuitive compared to other cms’ like modx or joomla/mambo


It’s written in PHP4. This will change as of version 7. You can write your own modules in php5 of course. As a seasoned Drupal developer and I find my resume has suffered due to my limited exposure to php5.

It’s not the best for running services like SOAP. Calling the whole Drupal stack to provide a web service is too much of a performance penalty. The services modules are still in development.

No database transaction support. This becomes an issue when you scale it up to extreme loads.

It would be good to run tests from the command line. This was possible with simpletest 1.x but the current version doesn’t support it very well. Simpletest is not mature enough. A clean Drupal install can fail tests. Some of the default included tests force you to use content types and modules you may not need and you can’t disable these without hacking the simpletest module.


It has a seemingly bad security record: http://secunia.com/advisories/search/?search=Drupal