Thoughts on Drupal
I’m working with Drupal for the first time on a hobby project I’m doing with Seth Gottlieb . Adam Kalsey – Drupal ninja that he is – is advising us on the technical implementation, and he’s been a great help. Why Drupal? Because I didn’t know it, and figured I needed to. Seth and I, after all, had…
The author is working on a hobby project with Seth Gottlieb and Adam Kalsey, who is advising them on the technical implementation. The author appreciates Drupal’s flexibility, ability to scale, and the flexibility of its configuration options. They also note that Drupal is “casually” customizable, with the main method of customization being file- and function- naming conventions.
Generated by Azure AI on June 24, 2024I’m working with Drupal for the first time on a hobby project I’m doing with Seth Gottlieb (about which you’ll hear much more later…). Adam Kalsey – Drupal ninja that he is – is advising us on the technical implementation, and he’s been a great help.
Why Drupal? Because I didn’t know it, and figured I needed to. Seth and I, after all, had the discussion about how there are people like to feel smart and people that like to feel stupid. Learning Drupal has made me feel plenty stupid, and that’s exciting. And there’s no better time to feel stupid while learning than on a project you’re doing for yourself.
During the process of learning Drupal, I’ve come on some observations. Keep in mind that these are from a content management veteran, but Drupal newbie. In no particular order:
Drupal is configurable as all get-out. It’s a developer’s dream in the sense that there’s nothing that can’t be added to or changed.
Drupal is flexible enough that I don’t know if I’d even typecast it as a “content management system.” It’s an application framework, more than anything. You could write apps on it that were only distantly related to traditional content management scenarios. (Adam pointed me to Sprout Builder which is written on Drupal and seems to have nothing to do with content management.)
Drupal is essentially a bundle of hooks, or events. You write modules that sit around a listen for the system to do something, at which time they execute some code. A request to a Drupal site is essentially a big town meeting of all the modules:
Okay, everyone quiet down! We have this request here. Who wants to handle it? Let’s have a show of hands…ah, screw it, just form a line…
I find it amazing that Drupal can scale. The bootstrap process it runs through on every request is amazing. But, no matter how complex it is, I know Drupal scales like a mofo, which makes it all the more impressive.
Most of the “code” you write for Drupal isn’t really “logical execution” type code. It’s essentially configuration options set using PHP. There are less “if/then” statements per line than any other code I think I’ve ever written. There are most array declarations (and to a greater nesting level) per line than any other code I think I’ve ever written.
The form API is pretty remarkable. I haven’t found a CMS with a better one.
Probably the greatest skill you can cultivate as a Drupal developer is to learn all the available modules, what they do, and their strengths and limitations. Drupal is completely built on modules (there’s very little in the actual core), and I’d venture there’s more submitted code for Drupal than any other system on Earth. You could build a site with an awful lot of functionality without ever writing a line of code.
Drupal is “casually” customizable. The main method of customization is file- and function-naming conventions. Contrast this to eZ publish, which has a central authority on everything. While naming conventions are very simple to do, I fear that it might get out of hand. Already, some of the file names in my theme directory are awfully long – like, 10 segments separated by underscores.
So far, it’s going well. I’ll keep you updated.