Drupal Versus CakePHP

Posted by in Code

Although Drupal is generally considered a CMS rather than a web application framework, there’s a fair bit of overlap in either regard, which I guess excuses the fact that I’ve been using it as such. At my current job with Eyemart Express where I work as one of two(!) software developers for a company that really requires somewhere near 20, I work a lot with CakePHP because, quite frankly, it was the first framework I could think of when the two of us met and started discussing rebuilding the company’s archaic website.

Simultaneously, I’ve also been working on a website for the National Dodgeball League to aid in building a more central community for the world of dodgeball. It’s supposed to encompass leagues, teams, and events (which also includes registration, management, and liberal use of the PayPal API). Oh, and the commissioner wants to incorporate a hefty bit of social shenanigans in there as well such as badges, following teams and players, and that sort of thing. After a bit of discussion with them, we settled on using Drupal for the project.

Though I’ve used both of these frameworks before, working with them in parallel with two different frameworks has given me more insight on what I like, don’t like, and want to wish into a corporeal form so I can burn it back into nonexistence.

CakePHP

I really like CakePHP. I mean, it may just be because it’s based in the model-view-controller architecture, but it makes a lot of sense to me and makes development extremely easy. All of your different pages go into the views (including your “theme,” so to say), your database interactions go into the models, and your user interaction logic goes into the controllers. Simple!

Everything is named as they need to be, too. In CakePHP’s effort to enforce “convention over configuration,” everything is named according to what it does, like the controller for frames is called “frames_controller.php” and its index page is in the /views/frames directory under “index.ctp.” Just about everything is automated if you name things right including table usage, authentication, and more. And even though I don’t use it, CakePHP provides a command line utility that “bakes” things automatically for you after you provide some basic parameters.

I also really appreciate how little overhead there is with CakePHP. In fact, after installation, there are no database table created and comes in at somewhere around 6MB, most of which is located in the /cake directory. The only real problems I can point out are that your models may get a bit unwiedly with more complex applications—though if you get to an unbearable size, you’re probably doing something wrong anyways—and the amount of plugins pales severely in comparison to the amount of Drupal modules available.

Drupal

Speaking of Drupal, I’ve got some beef to pick with you. Sure, the community and the modules are pretty nice, but picking through the trash to find the gold (and sometimes nothing more than shined-up pebbles) is incredibly arduous and you never truly know if something is worth using until you install, configure, and use it. This is really just a problem that comes up with the feature as I’m sure CakePHP would have a similar problem if it had anywhere near the amount of plugins available, but a problem nonetheless.

There is also an incredibly harsh learning curve for Drupal. Had I not been pinned into using it from early on, I probably would have turned back to CakePHP for the NDL project. Many things are explained in the “how to do this” fashion with the documentation and tutorials on the Drupal website, but few (if any) are explained with the “why this happens.” A prime example is how to get the theme hook to work properly (the comments spell out perfectly the effectiveness of Drupal documentation).

I jumped right into developing my own modules since I figured it would not only help with my Drupal education but also the level of customization with the site, but my initial roadblock was trying to figure out how to get a theme file to render. For the longest time, I was only getting a blank white page to show up along with whatever desperate debug statement I was outputting to reassure myself I wasn’t going crazy. After pouring through other modules, I realized you not only had to register with the theme hook/manager for your whole Drupal system in your .module file, but you also had to still make a call to drupal_render with either a function that produced an array-based, HTML-esque data structure or a .tpl.php file (or both!).

Oh, also, you have to go to the modules page in the admin panel to clear out the module cache, something not mentioned anywhere(?) in the documentation and a fact I only found out after close to an hour of angry Googling. It’s a common theme for things to be documented enough for you to know about something, but not about the underlying logic for that thing, resulting in a lot of searching the web and looking at other modules for answers, though I guess it’s hard to document everything when your system is that large.

In fact, I would downright call Drupal bloated. Though many things are set up right away after installation such as users, roles, permissions, nodes, and such, which is very nice indeed and greatly appreciated when you’re so used to doing most of those things yourself, but the installation itself sticks in 55 tables into your database. And while the actual size of the files included in the installation are quite svelte at under 4.5MB, it’s very easy for your .module files to get out of hand. Breaking out into .inc files, theme files, and other sub-modules is pretty much the only way to wrangle these file sizes and line counts into anything close to resembling manageable, otherwise everything gets jumbled together—a stark contrast to the MVC methodology.

With all the mishmash of information, logic, and layout data coming from every which way, it’s also predictably somewhat of a chore to develop themes. In fact, the recommended method of making themes and not just learning to do so is to simply modify one that already exists. The default theme itself is also quite a mixed bag of quality; while I really enjoy the blue tones and the fancy breadcrumb situation going on up top, the way forms and profiles are, dare I say, horrendous.

And Finally

That all being said, though, CakePHP doesn’t even come with a default theme let alone a built-in theming or templating system, though the views part of the whole MVC thing kind of takes care of that. Also, despite all the gripes I have with Drupal including its bloat, its learning curve, its comprehensive-yet-disturbingly-lacking documentation, and the myriad of other things I could point out that make me grumpy, I can tell that Drupal was a good choice for the NDL project. Maybe it’s a bit of Stockholm Syndrome, but I’ve grown oddly fond of Drupal’s oddities, some of which point to the fact that it may be more convoluted for a reason: it’s more powerful. So many things are built-in and yet so many other things are left out for a reason; the developers know what is and what isn’t important and what can lend to a more versatile framework.

That’s not to say, however, that I prefer it over CakePHP whose baseness and simplicity are just too much for me to overlook. Even though there are many things I have to handroll in CakePHP compared to Drupal (such as user stuff), I just love the straightforward MVC architecture. If I want to change how something looks, I go the /views; if I want to change how something works, I got to /controllers; and if I want to change how data is stored or retrieved, I go to /models. If only everything in life could be so simple.