Drupal development and use by professional programmers .. are there specific pitfalls or advantages?

Question

Background: Long ago Microsoft Access gained a lot of popularity because you could build pretty powerful desktop database applications with point-and-click ease. It seems like Drupal is now doing the same thing, except for the web.

This is definitely good in some aspects, but it seems to have some drawbacks as well. From the perspective of someone with a few years of Web development experience and programming experience, it seems like Drupal has some quirks that take some getting used to.

Examples:

• OOP and Namespaces: Drupal pretty much re-invents Object Oriented programming with its own internal API, and there does not seem to be much impetus to change that, even though PHP has added built-in support for (its own flavor of) OOP. See Drupal on OOP.

• It works for me ...: Many contrib modules seem to be plagued by use cases that were not initially anticipated by the original author(s). The common response is "well, at least it works for me". This is understandable when developers write something first to solve their own particular issues, and then only later adapt it for others (if funding, personal preferences, and time allow). The problem is "good enough for me" is an incremental approach that does not work well with large-scale development. The result is a combination of solutions that feel "duct taped" together.

• Duplicated Standards: Drupal seems to also re-invent existing technologies and standards even in cases where there does not seem to be a stylistic or strategic benefit in doing so. For example: 1) New .info files; 2) Deployment tools; 3) Re-creation of PHP language features; 4) Re-creation of code and functionality from established open-source libraries.

(The newly-invented .info files (used in configs), are used instead of already built-in INI file format of PHP, or the already-used and published YAML, for cases where INI is not powerful enough. Another example, in contrib modules at least, you can find lots of hand-made regex hacks used to parse HTML, instead of already-developed full-fledged HTML parsers. Another example, Drush appears instead of any already-known build language out there (EDIT: the build language link is not a good one, I meant to emphasize higher-level tools like Rake, Capistrano, Ant, Maven and others, I am assuming Drush is the closest thing.))

• Unit testing: Drupal does not seem to have a strong support for unit testing. Combined with the other factors above, this makes for a challenging environment for those who want to have comprehensive code coverage, especially for cases where Drupal is being used in a work environment with the potential for lots of apps proliferating.

Question: If you have some Drupal experience, and also some programming experience (especially if it is in other languages in addition to PHP, with native support for OOP), what are some specific pitfalls or even advantages that you have encountered?

Answer 1

A/B splittesting: none

IMHO the set drupal core modules is too small, so the frequent bugfix updates breaks trivial things like url rewrite, meta description and lightbox, since these things are outside the core. Causing much trouble.

Answer 2

In answer to your question. As an OOP programmer coming to Drupal, don't mistake Drupal for OOP it is different, and the areas which seem familiar probably don't work in the way you expect from an OOP background.

For example, you could think of modules as an instance of an abstract module class, which can implement various methods. But they are not, and thinking they might be will confuse the heck out of you.

It comes down to a question of focus. OOP is designed to solve the problem domain of everything which means that it has to be flexible enough to do just about anything.

Drupal is designed to be a content management framework. This gives it a much tighter focus, so the design decisions are based around that.

Answer 3

IMHO, Drupal is heading down the same road as things like ZOPE or PLONE in the Python world, or SAP in the enterprise world. It is becoming a little world unto itself and a professional programmer risks being sucked in until they are only seen as a Drupal person, not a general purpose developer.

Some people may like that and certainly in the SAP and ZOPE worlds, people make a career out of working with that one tool.

Answer 4

I think it's a bad example to compare drush with build language, from your wiki link:

Build automation involves scripting or automating the process of compiling computer source code into binary code.

This is not what drush can do or is used for. It's a simple util tool to preform things that developers do a lot like downloading a module, enabling/disabling it, running sql on your drupal db and other nice things. Like they state themselves:

drush is a command line shell and Unix scripting interface for Drupal, a veritable Swiss Army knife designed to make life easier for those of us who spend some of our working hours hacking away at the command prompt.

But even with this poor example, it's true that Drupal reinvents a lot of things instead of using other known solutions out there.

One of the things that you have to get down, when developing with drupal is the naming convention. Drupal doesn't use namespacing but instead a special naming convention. This is something that probably wont change anytime soon. The problem with this is, that until you know how this conveention work, misnaming functions can be a cause to a lot of wondering and confusion as to why this isn't working as expected.

Drupal uses hooks, this is a part of the special drupal naming convention. The way drupal think, it not to subclass things to make what you want, but instead have one version, that any one at anytime can change and tweak to their bidding. This can sometime cause some funny errors if both module A and modeule B wants to make changes in the same flow of code. There are also different levels of overiding, some taking precedence over others, and some being performed later that others. In most cases this works just great, but around central modules like node, cck, views and others, this can become a minefield, where you have to take care if you want to change things without messing things up along the way.

Answer 5

OOP: Drupal well predates the prominence of PHP 5, when OOP in PHP really became up to par. In fact, the upcoming Drupal 7 will be the first release of Drupal which requires at least PHP 5.2. So there is a bit of a legacy in the API which sidesteps the OOP issue. On the other hand, newer structures such as the new database API which will be introduced in D7 and the automated testing system use PHP 5's OOP features quite extensively. It's possible that this OOPness will spread to the older parts of core, but it certainly ain't gonna happen overnight.

If you're coming from languages with historically stronger OOP support like Ruby, or from post-PHP 5 PHP frameworks with more ingrained OOP support like CakePHP or Firestarter, I can see how the relative dearth of OOP in Drupal can be shocking and disturbing. On the other hand, I think Drupal is engineered well enough that it doesn't really suffer for lack of it, once you wrap your head around things.

Duplicated standards: I agree with you there - once it became apparent that standard INI files would not do all that we needed them to, we should have switched to another, well-established standard (preferably one that had another built-in, low-level parser in PHP - so not YAML) instead of adding our own extensions to the INI "standard." But for what it's worth, PHP 5.3's built-in INI parsing feature upgrades will make much of Drupal's INI parsing features redundant.

Unit testing: Drupal 7 incorporates a rather thorough testing system in core, and many of those features are available as contributed (non-core) modules in D6. I've heard pedantic people say that it's not truly unit testing and is instead process testing or something like that, but the fact remains that it's an automated testing system, and the drastic improvement in quality it has afforded the Drupal project as well as contributed modules is already clearly apparent.

As for Drush, as others have mentioned, it's not like a build system at all - it's a script which allows us to do some common Drupal tasks, such as enabling modules or forcing a cron task run, through the command line instead of the web browser.

Answer 6

I really can't stand framework's like Drupal, Joomla and Wordpress. I laugh in the face of amateur programming nubs that think that three years of experience developing in Drupal gives them any sort of real edge in a normal programming world where things such as good OO code exists. A framework that follows industry standards and strong design patterns can not be beaten because a knowledgeable programmer from any walk of life should be able to come in to a project and have some since of how everything is done. That is certainly something you can not and will not find in frameworks like Drupal.