| Building Websites with Joomla! 1.5.x |
| Written by Graham Stoney | |||||||
| Tuesday, 17 March 2009 21:17 | |||||||
Page 1 of 5 IntroductionWhen I decided to publish my Engineering wisdom on the internet, and later to set up a website for my Personal Development business, I knew that I would need a Content Management System (CMS) to do the job properly. Although I was an experienced Embedded Systems Engineer in a past life, I hadn't ever done any serious web publishing before so I had no idea where to start and expected there would be quite a learning curve. I ended up using Joomla!, which has done the job quite nicely. This article describes what I learned along the way, including some tips to save you time setting up a website of your own. My RequirementsI started off as all good Engineers do, by defining my requirements. And while I was doing that, I started playing around with some different CMS's to see which ones had the best chance of meeting them. The requirements for the CMS were all based on the features that I wanted the site to support, which were as follows:
Picking A CMSSurveying the CMS scene, I first came across Mambo, which I played with for a while. It looked up to the job, but while investigating it I learned that there had been a schism in the Mambo development team which had led to the creation of Joomla! from the same codebase. I concluded that Mambo was a dead-end and started looking at Joomla! instead. I'd also heard that Wordpress was popular but more blog-oriented; and I wanted to create an information base rather than a blog. I spent several weeks exploring Joomla! to work out exactly how to get it to do what I wanted. Things were looking pretty good, but I also heard good things on the 'net about Drupal, and I decided I should at least look at it as well. Drupal looked cool, but I concluded that Joomla! was more popular. I was pretty much convinced that either one could do the job, but by then I had grown tired of evaluating and actually wanted to begin implementing something, so I never really learned enough about Drupal to offer a fair comparison. It's only when you actually build a complex site with a CMS that you get to learn about the more subtle nuances that get glossed over in comparison tables, yet can make a big difference to how hard or easy it is to implement the features that you want. Version 1.0 or 1.5?There are currently two supported branches of Joomla!: 1.0, and 1.5. Version 1.0 is still supported because it is very widely used. Version 1.5 hasn't been around as long, but I took a punt on it being stable enough for a production site, and that punt paid off. The drawback with setting up a new site on version 1.0 is that migrating to 1.5 later will be painful, while the drawback with setting up a site on 1.5 is that releases due to undiscovered security problems are more frequent so it involves slightly more maintenance. Also, not all extensions are available for 1.5 yet. It is possible to use extensions from 1.0 with 1.5 via the legacy plugin, but the word on the streets seemed to be that this should be avoided if at all possible. I was able to find extensions which worked natively with 1.5 for all the functionality I required. There was a security issue with 1.5.5 which caused some sites to get hacked, and led to a rapid release of 1.5.6. A month later, 1.5.7 came along. Another couple of months later, another security issue led to 1.5.8. And two months later, yet another security issue led to 1.5.9. There's probably a later one by the time you read this. I'm hoping the need for security releases is just a blip on the radar. Nevertheless, if you're setting up a new site and want to stay current, I reckon you'd be crazy to use 1.0.X. Go with the latest 1.5.X version. Strengths of Joomla!For my requirements, Joomla!s pros outweighed the cons. I wouldn't expect a much shorter learning curve with anything else given the same requirements, and I didn't know of any off-the-shelf solution would require some customisation to meet my needs. Joomla! strengths as far as I was concerned were as follows:
Core FunctionalityOn the down side, the core functionality of Joomla! just isn't enough to build a practical modern-day website. For instance, its Search-Engine-Friendliness isn't sufficient if you want your site to rank well; and in my opinion, there's little point to having a site, if you don't. Fortunately the extensions library includes a vast array of additional functionality. Conventional wisdom is that you should utilize the core functionality before diving into the extensions library, but there are some extensions I consider essential functionality for any web site which I believe would be better as part of the core. Extension functionality tends to lead core functionality over time. I suspect Joomla! may be a victim of its own success in this respect; mass acceptance means the developers must be very careful about things like backwards compatibility. Integrating significant functionality from even the most popular extensions into the core could break some people's sites when they upgrade. Some extensions are better written than others; some fit nicely into the Joomla! architecture, while others are a hack. It's easy for an extension author to publish an update, whereas a core release is a team effort requiring lots of regression testing, translations, and a certain amount of administrative overhead. So it's understandable that the functionality in the extensions is ahead of where the core is at. Some core features just don't work the way I would expect them to; but perhaps that's just me. For instance, the default home page layout is a blog style where articles appear ordered left-to-right; while the style for blog displays of articles grouped by section or category is ordered top-to-bottom. Other people complain about this on the forum with workarounds available and it's logged as a bug, but the core still handles it inconsistently. Putting workarounds in place for inconsistencies like this wastes time that could otherwise be spent developing your site content. The Section/Category/Content ModelJoomla! enforces a strict two-level content hierarchy. You can structure your menus any way you want, but the content database is partitioned into Sections, which contain Categories, which contain your content like this: Section Category Articles I found that my content fit nicely into a two-level hierarchy, with only the occasional exception. But it's the exceptions which are hard to deal with. If my site was significantly more complex such that a three-level hierarchy was necessary, I have no idea how I could have done this with Joomla! I believe this is the single biggest differentiating factor between Joomla! and Drupal. There are many little ways in which they work differently, but this restriction is built deep into the architecture of Joomla!, while in Drupal, everything is a node in a tree with whatever structure you like. This wasn't a big enough deal for my site to motivate me to learn the intricacies of Drupal once I'd already spent 2 months learning how to get Joomla! to do what I needed though. Another drawback of the article categorization model in Joomla! is that each article can only occur in a single Section+Category pair. I could not easily, for example, publish a single article on Requirements Tracking in both my System-Engineering/Requirements and Software-Engineering/Requirements categories without duplicating the content or having one of the articles be just a pointer to the other. Neither of these solutions are particularly Search-Engine-Friendly. TemplatesThe look and feel of a Joomla! site is dictated by the use of a template. One of the benefits of Joomla!'s popularity is the vast number of templates available on the internet, either for free or relatively cheaply on a pay-per-download basis. Switching templates to change the way your site looks is relatively trivial, although not all templates are of equal quality and they don't all support exactly the same module positions. So sometimes you need to adjust your modules or elements of your site may disappear. There are two main classes of templates: fixed width or variable width. A variable width template allows the user to resize their browser window and have the elements on the site adjust themselves elastically to optimise the use of screen real-estate. The text in your content reflows to fit automatically. A fixed width template, on the other hand, is designed for a specific window size and works optimally only on a specific screen resolution. Not everyone has the same screen resolution and browser size, so a fixed width template forces some users to scroll to get access to information that they might otherwise be able to see if the content filled the available window. Whether you prefer fixed width or variable width templates is ultimately a matter of personal preference. Designers prefer fixed width because it gives them more control. But visitors like me prefer variable width because they can set their window size to suit whatever else is on their screens. Call me choosy, but despite the vast array of templates available for Joomla!, I had trouble finding one that I liked. Part of the problem was that most templates are fixed-width, whereas I wanted a variable-width one. Many of the templates had too much screen real-estate devoted to funky graphics of the template itself, and too little devoted to the actual content. My site was intended to be content-rich, so I wanted the template to focus the visitor's attention on the content, not on the pretty graphics of the template. I tried starting from scratch developing a text-only template of my own, but this proved an enormously difficult task given that I had to learn PHP, CSS and the Joomla! template design rules all at the same time. Time I spent doing this was time I wasn't using to develop the content of my site, which was what I was wanting to focus on. I ended up giving up and found a variable-width template that I liked sufficiently to start hacking it into what I really wanted. But it was heavy going for a CSS novice like me, and I was always bothered by a large to-do list of things about it I wasn't really happy with. I slowly came to realise why designers prefer fixed-width templates. The more complex my site became the more I felt like switching to a fixed-width template just so I could avoid all the unexpected gotchas that I encountered when resizing the browser window. Fixed-width templates are so much easier implement and test, because you only have to worry about one window size. Having everything adjust elastically in the face of multiple module elements with varying content is hard. My site ended up with several module elements on each page, and getting them all to co-operate in window size changes was much more difficult than I expected. Often I would make a change and things would look great, then I'd resize and find modules overlapping each other, or content jumping down the page, or embedded diagrams no longer in the right place. The idea that CSS gives the flexibility to allow objects to float and for text to flow around them sounds great in theory. But in practice when the XHTML for different page elements is coming from different modules which don't know about each other or about the structure of the template, getting this to work for different browser sizes is hard work. There's no easy way to determine the quality of a template unless you're familiar with the template design rules and know what to look for. The important thing is that it works correctly with all the modules and extensions that you want to use. The more obscure the layout you want on your site, the more likely you are to need to tweak the template. Search Engine OptimisationI wanted my site to rank well on search engines, without me having to pay for advertisements. The main things I wanted were for the URLs on my site to include keywords such as the Section, Category, and Title of the article. Keyword-stuffing has rendered keyword meta-data of little use, but some search engines will still find keywords if they're actually in the URL itself. Unfortunately this makes my URLs rather long. I doubt that any serious search engine really still baulks at URLs containing database queries, but I wanted my URLs to be human-readable so they are better for other sites to reference and bookmark. Sadly, Joomla!s search engine optimisation isn't great out-of-the-box, which is why I recommend the sh404SEF extension below. The other important thing was to set the description metadata for each article, because this is what search engines like Google display in their search results as the summary of your article. An article in Google's webmaster help elaborates on how this makes your site look more worth visiting when the user sees it in the search results. Each of my articles begins with a two-or-three-line summary before the Read More marker, and ultimately I found the easiest way to set the description metadata was to copy this summary from the article. Ideally, I'd love Joomla! (or an extension) to do this automatically for any article without an explicit metadata description. A shortcoming of description metadata handling in Joomla! is that while articles can have descriptions, Section and Category tables cannot. The sh404SEF extension allows arbitrary metadata which works around this problem, but the trouble then is keeping the sh404SEF metadata up to date as new Sections and Categories are added. I'd love to see this deficiency addressed in the Joomla! core. Google has a tool to warn about missing or inadequate descriptions in their webmaster tools, which is definitely worth checking out, as is the Missing Metadata extension described below. |
