Tip: Pros Love Ugly Extensions

Don't judge an otherwise-great Joomla extension by how pretty it is, or isn't; just dig in with some CSS, and pretty it up!

I'm no designer, but sometimes it doesn't take a designer, to make an improvement.The good news: Joomla's community produces thousands of free extensions. The bad news: rarely are they styled to resemble the rest of your particular website. The ugly news: programmers aren't always big on style anyway aware style exists.

However, by dipping your whole self into CSS, and sometimes leveraging other standard tricks, you can often do more than fix the look -- you can make it look truly worthy of the rest of your template.

You like real world examples, I like showing off. I don't even sell design. Let's do this.

Case 1: JEvents

The programmers of JEvents are stuck in the same style dilemma as any open source extension coder. Give the extension one stylish skin, and expert users will complain it clashes with their site. Leave style to the end-user, and users will pan the extension for being unworkably bland. 

JEvents solves this gracefully, except for its navigation widget. The nav block is a... well, I'll just show you.

JEvents Before: That nav block is the mother of all Tetris pieces.
JEvents Before: That nav block is the mother of all Tetris pieces.

I found it unacceptable. Worse, it uses tables -- tables! -- instead of divs and the CSS class naming wasn't done with precision in mind. There were perilously few CSS IDs in place, too. Thankfully, CSS is now advanced enough to provide workarounds.

Using CSS to Fix Style Issues

I can't teach you CSS in an article, but try to keep up. Hopefully, you already know that HTML is the language of document structure, and CSS is the language of document style. A CSS class is a style hook. If an HTML element has a class name, it can be styled.

JEvents provided class names on almost everything. Thanks to path selectors, some parts of an HTML document might lack CSS hints, and yet still be reachable precisely by CSS. This is possible so long as any of the element's "parents" in the nested document structure, have style hints (class or ID).

Using classes, and paths matching patterns of usage within class-named elements, almost sufficed to restyle the entire nav block. However, I wanted to replace the images being used for buttons on the date chooser, and hit a snag. 

To replace the four nav buttons, I needed four distinct CSS rules, one for each image. Too bad: the code for the table-link-image combos presenting the buttons, neither had unique class names, nor sat in unique element structures, with which to differentiate precisely. This means older browsers will miss out on my master nav block vision, but anyone using a newer browser will be compatible with the powerful ":nth-child" selector feature. This allowed me to rely on the date picker's table code, which (crucially) never changes from click to click. Using that information and CSS path selectors invoking the :nth-child feature, I was able to replace the button images.

The entire customization was done using CSS:

JEvents After: Yes, you can hire me for this. It's not design, it's visual repair.
JEvents After: Yes, you can hire me for this. It's not design, it's visual repair.

An !important Note

Often, as with JEvents, an extension comes with CSS code, but it's not perfect for your needs. Also often, this can include elements being explicitly styled by the programmer, but not in a way you like. Sometimes you will automatically override these when you do style, without even realizing it; other times, browsers will ignore your custom CSS because the default took priority. This happened at least once with the JEvents navigation menu's customization.

Another CSS feature fixed it -- the !important flag. It doesn't solve 100% of cases, but it is quick and easy. You simply add !important to the style definition, and it will gain strength of priority to override conflicting style code on that page. Only more-precisely-targeted CSS code which also bumps its priority, is likely to win-out against you after you invoke !important.

So, as quickly as all that can turn awesome, CSS isn't total power. Let's look at a more obstinate extension.

Case 2: JoomGallery

JoomGallery, like JEvents, is a very popular extension. Let's have a look at what I was working with to start:

JoomGallery Before: This is one of the JED's top eye candy extensions. Obviously.
JoomGallery Before: This is one of the JED's top eye candy extensions. Obviously.

Out of all my nitpicks with JoomGallery's site UI, there was only so much needing done via CSS -- it wasn't necessary for about half my tasks, and it wasn't a useful way forward, for a few others. I added styles as fitting, then started digging through JoomGallery's configuration page.

Config and Control

A component with lots of configuration options can be daunting, and the control labels in JoomGallery's back-end could use an eye for pedantic consistency. After no fewer than six crawls through its tabs, subtabs, and many, many fields, I found everything I wanted to switch off, on, or elsewise. 

This is a very important thing to remember about the broad array of extensions available -- each programmer has different ideas about what options to present, how to implement control over those options, and precisely where and when to present them. It can easily be that you've "looked everywhere" according to one paradigm, and done nothing relevant to the task at hand, according to another. Few aspects of Joomla adminship demonstrate this quite like the varying degrees and avenues of style control.

And, case in point, after those six-or-so passes through JoomGallery's config, I was still hunting for solutions to sprucing up what I hadn't turned off.

Better Template Than Never

Thankfully, a component's authors can allow you full control over both form and even function, just by structuring the project correctly. 

Most good extensions have many discrete templates. The originals of these templates, reside under their home under the /components/ folder, each organized by their sub-function. For example, the stock Content component has a sub-folder for /category/, another for /categories/, another for /article/, and so forth -- each of the views.

Now that Joomla 3 really is advisable, overriding a template has gotten easier. I created the override for my template via Template Manager, studied the content of the view I wanted to improve, and did surgery. After much rotating between my custom CSS file and various override files, I was almost done. 

It is when you are almost done, that the last items become strong like boss.

Confound, the Languages

Finally, it came time to replace the "TOP 12" links, with buttons. This almost required modifying a core file. 

This bar of links was not being output anywhere in the component's templates -- requested, but served from elsewhere in the component. I searched wider, and found a helper file buried in the component's folder -- which is not something you can override. Thankfully, the helper file indicated that the body of these link texts, were being served from Joomla's Language Manager.

A bit of text for a link body, is prime thing to put in the languages system. Now, however, it's become part of our site layout. Ah, well -- it's better than modifying core files. 

I replaced the text in the links with image code, complete with simple tooltips, using the Language Manager's Overrides tool, and was finally done customizing one of JoomGallery's views. Those buttons, at least, will replicate across all of JoomGallery's front-end, and the changes to the category view need only to be repeated for the other front-end templates.

Here's the result:

JoomGallery After: Only the hyphens amid the "TOP 12" links, were hard-coded.
JoomGallery After: Only the hyphens amid the "TOP 12" links, were hard-coded.

Where to Start Learning

I'll recommend the same website I continually learn CSS from: W3Schools.com. Yes, I've always learned from references. There's no easier way to learn web technology, than hands-on.

Naturally, for the Joomla stuff, you'll study the docs at Joomla.org -- specifically dealing with component template overrides, and language overrides.