We are partially a Drupal web development shop (we like to use the right tool for the job), and we have done quite a bit of work using Drupal. These days the community is quickly becoming more and more commercialized by various companies each offering to solve a problem. And while this is not a bad thing, we often feel that many of the problems that are being solved are problems with Drupal itself in the way its design and development decisions are approached. As of version 8, we don’t see hopes of the problems addressed here improving.
Drupal has a massive problem with scalability. For example one of the problems with its design is hooks. Now hooks in theory sound like a great idea… however, in practice they are anything but. The reason for this is that because of hooks, every single piece of code must be loaded at each point. PHP has something called auto-loading, however Drupal can not, as of at least 6.0, take advantage of this. Instead, Drupal loads every bit of code on each page load. In order to prevent all of this code from being executed each time, Drupal caches much of the content in multiple cache tables. This works to an extent, but now you have tons of content cached and that cache has to managed by the developer or Drupal which becomes annoying and may cause edge cases that at times you should never have happened in the first place if your framework was better engineed.
In comparison many frameworks including Kohana allow you to only include the code which is necessary for whatever page is being generated. Using an HMVC architecture. Unfortunately, many other CMSes have similar problems, but it really comes through in Drupal; especially with choices like writing a wrapper over PDO — why one would do that still boggles the mind… I know why — but it would have made more sense to stop doing it rather than write a wrapper around PDO.
Everyone is an expert syndrome
Drupal has many so-called experts. Many of these non-developers bill out at $150.00 or more and Drupal sites are often complex beasts that may break or become confusing. Paying these guys often becomes a big problem for small businesses that employ Drupal sites. Instead of writing simple sites that are maintainable with a limited number of features, people are upsold on complex sites that are hard to maintain.
Is this the consultant’s fault or is it the fault of the business owner? I think the fault lies in both. Business people often don’t understand what they actually need, instead it’s easier to just throw the kitchen sink at the problem. The developers think that they are adding value by providing a boat load of features.
Ultimately, the problem is that neither understand the market nor the value that they are trying to create through the site. What is the point of a million features, if a few people visit your site every month to get your phone number? That’s the fact of the matter, most users are simply not that interested in everything available online. They will simply pick up the phone and call you when they need specific information.
Many Drupal developers are not computer scientists, instead there is a mish-mash of many different sorts of people that have ended up in the web development business. Unfortunately, many of these people don’t have the entire tool set to be called experts of any one field, much less a complex beast like Drupal. But yet they still consider themselves experts.
Lack of Talent
Another problem with Drupal is the fact that talent is difficult to find. This is a problem because it increases the price of everything, especially when combined with the everyone is an expert syndrome. Since the people that you do find may be self-proclaimed experts that actually don’t know very much about how Drupal really works. They might then go hire yet more people and now you’re dealing with management overhead alongside inexperienced developer(s). Just a word of warning, as not everyone is like this but — caveat emptor.
Drupal is a massive behemoth and unless you have a lot of cash to hire a real expert, we would recommend thinking twice before committing to Drupal for your next project that’s going to make millions but cost only thousands. This being said, we still do Drupal sites, but we try to mitigate the problems by limiting the scope of the project early on to stuff we actually know how to do. Further, we try to make use of pre-made components to increase the chances of success. We also try not to use Drupal and instead stick to WordPress if possible. Ultimately, you must use the right tool for the job, and in some cases Drupal makes sense but usually there is a price tag invovled.
And there you have it.