This post is intended to be the beginning of a series of regular blog entries exploring the innermost guts of the Drupal CMS. We'll take a copy of Drupal, a mocked up website, and a debugger, and step through initialization and requests. We'll get to the heart of how it really, really works.
Drupal powers millions of sites around the web. It's a flexible, extenable open source content managment system you can run on multiple platforms. Drupal site admins can select modules from the some 13000+ available on Drupal.org. With Drupal, you can build the kind of site you need, from personal web pages to sprawling enterprise information portals.
Like so many people, I've spent much more time using drupal, than exploring it's API, or even digging into how the thing actually works. I switched to drupal sometime in 2006 after running my own, homebrew CMS for years. I had a new job in the Enterprise Middleware industry, and I found my time for software development decidedly spare. Drupal was a time saver, often to excess.
Sometimes I'd need a particular feature for deninet, and often, "there's a module for [it]". I'd need only to download the appropriate code and configure it as I saw fit. For those times no module did exist, I wouldn't need to wait long. Every time after I started writing a module, life would interveine, and upon returning weeks later someone else had already created the same thing. One might think this was wonderful, but I found it profoundly frustrating. I believe in open source; it's not about free stuff. It's about pooling our expertise to build great solutions for everyone to use.
And I wanted to contribute.
For years, however, something hampered me that I could only describe recently. While my spare free time is always a factor, what really bothered me is that I don't "own" the code. When I was writing my own CMS, I understood it from the bottom up. I knew every class, interface, and design decision. It was my code, and I knew how to extend it. While that attitude works great when you're working alone, but not with a developer community as large as Drupal. No one person owns the project in a possessive sense (not even Dries). Nevertheless, no matter how many module development books I read, or API docs I committed to memory, I did not feel grounded. I did not feel I "owned" the code, and I was always nervous about my lack of understanding. That feeling, more than anything, put me off any sort of contribution.
When I realized my fundemental hangup, what I needed to do became clear. "Obviously," I thought, "I need to 'own' the code. I need to know how Drupal works." Not just conceptually, not just the pale description of a hook in the Module Dev guide. I need to know where that hook is, how it's invoked, and why it's written that way.
Who are you?
Before anyone gets ideas about just what my knowledge or experience is with reguards to Drupal, let's set the record straight:
- I am not a core maintainer.
- I have not written core patches.
- I have not written any modules (although I tried!).
- I have contributed module patches -- 2.
- I have written code in C, C++, C#, PHP, and Python on more than half a dozen platforms.
- I have written my own CMS, but I don't use it anymore, and no one else ever has.
- I was a middleware consultant and enterprise software trainer.
- I am a award winning enterprise software courseware developer.
Why do this?
In addition to simple curiousity, I feel I can learn a great deal from how Drupal is written. There are some very sharp people working on this project, but the list of core maintainers has dwindled as the complexity of Drupal shot up over the last few versions. Soon, the project will be facing a crisis of too many feature requests, and not enough maintainers.
I want to work in open source. As I said earlier, I believe in open soruce and rely on it where I can. While I've built my career thusfar in the proprietary space, I'd love to contribute back to the community from which I have benefitted. If I can make a modest living from that, I'd consider myself extraordinarily fortunate. Drupal is the project with which I have the most familiarity.
While I intended to do this just for myself, it occurred to me that others would benefit from my explorations. I write software training materials for my day job, after all. Furthermore, it would serve as a reference for myself.
How are you going to do this?
I have a copy of Drupal running on a LAMP stack. I will use the Eclipse Project with PDT as development toolkit, and XDebug as a PHP debugger. I'll do all of this from a laptop running Arch Linux 64-bit. Configuration was simpler than I expected thanks to the Arch User Repository (AUR). Beyond that, I have the API website and my wits.