What about Joomla?

In my ponderings about WordPress and PostgreSQL I was challenged to consider Joomla. Believe me, I have considered Joomla and rejected it, at least for my use. Let me give you a brief history of Joomla and me.

Possibly the first CMS I ever used was Mambo, the predecessor to Joomla. It was one of the tools with which my web development company used to create client sites. One of my employees was very adept at Mambo. I remember quite clearly the day when practically the entire Mambo development team up and quit Mambo, announcing they were going to create a fork which became Joomla. It was the buzz of the office. We recommended Mambo, then Joomla to our clients. Even today, I believe Joomla is a good solution for some situations.

Fast forward a several years., circa 2007. One of my old clients approaches me to help them out with their web site, it is a Joomla 1.0.x site. That client knew I was familiar with not only their company but with Joomla. I have worked now on that site and a couple others over the past three years. We have changed themes, migrated from Joomla 1.0.x to 1.5.x and added or removed countless extensions. I have even worked on a custom Joomla extension. All this work, has given me a fairly good perspective on Joomla and what I don’t like about it.

First and foremost, Joomla has a bit of a wild west mentality when it comes to extensions. Each extension seems to do its own thing, often without regards to the needs and desires of other extensions or the main Joomla core. This is exhibited most grievously in the way the extensions handle css and Javascript. Joomla itself seems to encourage this behavior because of the way it handles the extensions.

On one site I often have to debug, the client has 22 Components, 34 Modules, and a gazzillion plugins, all which are not part of the core. This results in 22 different Javascript files needing to be downloaded, most at the top of the page where they shouldn’t be, and 14 different css files (and that is after we combined and minified several that we had control over). This puts the site into performance hell.

More importantly and most annoyingly, of the javascript files, the following gets loaded in this order:

1. jQuery 1.2.6 minified
2. jQuery 1.2.2
3. jQuery 1.3.2
4. jQuery 1.2.6 not minified and modified specifically for the extension that includes it (we finally disabled this extension because it was causing too much problems)

Of course that doesn’t include all the other javascripts including other Javascript frameworks such as MooTools which of course all want to use the $ for themselves. We have very little control over the order the files get loaded and the extensions of course have the pride and prejudice to think that they are the only ones that need to load anything.

Now let me say I understand on one level why the extensions do what they do and why Joomla is designed the way it is designed. The extensions are self-contained. They can be installed and uninstalled without affecting other extensions or the main Joomla core. But this self-containment allows for completely divergent and sometimes conflicting code to be introduced. Some extensions just can’t be installed with others because they step on each other, either because they haven’t used namespaces of some sort or they introduce incompatible code of another sort. An extension that expects and requires jQuery 1.3.2 gets broke when another extension loads jQuery 1.2.6 later. I am just waiting for one of the multitude of extensions installed on this site to suddenly upgrade to jQuery 1.4.x and watch the entire site burn down from the total chaos.

While I am on the extensions rant, there is a trend in the Joomla development community that really irks me. I am seeing more and more Joomla developers move to a subscription model. Oh, it isn’t a subscription for the extension itself in most cases, rather, a subscription to access the support and download sections of the web site. I understand the need to make money doing what you do but this really gripes me at one level. To get simple bug fixes a year later one needs to pay for the subscription to be able to access the download. It drives one to piracy… almost. In at least one case, digging in and fixing the bug myself was the cheaper solution. But of course, then there is the one developer who uses IonCube to encrypt the php so one can’t even go in and fix a bug! If I could get my client to abandon that extension, I would be so happy. Closing access to the php source code should result in that code being boycotted *cough* SEF Advance *cough*.

I could list a few more reasons why I don’t like Joomla but really, the whole extension thing is enough for me to avoid it. In my opinion, the Joomla development team needs to introduce a unification and minification engine for Javascript and CSS that all the extensions have to go through to eliminate duplication and conflicts (versions and namespaces) and increase the performance of Joomla based sites. I personally would probably put the hammer down in a very unpopular way and insist that all extensions use a specified Javascript framework, be it jQuery, MooTools, YUI or whatever. Now I know both jQuery and MooTools work very hard to at least not conflict with each other, so maybe a little leeway there but good grief. We don’t need 6 copies of jQuery in 4 different versions, 2 copies of MooTools each their own version, and some other little known frameworks puking up the site.

So no. Even if I could use Joomla with PostgreSQL, I wouldn’t right now. Maybe Joomla 2.0 will fix a lot of these problems. The next version of Joomla 1.6 is addressing many of my other complaints. It theoretically is even going to add additional db drivers so PostgreSQL may be possible. But I don’t see (but then I am not actively participating) in the development of 1.6 the basic addressing of what I see as a serious flaw, the proliferation of Javascripts and CSS files flowing from the extensions themselves. This is a site killer and not for me.

• ← WordPress and PostgreSQL (part 1)
• Lunch at Biaggi’s →