Yet Another Biased Drupal versus Joomla Shootout

This is exact­ly the sort of thing the Inter­net needs few­er of, but I’m going to go ahead and pol­lute the Web with my com­par­i­tive expe­ri­ence with the two lead­ing open-source CMSs available.

(I’m not count­ing Word­Press as a «lead­ing» CMS even though it is more pop­u­lar than either Dru­pal or Joom­la and clear­ly falls under the def­i­n­i­tion of «con­tent man­age­ment sys­tem». In my opin­ion, Word­Press is too lim­it­ed to be con­sid­ered in the same class as Dru­pal or Joom­la. Also because Word­Press beats the pants off of both Dru­pal and Joom­la for use-cas­es which Word­Press does fit. If Word­Press does what you want done, the Dru­pal ver­sus Joom­la ques­tion is aca­d­e­m­ic. If you need more, then it is by def­i­n­i­tion not a viable option.)

I’m clear­ly biased here; I’m heav­i­ly invest­ed in Dru­pal. Please take every­thing I write on this top­ic with that grain of salt. This blog, my online art gallery, and sev­er­al oth­er per­son­al projects have all been built with Dru­pal. I get a not-incon­se­quen­tial por­tion of my income from Dru­pal devel­op­ment and setup.

How­ev­er, late­ly I’ve revis­it­ed the ques­tion because I have the oppor­tu­ni­ty to do some Joom­la work for pay­ing clients. I’d real­ly like to think of myself as fair-mind­ed and I believe I owe it to myself and my clients to give Joom­la a deter­mined and open­mind­ed trial.

When I first saw that I want­ed to do things with Mono­chro­mat­ic Out­look that required some­thing beyond Word­Press, I went look­ing at more flex­i­ble and pow­er­ful CMSs. The first one I tried was Joom­la, and for a few days I was total­ly in love with the new toy I’d dis­cov­ered. Unfor­tu­nate­ly, that joy con­vert­ed itself to frus­tra­tion rather quick­ly. I nev­er got my head around the basic data mod­el (or even deter­mined whether there was a basic data mod­el.) My attempts at build­ing and mod­i­fy­ing themes failed hor­ri­bly, and I found the pub­lish­ing process con­fus­ing. So I reluc­tant­ly looked at Dru­pal, which had been described as more dif­fi­cult than Joomla.

What I found was a sys­tem that I could imme­di­ate­ly use. Maybe it’s because of my expe­ri­ence programming—this is not the first time that I’ve been con­fused by the pur­port­ed­ly eas­i­er of two sys­tems (I’ve nev­er suc­cess­ful­ly con­nect­ed a Win­dows machine to a net­work but think it’s a snap in Linux)—but the learn­ing curve was much steep­er than Joom­la’s. (Note: a steep learn­ing curve is one where more learn­ing hap­pens over a short­er peri­od of time. A shal­low learn­ing curve has rel­a­tive­ly lit­tle rise over more time.) Sure, there was a lot more to learn about Dru­pal (and I’d be lying to call myself a Dru­pal expert even now) but I knew pret­ty quick­ly how to install and update mod­ules, how to find answers to ques­tions I had, how to cre­ate con­tent and even new con­tent types. I was up and run­ning in a short time.

In the past cou­ple of years, Dru­pal has giv­en me its share of frus­tra­tions, which is part of why I rec­om­mend Word­Press to any­one that does­n’t need more than Word­Press. The only frus­tra­tions I ever had with Word­Press were relat­ed to get­ting it to do more than it was designed for. Sys­tem and mod­ule updates are a pain in the ass with Dru­pal unless you’re will­ing to take your site offline for an hour or else set up prop­er ver­sion­ing and roll­out pro­ce­dures out­side of Dru­pal. Dru­pal peo­ple will jump down my throat about that one, but it’s my experience.

Now, years lat­er, I’m giv­ing Joom­la anoth­er try. I’ve been doing work with a Joom­la site for a cou­ple weeks now, inter­spersed with the oth­er work I’ve been doing. I haven’t had to dig too deeply into it, and that has for­tu­nate­ly giv­en me the oppor­tu­ni­ty to do some fran­tic research as I try to get up to speed with Joom­la. To my dis­may, I’m not up to speed yet.

Here are some spe­cif­ic obser­va­tions regard­ing the dif­fer­ences between Dru­pal and Joomla:

• Core data type: in Dru­pal, the basic build­ing block is a node. With few excep­tions, every­thing you make with Dru­pal is a node, and each has com­mon ele­ments: a title, a body &c. An arti­cle or cal­en­dar event are both fun­da­men­tal­ly the same kind of thing, with dif­fer­ent attrib­ut­es. Joom­la’s phi­los­o­phy is to make each kind of infor­ma­tion or cat­e­go­riza­tion sep­a­rate to avoid con­fu­sion. Dru­pal trusts that no one is going to con­fuse a cal­en­dar event and a forum top­ic even though we can see that they are basi­cal­ly the same kind of infor­ma­tion under­neath all the extra attrib­ut­es. For me, under­stand­ing a sin­gle fun­da­men­tal idea is far eas­i­er than learn­ing mul­ti­ple types of cat­e­go­riza­tions which may or may not be arbi­trary distinctions.
• Admin­is­tra­tion areas: Joom­la’s admin­is­tra­tion area is not acces­si­ble with the same user as the con­tent areas. Joom­la’s admin­is­tra­tion screens are total­ly sep­a­rate from the site con­tent. In Dru­pal, you can spec­i­fy a sep­a­rate theme to show for your admin pages to visu­al­ly dis­tin­guish them, but if you log in with an admin­is­tra­tive user on the main site, you have access to the admin pages. Admin options are added to the stan­dard site nav­i­ga­tion, which makes it easy to jump back and forth between con­tent and admin­is­tra­tion.

  This is real­ly a mat­ter of pref­er­ence. I find hav­ing to log in twice con­fus­ing and annoy­ing. On the oth­er hand, I have to open a sep­a­rate brows­er if I want to see my sites as a stan­dard user would see them, with­out the admin cruft. Though I fall on the «inte­grat­ed» side of the argu­ment, the oth­er side is a per­fect­ly rea­son­able position.

• Func­tion­al­i­ty Out­side of Core: Dru­pal’s func­tion­al­i­ty is split into mod­ules. Some mod­ules just cre­ate a new con­tent type, oth­ers add bridges to oth­er soft­ware, yet oth­ers add dynam­ic fea­tures to a site. Even Dru­pal’s core fea­tures (includ­ing the parts that can’t be dis­abled) are orga­nized in mod­ules. Joom­la has Com­po­nents, Mod­ules and Plug-ins, each installed and con­fig­ured dif­fer­ent­ly. Com­po­nents are sep­a­rate appli­ca­tions, pre­sum­ably with some Joom­la inte­gra­tion. Dru­pal would make the inte­gra­tion fea­tures a mod­ule and let the appli­ca­tion stand on its own. Mod­ules seem to be most­ly what Dru­pal mod­ues are: code that adds func­tion­al­i­ty to the site with­out adding an inde­pen­dent soft­ware pack­age. Plug-Ins are fil­ters that change exist­ing con­tent before that con­tent is pre­sent­ed. An exam­ple would be some­thing that turns all the arti­cles on the site into Pirate-speak: «Click here» to «Arrrr… Click here, matey!» That’s a bad exam­ple, because Joom­la also has lan­guage sup­port as whol­ly sep­a­rate area of cus­tomiza­tion, but let’s set that aside in def­er­ence to the illus­tra­tive exam­ple. In Dru­pal, Plug-Ins would be mod­ules, or func­tions han­dled by mod­ules such as Con­tent Tem­plate (con­tem­plate), or Views.

  I sort of under­stand the dis­tinc­tion between these class­es of cus­tomiza­tion, but I don’t under­stand why the dis­tinc­tion is impor­tant to a site admin­is­tra­tor. Give me parts that do things and let the mod­ule devel­op­ers wor­ry about the dif­fer­ences in inter­nal log­ic. Unlike seg­re­gat­ing the admin area from the con­tent area, I don’t see the upside. If I want to add a fea­ture to my site, do I care whether it’s a «com­po­nent» or a «mod­ule» or a «plug-in»? Maybe 

• Image sup­port: Here I have to give Joom­la cred­it. Image man­age­ment is a core fea­ture in Joom­la. In Dru­pal there are mul­ti­ple com­pet­ing ways of han­dling images, and those have mul­ti­ple sets of inter­faces for man­ag­ing and dis­play­ing images. Where Joom­la gen­er­al­ly shows a greater lev­el of balka­niza­tion than Dru­pal (more on this lat­er) there’s no con­fu­sion about what approach is bet­ter to learn for includ­ing images on your site. Dru­pal 7 (which is still not an offi­cial release) improves on this some, but the improve­ment is incre­men­tal. Dru­pal 7 still has no inte­grat­ed image manager.
• Data abstrac­tion: In Dru­pal, a node is a piece of infor­ma­tion which can be dis­played. A block is a con­tain­er for infor­ma­tion, whether it’s one node or many, or even a chunk of sta­t­ic HTML code. Themes pro­vide rules about how to dis­play blocks and nodes. There, you have a con­cep­tu­al mod­el of the basics of Dru­pal’s orga­niz­ing prin­ci­ples. You can rearrange, mix and match to your lik­ing. Joom­la has «man­age­ment» pages which cor­re­spond not with sin­gle con­cepts, but with parts you see on the site. Go to the «Front Page Man­ag­er» to change what shows up on your site’s home page. Sec­tions appear to be pre­de­fined chunks of real estate on indi­vid­ual pages, and cat­e­gories are tags for cat­e­go­riz­ing con­tent, sort of like Dru­pal’s tax­on­o­my except that each cat­e­go­ry exists only in one sec­tion. So real­ly, cat­e­go­ry could have been called sub­sec­tion.

  If you’re a top-down thinker, inter­est­ed in manip­u­lat­ing the sur­face details with­out hav­ing to cre­ate a log­i­cal set of con­texts or orga­niz­ing prin­ci­ples, Joom­la is prob­a­bly for you. If you think from the bot­tom up, and can’t stand mess­ing with any­thing unless you have some idea what you’re actu­al­ly doing at some fun­da­men­tal lev­el, you might be bet­ter off avoid­ing Joomla.

• Soft­ware phi­los­o­phy: nor­mal­ly, I think that Joom­la’s approach to Open Source soft­ware (Free/Libre Open Source Soft­ware, aka FLOSS) is prefer­able. It’s like the dif­fer­ence between the Lin­ux and BSD licens­es. The more «free» licens­es are actu­al­ly more restric­tive, but that restric­tion guar­an­tees that more soft­ware will be freely avail­able. I under­stand the pros and cons, and from a pure­ly the­o­ret­i­cal per­spec­tive, I think that in most cas­es Joom­la’s approach, which encour­ages com­pe­ti­tion, is the best one. In Joom­la’s case the result seems dis­as­trous.

  While Dru­pal encour­ages the merg­ing of sim­i­lar projects and mod­ules, Joom­la’s approach encour­ages each small devel­op­er to cre­ate mod­ules on their own, not share infor­ma­tion with oth­ers, and try to be the best with­in a cat­e­go­ry. This is great on a gran­u­lar lev­el: com­pe­ti­tion and choice increas­es the qual­i­ty of Joom­la modules.

  Look­ing from a wider per­spec­tive, how­ev­er, it’s only indi­vid­ual mod­ules that ben­e­fit. With­out con­sol­i­da­tion of impor­tant mod­ules, oth­er devel­op­ers have to either tie their solu­tions to one approach or rein­vent the wheel. Where Dru­pal has one mod­ule (well, two actually—even Dru­pal isn’t total­ly immune to project schisms) to han­dle e‑commerce it also has hun­dreds of small­er mod­ules that rely on that one e‑commerce pack­age, and mod­ules that pro­vide «glue» between it and oth­er mod­ules. In Dru­pal, the Über­cart Roles mod­ule mar­ries the core Dru­pal user role con­cept to the Über­cart e‑commerce pack­age to cre­ate a mod­ule that per­mits users to pur­chase high­er lev­els of access to their web­site, based on roles set up by the site admin­is­tra­tor (note that Über­cart roles is so pop­u­lar that it was rolled into the main Über­cart distribution—while it is still its own mod­ule, it’s avail­able to any­one who has installed Über­cart). The author of Über­cart Roles was able to (rel­a­tive­ly) eas­i­ly lever­age exist­ing code to enable sites to offer sub­scrip­tion con­tent. Though the Über­cart mod­ule and the code that sup­ports roles is quite exten­sive, the Über­cart Roles mod­ule weighs in at about 1300 lines of code—pretty lightweight.

  There are dozens of Joom­la mod­ules that do the same thing, but each and every one of them had to build their own e‑commerce solu­tion and cre­ate their own meth­ods of enabling and restrict­ing access to select­ed con­tent. A Joom­la user wish­ing to cre­ate a sub­scrip­tion web­site has to sort through all these com­pet­ing options, many of them cost­ing hun­dreds of dol­lars, and none of them hav­ing inter­op­er­abil­i­ty with the oth­er kinds of prod­ucts the site might offer. You want to offer t‑shirts and web­site sub­scrip­tions? Your cus­tomer on a Dru­pal site can do that eas­i­ly. I won’t say it’s impos­si­ble to do with Joom­la, but the path is nowhere near as clear, nor as sus­tain­able over the long run.

  Remem­ber my com­plaint about Dru­pal’s image sup­port? That’s how Joom­la is with its entire cat­a­log of third-par­ty add-on modules.

• Themes: I’m going to have to give this to Joom­la, since every­one says great Joom­la themes are plen­ti­ful and great Dru­pal themes are nonex­is­tant. I have to admit, even http://www.whitehouse.gov/ pret­ty much looks like a Dru­pal site. The state of Dru­pal themes is a bit dis­mal. The only place I’ll dif­fer with con­ven­tion­al wis­dom here is that, hon­est­ly, good themes in Joom­la are few and far between too. With either sys­tem, you’re going to have to pay some­one to make your theme look passable.
• Sup­port: Relat­ed to soft­ware phi­los­o­phy (see above) sup­port is a tricky top­ic. Both Dru­pal and Joom­la have large ded­i­cat­ed com­mu­ni­ties of users. Joom­la has the advan­tage of a wealth of third-par­ty com­pa­nies that are charg­ing for thi­er mod­ules (and com­po­nents and plug-ins) and which are oblig­ed (if for no rea­son oth­er than enlight­ened self-inter­est) to pro­vide prompt and use­ful sup­port. The down­side is that the qual­i­ty of this sup­port varies from com­pa­ny to com­pa­ny. But that’s no big deal; that’s the way the rest of the world is.

  Dru­pal’s sup­port is almost all in the same place: http://drupal.org/. There are oth­er resources, but the forums on Dru­pal’s main web­site is the clear­ing­house for every issue and sup­port queue of every mod­ule avail­able. The down­side? Some mod­ules are not well-main­tained and unpop­u­lar, which can make it dif­fi­cult to get sup­port for them. It’s also plagued with quite a bit of FLOSS atti­tude. Expect your bug reports and sup­port requests to be met with defen­sive­ness and sug­ges­tions that you RTFM. Much of the time you’ll be pleas­ant­ly sur­prised, but you won’t have to wait for long to be told that there is no prob­lem. Some­times the response will be help­ful and oth­er times even a pil­lar of the Dru­pal com­mu­ni­t­ry like mer­li­nofchaos can be down­right hos­tile, despite users who have gone the extra mile to devise a solu­tion to their problem.

I’m not going to pre­tend that this is a fair, unbi­ased com­par­i­son and «declare» a win­ner. It should be obvi­ous that I remain in the Dru­pal camp. I find Joom­la to be con­fus­ing, dif­fi­cult, and inflex­i­ble, and I don’t see any redeem­ing fea­tures that sug­gest an obvi­ous use-case.

At the same time, I don’t expect or even desire any­one to change their mind about these con­tent man­age­ment systems.

Instead, my hope is that by elab­o­rat­ing my rea­sons I can pro­vide some per­spec­tive behind my alle­giance. Both sys­tems have fail­ings and strengths, and I hope some­one whose mind is unlike mine will be able to see that the things that both­er me won’t both­er her, or the things that I val­ue she does not. I hope that regard­less of the choic­es my read­ers end up mak­ing, that my expe­ri­ence will pre­pare them for the points of resis­tance and help them to weigh their options.

In case I did­n’t make myself clear at the begin­ning of this post, if you’re try­ing to decide what soft­ware to use to set up your blog, and you don’t need fan­cy datatypes or advanced tax­on­o­my or e‑commerce, for God’s sake don’t con­sid­er either Dru­pal or Joomla—just use Word­Press. Word­Press does what it does—makes and man­ages blogs—almost flaw­less­ly. In fact, even if you think you do need Dru­pal or Joom­la, try set­ting your site up with Word­Press first. It’s pret­ty easy to move your con­tent from Word­Press to either Dru­pal or Joom­la, and the worst thing that will hap­pen is that you’ll come out of the expe­ri­ence with a clear­er under­stand­ing of what fea­tures you need your web­site to have. You can get a basic shared account on Dreamhost for nine­ty-sev­en bucks a year, reg­is­ter a domain (includ­ed in that $97), per­form a «one-click install» of Word­Press and start your blog going in about fif­teen min­utes flat. If you have any doubt that you real­ly need Joom­la or Dru­pal, that’s exact­ly what I sug­gest you do.

You can thank me for the headaches you’ve avoid­ed later.