Some other people who also seem to think that Drupal6, Drupal7 (and still Drupal8) is not coded very well and is not OO enough

HOT TIP: this content is flagged as highly recommended !

From 7 reasons to switch from Drupal to Yii (Eric Kennedy) [Webel: and please note I am not suggesting you switch from Drupal, I am suggesting fixing Drupal by using true OOP ]:

If Drupal is a framework, only Rube Goldberg could love it


Drupal's field API/content construction kit (CCK) will drive you crazy, and it's part of Drupal 7 core. Why use $node->ip when you can use $node-> field_ip[0]['value']. And if you decide that two content types should both have a text field of the same name, CCK will put that in a table of its own (content_field_ip) with delightful column names (field_ip_value). Sure, Drupal can untangle that mess when a full node is loaded, but it isn't pretty to look at in the database.


Drupal has PHP 4 baggage. Once I decided to consider PHP frameworks, I quickly realized I wanted only a 100% strict PHP 5 OOP framework.

You don't see many people arguing that Drupal's procedural "hooks" approach is superior to OOP.

Dr Darren remarks:

'Unfortunately Eric, I do still read of 'many people arguing that Drupal's procedural "hooks" approach is superior to OOP', as often as not on; they are hooked on old habits (including structured arrays without intelligence and defined only through documented convention), they are of course utterly wrong, and they are, quite simply, ignorant of the advantages of true object-orientation and the design patterns only possible through OOP.'


Simon (not verified) on Wed, 01/18/2012 - 10:34

It is a badly written mess, not just in terms of code, but the actual mechanics of many aspects of it, for instance implementing the design, all our designers who are quite at home with templates / HTML, could not stand the bitty, over complex, all-over-the-place nature of Drupal.

From Drupal Sucks: Robozen (2009):

Gripe #3: Drupal’s Design is Piss-Poor

Drupal has a history of security vulnerabilities and is written in ugly spaghetti code (guys, have you heard of classes? Objects? Inheritance? ..).

lambert on February 4, 2012 at 20:57 said:

Here’s a very basic example of why Drupal was designed by people who either a) are totally incompetent or b) want to make sure only they can maintain their product. ..

Drupal uses mashed together method names that are whole sentences instead of using an OO approach. This is a VERY poor practice. Objects should provide context for calls invoked on them, instead of using a cluttered namespace approach where the user has to memorize a specific convention for how oversized variable names are created and pass in an object every time. in addition to being error prone this creates much more overhead on a machine level, because you end up with things like gigantic symbol tables that have to be searched over and over again for the same three calls, and your current stack frame will have a shitload of extra variables instead of pushing a new stack frame with less overhead for use with a different execution context like, say, an object.

And this OOP in Drupal 7: Cool module in practice (2014) from Pedro Rocha is music to my Enterprise Java and Design Patterns ears:

Drupal community is talking a lot about OOP in the last months, because Drupal 8 is bringing sanity to developers, but OOP is not being used on Drupal 7 only because it's not being used. Sounds weird, but it is true: the tools are already here to help us develop modules that are easier to understand, contribute and maintain.

I came in a moment that i thought "wow, my Drupal code could really become more organized", and this was because i didn't agree to have .module and .inc files with dozens of functions that, in most of the time, doesn't relate to each other: they were just there, everyone in the same bag, because it's a common practive among contrib modules. Maybe an file, but nothing more than this.

Yes, Drupal was created in a PHP without OO, but nothing stops us from use these resources in the last years, since PHP 5, so it's just a question of "bad practice". For me, as i worked with J2EE for 3 year, before jumping into Drupal, in 2010, the last years i fell that my code was becoming worst, in terms of reuse and readability.

Entity module was a great friend in this jorney and when i knew X Autoload(that makes Drupal 7 understand PSR-0 - already bundled with Drupal 8), an idea came to mind: OOPify Drupal. And i'm not talking about create classes and need to register in some kind of registry: i wanna create a class and it simply works. Clear the cache is all i should need.

While the OOE = Object Oriented Examples = One Of Each module featured on this site is a far more comprehensive implementation (and with graphical UML support) than Pedro's promising Cool Module stubs, it shows that great minds think alike.

And it shows once again that "it aint necessarily so" when dealing with Drupal religion, which BTW is what makes me, Dr Darren of Webel, a "Drupal heretic". Once you really know OOP and Design Patterns you can't help but hunger for them; so working with much of Drupal7's module development "API" is still like being very thirsty and starving.

But we recall that: Dr Darren says: 'Just because I (constructively) criticise some aspects of Drupal core and the module development API does not mean I don't appreciate Drupal and what one can do with it'. And many of us, enticed by the good things one can do with Drupal as a CMS (i.e., simply setting up a web site and adding content), have a massive professional, financial, cultural, and intellectual investment in it. So we "pray" (we, at least as much as a heretic can), than Drupal7 will drop hook-and-structured-array-key-religion and adopt decent Object Oriented Programming (OOP), as PHP DOES efficiently support.

"Oh no ! They finallly changed Drupal to real OO and my site now runs a tiny, tiny bit slower (sometimes), on some (only) pages. Damn those OO advocates, even if they did manage to maintain and develop new modules MASSIVELY FASTER AND EASIER WITH LESS PAIN. Damn heretics ! They don't respect the performance of .. servers .. machines .. robots."

Well ok, nobody actually said that (yet).

Some more valid concerns expressed in this preface to a nice guide to Drupal 7 Render Array snippets

Drupal 7 contains some incredibly powerful functionality in things like Render Arrays, Entity and Field APIs, etc. However, the actual details of these things are next to impossible to find. Especially difficult are specific examples and lists of available options. The more time I spend developing in Drupal 7, the more time I spend digging through code that I've already written trying to find a snippet that took me hours to find or figure out the first time I used it. I'm starting a short series of posts to document these items so I can find them more quickly.

Such problems ARE largely addressed easily by the OOE = Object Oriented Examples = One Of Each tutorial module, which encapsulates documentation in object-oriented getters and setters, near where it is used. See for example Video: Demonstration of NetBeans IDE prompting on an OOE IMenuItem encapsulation of a Drupal menu item in object-oriented PHP {MediaFront} and Screenshot: NetBeans IDE prompting on an OOE IMenuItem encapsulating a Drupal7 menu item.

The following from Drupal Module Hooks by Alan Storm is not directly critical of the choices the Drupal core developers have made over the ages, but it is an interesting implicit acknowledgement of just what a royal pain in the !$%@* Drupal's so-called Hooks API is for anybody who is used to real object-orientation and elegant Design Patterns:

'Drupal’s module system implements a Hook system. This system resembles class based observer/listener patterns you may be familiar with, but no classes or objects are used. Instead, the system is implemented entirely with PHP’s variable function features. This may seem weird if you’re just coming into PHP development, but remember Drupal’s history.

Drupal is over a decade old, its first versions surfacing in the open source community sometime around 2001. PHP was a popular language at the time, but PHP 4 was the new version. Objects based on classes were not references, which means traditional OOP patterns weren’t readily availability. Even once PHP 5 broke onto the scene, it’s class/object system was noticeably slower that solutions implemented using only functions. Code performance speed approaches deity like status in the Drupal community, so rather than play with the cards PHP dealt them, Drupal developers chose to implement their own system.'

My time as a coder is more important than a server's. See also In PHP(5.3) arrays are not significantly faster than objects (if at all).

Alan goes on to say:

Also, it’s more fun to roll your own!

Fun ? Fun for whom. And it depends an awful lot on what is being rolled, why, and how. I mean even if one can somehow justify Drupal7 not having moved to decent OO, nobody can seriously tell me - used to graphical software engineering with Unified Modeling Language (UML) in combination with Enterprise Java - that Drupal hooks are fun, or that having to remember or constantly lookup badly documented "by convention" structured array keys (ahem, the Drupal "API") is fun. Drupal core - up to and including version 7 - has (badly) attempted to mimic and reproduce parts (only) of an object-oriented language, and PHP has been OO long enough for that excuse not to wash any more.

More from Alan Storm:

This sort of decision is one of the many things that programmers like to argue about. My suggestion to you is accept that Drupal made the decision, and learn to use the systems they’ve provided. If you can’t do that, and you’re bent out of shape about it, pick another system. If you can’t pick another system and hate the one you’re being forced to you, meditate on why you’re working where you are.'

Or, instead of "accepting the decision", Drupal can be fixed once and for all, which is what the OOE = Object Oriented Examples = One Of Each bridge module DOES finally do. And it even does it with graphical Unified Modeling Language (UML) support. It is, like Design Patterns, quite simply, superior Information Technology.

Dr Darren Kelly (Drupal heretic), Webel IT Australia

Visit also