Wednesday, April 2, 2014

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

The following was originally posted to StackOverflow in 2009. ( The post was unfortunately deleted by some StackOverflow users. It is reproduced here for historical purposes. It was the earliest (apparently the first) public proposal to advocate the use of YAML in Drupal, as a basis for enhancing the professionalism, maintainability, and flexibility of the product. After some resistance by the Drupal community, YAML was recognized and adopted for use in Drupal version 8.

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.
  • 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 JSON or YAML, for cases where INI is not powerful enough. Another example, in contrib modules at least, you can find lots of hand-made regexes 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?
  • Update: (Jul 2, 2013) Drupal 8 is slated to use YAML instead of the Drupal-specific .info file format (
  • Update: (Jul 3, 2013) Drupal 8 is slated to use the SYMFONY framework which includes native support for Namespaces and Object Orientation.

what were the examples of duplicate standards? –  Jeremy French Nov 11 '09 at 15:36
added, sorry for the omission –  dreftymac Nov 11 '09 at 15:59   
thanks a lot for the feedback ... regarding "build language" the reference includes higher-level tools as well, not just those for compiling to binaries. (See e.g., tools like rake, capistrano, Ant) –  dreftymac Nov 11 '09 at 18:27,15522.0.html Here is a link to a review from someone who asserts 25 years of software development experience. –  dreftymac Mar 25 '10 at 19:43   
show 2 more comments

closed on StackOverflow Apr 8 '13 at 7:02

deleted from StackOverflow Feb 27 at 22:05

5 Answers

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.
deleted Feb 27 at 22:05
The issue with the unit testing is not the system itself but the way it is being used. You can use simpletest for unit testing, but in the cases I have seen it is used for system testing (and integration testing). – Jeremy French Nov 12 '09 at 6:28
Thanks for balancing out things with some favorable viewpoints. The no-YAML point still eludes me, though, since GPL'd PHP 4.x-compatible YAML libraries already exist and are in production use; ready to be added into Drupal. Waiting for a PHP-native variant, or a suitable re-invention seems as odd as choosing to re-invent a Drupal-specific or PHP-specific variant of jQuery. –  dreftymac Nov 12 '09 at 16:46   
Personally speaking, I'm of the belief that we should try to use low-level stuff as much as possible, especially when it comes to relatively slow stuff like parsing config files. It's faster, and it reduces the amount of code Drupal core has to lug around and all that implies (fewer bugs, smaller attack surface). Also, before Drupal 5 (I think), Drupal just used PHP's standard INI parsing, so when it was decided that .info files would need to be more elaborate, I suppose the choice was made to stick close to what developers were already familiar with rather than go with something radically… –  Garrett Albright Nov 12 '09 at 18:15
…different, like YAML, so that line of thought may have also affected the decision to roll our own INI parser. All that being said, I personally dislike YAML, and would campaign against any attempt to introduce it into Drupal core, both because of my aforementioned preference for fast low-level parsers and my personal distaste; but I guess that's another discussion. –  Garrett Albright Nov 12 '09 at 18:18
That makes sense. Ironically, I hated YAML at first also, but I also had to decide between it or re-invention -- but then I use Ruby, Perl and Python very regularly, which are a lot more YAML-friendly ecosystems. Nevertheless, "I simply dislike it" is always a direct and honest answer that stands on its own merit. Even re-invention is commendable when it's done by someone who has made a good-faith effort to understand and evaluate the alternatives. Thanks a lot for some excellent viewpoints and the additional insight. – dreftymac Nov 13 '09 at 2:20   
comments disabled on deleted / locked posts

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.
deleted Feb 27 at 22:05
comments disabled on deleted / locked posts

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.
deleted Feb 27 at 22:05
Good observation, although I was thinking something even simpler, such as having namespaces and classes to distinguish method signatures, so you don't have collisions by modules that use the same function names. [e.g., the difference between Console.print() and PDFtoXML.print() ] –  dreftymac Nov 11 '09 at 15:57   
@dreftymac: Drupal addresses the problem of naming collisions via coding convention. Module function names should always be prefixed with the modules name, so basically every module 'defines' its own 'namespace'. Works OK so far, but gets pretty annoying for modules with longer names, as the resulting function names get hard to read. –  Henrik Opel Nov 11 '09 at 22:10
I understand, but then I guess you can say all programming languages avoid naming collisions via coding convention. That's basically what Namespaces and Classes are for. The problem arises when these fundamental properties of the language are decided upon and derived outside of the specification of the core language itself (in this case PHP). Anyway, the point is well taken. Drupal was already mature before PHP claimed to support OOP, so the die was already cast. –  dreftymac Nov 13 '09 at 2:24   
comments disabled on deleted / locked posts

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.
deleted Feb 27 at 22:05
But what if I don't like Lightbox and want to use Thickbox or something else instead? Or what if I'm a developer and I want to add new features to Lightbox without waiting for another major Drupal release to do so? There's actually a movement in the Drupal coder community called smallcore pushing to make Drupal's core even smaller and to have even fewer built-in modules, and to use Drupal's install profile features to offer packages with lots of modules included for those who want more of an out-of-the-box CMS and less of a framework. –  Garrett Albright Nov 11 '09 at 19:19
With some sane default packages I think a most people could be satisfied out of the box. No need to spend time on getting urlrewrite working, time on getting meta description working, etc. If they make the core smaller then perhaps they should consider making distributions with preinstalled packages, so that users have a good starting point. –  neoneye Nov 11 '09 at 19:50
comments disabled on deleted / locked posts

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.
deleted Feb 27 at 22:05
Tools like Capistrano are more likely to make use of Drush to get the job done, being higher up the stack. The recent Drush Make project is more of an overlap. –  Grayside Nov 13 '09 at 5:12