Discussion about problems with Drupal

Thanks John,

I only have a few minutes before needing to take off, so I'll answer a few things quick and get back to ya with more as soon as possible. If my tone feels terse or defensive, please don't take it that way... I'm typing this a bit too fast :P I just hope to help give you another perspective based on my own experience.

Regarding point 1... that's not true in my experience, unless the client is using the admin account for day to day use (which they should definitely not). Drupal has very fine-grained permissions and multiple tiered roles, and when configured correctly, hide almost all complexity from the client's "limited" day to day user account. In fact it can be made so simple that the client has to deal with little more than choosing what type of content they want to add. When they want to edit it, they can click "Edit" on the page itself, or browse the content backend listing. In contrast, the WordPress admin, while definitely easier when compared with the full Drupal super admin view, has substantially more unnecessary functionality exposed to the client, which they have no need to see and there is no way to hide from them. Personally I prefer Drupal's approach where I can choose how much or how little to expose to the client.

Point 1a... this is definitely true. Drupal 7 is at least somewhat more complex in my experience than 6, particularly in regard to the new fields in core and Entities (which are extremely cool, but at the same time, different from "how it used to be done", so has required me to relearn some things). That is something the Drupal community has already acknowledged and is working hard to remedy in Drupal 8. By no means is this an overwhelming level of difficulty though for a competent web developer (I know "some" PHP and manage to make quite amazing things with Drupal without too much trouble).

Point 2... not quite following. I'll reread this part later and see if there's any advice I can offer.

Point 3... if there's a security issue, I want to know about it and be able to apply the necessary updates. Drupal takes security seriously, and a team of security volunteers even do their best to audit as many 3rd party modules and themes as possible (not just core). If another CMS releases less security fixes, I don't believe that automatically means it is more secure. It may mean they aren't looking as hard, or reporting as actively/timely about them. In the web development shops I work with, who use Drupal, WordPress, Joomla, as well as other systems, WordPress and Joomla have a far worse reputation so far as those sites "getting hacked". So far as time needed to apply Drupal module updates... yes WordPress's method through the UI is quite nice, however with a few minutes of practice, Drupal's Drush command line program makes it easy to batch update one (or all) modules on a site with a single short command. I manage updates for quite a few client sites, and it takes only a few minutes to apply updates to each one. Drupal also automatically keeps track of updates as they become necessary, and notifies me through email about all the sites needing important updates.

Well, got to go... hope this helps a bit initially, and I'll try to get back with more soon :)

Hi John,

I gave some more thought to point 2.

If I understand correctly, they are referring to the default behavior where, on a content creation page (e.g. adding a Page node), when you go to the Menu settings for the node and click on the "Parent item" drop down, you are presented with a representation (in the select field) of the full menu structure. In Drupal 6 and earlier, this even lists ALL menu items of ALL menus. I agree this is bad. With a very "full" menu, or worse many large menus, this is extremely unwieldy. You can choose an initial/default menu for the select list to start at, but it can still be tricky. It's better (but not perfect) in Drupal 7 core... more on that in a moment.

However, there are some tricks to make this better.

In Drupal 6, you should get the Menu Settings per Content Type module. This allows you to limit the menus offered on a given content type's node creation page to only those that are relevant to that use case (for instance, for your site's "Pages" it's highly unlikely on most sites you'd want to add them to the Navigation menu or to an Administration menu)... in most cases you'd only ever want it in the Main menu (which in Drupal 6 are the "Primary Links"). In Drupal 7 this feature has been added to core, so you don't need this module.

In both Drupal 6 and 7, to ease the situation when you have one or more large menus to deal with, the helper module you need to make your life easier is called Hierarchical Select. This module uses javascript to break apart the levels of a select input (such as the multiple levels you can have for a menu or in a taxonomy). This permits you to select the first level you're after, then a new drop-down appears next to it which lets you choose from the child elements, and so on. Check out a demo.

Some of "getting along with Drupal" is knowing about some key modules and various tricks to work around usability issues like this (and very often the good modules/tricks get merged into the next major version of Drupal). This is really the case with any CMS though... despite being very comfortable working in a variety of CMS's, I definitely feel a bit "unsteady" with any system until I've worked with it a while, collided with its various idiosyncrasies, and googled for solutions. I run into the same thing with WordPress for instance... often I run into an issue where I say to myself "now that's odd, I could do this particular thing in a split second with Drupal, or Drupal's solution to Issue xyz is clearly more flexible or elegant", and I have to go hit the forums to learn how that community deals with that particular sort of issue. And likewise, while developing for WordPress, now and then I see a feature or usability tweak and say "man! why can't Drupal's version of this work this way?". So each have their strengths and weaknesses. I don't have experience with ModX, but I'm absolutely sure the same will be a universal truth there as well.

Hope this helps. I'll answer more remaining points when I can :)

Unlike other systems, while Drupal is definitely a CMS, it is also closer to a "framework" than most other systems. A common analogy is "lego blocks", which you can choose to assemble as your project's needs require. Like legos, you don't have anything very exciting with just a few blocks blocks alone, but when brought together... medieval castles, space ships, who knows! :) A lot of Drupal's functionality is broken up into smaller, easier to maintain pieces, which can be rearranged in a wide variety of ways to help you achieve exactly what you want to create, without requiring you to buy into how another developer envisioned the feature as a whole should work. It also creates reusable functionality that many modules can instantly make use of, instead of each and every module reinventing the wheel to do many of the same basic tasks. Websites are increasingly complex and powerful "applications" these days, and one size fits all plugins are not the way Drupal has decided to go in many cases.

This has some side effects. While definitely making Drupal more flexible/versatile, It also makes Drupal more complex to learn, and also increases the possibility of unforeseen effects on some of the modules that make use of theses sub-components. Hence the need to 1) read the release notes of module updates before installing them, 2) always backup the site files and database before any updates, 3) maintain a local copy of the site which you can install updates on and check for issues first (or if not, at least be ready to do a quick restore if a module update creates issues on your live site). In the real world I often end up doing the latter if the site is relatively small. I use Drush on every site without fail, and it makes backing up, updating, etc vastly easier and faster. If it's a large site with version control, big databases (some sites I work on have multi-GB databases and highly active communities... not so easy to quickly restore), then there's no way on earth I would apply any update to the live site without having tested it locally.

This would be the case no matter what CMS I'm using. While admittedly I'm not very familiar with it yet, Drupal over the past several years has also integrated an extensive testing system which anyone who wants to can make use of in their own workflows.

In point 4 it says "Updates seem to corrupt other parts of the site, even though they're not related." As mentioned above, often the components are definitely related, even spanning very different features/sections of a site. Part of a seasoned Drupal developer's job is understanding these relationships, and keeping in mind how they may affect various parts of the site. It's no different than how changes to the components of a lower-level framework might easily affect a wide variety of features on a site. If the parts breaking are definitely "not" related in some case, then no, they should not break any fully unrelated features on the site, and I can't say I've ever experienced anything of that sort.

Hope this helps :)