» CSS

Are Template Clubs Losing The Plot?

Dan Luton — Wed, 19 Jan 2011 16:30:31 +0000

I've long been a fan of the cutting-edge design work produced by many of the top template clubs.

Rich, unique designs are being published every month for keen club members to download and deploy for their own web projects, making it easy to get an amazing looking website up-and-running in relatively little time.

However, what I'm not a fan of is the way many templates are built these days.

A good poke around under the hood is enough to make anyone who works with HTML/PHP/CSS frown at what's going on – yes, the code is normally nicely structured, but what is rendered in the browser needs to be carefully considered before using a commercial theme.

Framework = More Work?

The trend these days is to use a proprietary theme framework – these are produced by the clubs and normally the core is shared under a GPL license. All of the club template releases are built on this framework, which offers a bewildering amount of flexibility in layout and features. Often they come complete with an entire management system which is used to configure how everything works. This management can even stretch beyond the template and start managing core features of the CMS itself.

However, the learning curve tends to be steep, with the frameworks being massively complex in their implementation, and core changes to the code are far more difficult than they would be for a more traditionally constructed theme.

Many aspects of the layout can be adjusted within the theme's setup options, so in a lot of cases, code intervention isn't really needed – but what if you need to break free of the framework for something? You have to commit to learning how everything works within the framework, and often even small adjustments are hugely complex given the more rigid nature of the frameworks (which are normally based on a CSS grid system).

More Features = Less Performance

Ah, HTTP requests. A real hog of performance, and something you want to really keep to a minimum. By using clever techniques such as CSS sprites, JS and CSS combining, you can massively reduce the number of requests thus speeding things up – a win for your users, a win for your host, and a win for the performance of the site.

Now, I understand the requirement to separate elements up in order to give flexibility to a theme – but at what cost? Dozens of individual CSS and Javascript files cannot be a good thing.

Take a nice, lean CMS like WordPress for example. I recently was asked to investigate why the breadcrumb trail wasn't working (turns out the theme's breadcrumbs file was pretty much useless) and was horrified at the source output that I saw. Take a look at these stats:

section (a 'normal' site would be around 20-100 lines) including:

233 lines of code for the section (a ‘normal’ site would be around 20-100 lines) including:
46 lines of embedded CSS
16 separate CSS files
12 separate Javascript files
2 Javascript libraries
Almost 1400 lines of code for the home page

Which all add up to the following:

308 total objects
287 images
300Kb of scripts
A 2,700Kb total page size

Of course, I understand that sites will vary in content, plus there were a couple of extra plug-ins installed in this case – but a quick look at the relevant demo sites paints a pretty similar picture. When you consider that template clubs usually run on some pretty beefy server hardware, they can give a false impression of how the template might perform. Once deployed to a more common shared hosting platform, performance will undoubtedly suffer.

What can we do about it?

Template clubs and their projects are obviously a great way for novice developers and webmasters to get started, but many will be oblivious to what goes on under the surface of a theme, blinded by the fancy design and effects.

It's a shame in some ways, as the popularity of these clubs means that a high percentage of CMS websites will be using them, which could portray the whole platform in a negative light if the performance of a platform is judged on these sites.

My advice: take a look at what's going on under the hood when using a club template, you might be surprised at what you see. All those features aren't really free, and are costing you dearly in terms of performance. Also, to get some real stats on your site, run it through a performance checker like http://websiteoptimization.com/services/analyze/ to see how your own projects perform.

Of course, not all theme providers can be tarred with the same brush – know of a club producing more streamlined templates without all the fluff? Let us know in the comments!

Advanced Techniques: The Joomla Parent Menu ItemID

Dan Luton — Wed, 03 Mar 2010 22:50:56 +0000

Joomla's ItemID system offers a great way of customizing sites by giving the opportunity to style major parts of a template or page based on the menu links ItemID.

Every menu link in a Joomla website has one; and they are unique to each and every link on your site.

But what if you need to style entire sections of a site based on a handful of top-level (parent) menu items?

This article explores the methodology of styling sub-level pages respective of their common parent menu links.

Method 1: Modifying the mod_breadcrumb Module Code

The mod_breadcrumb module is native to Joomla, and by it's core function maintains a trail of menu link hierarchy leading to the current page. This code can be utilized in order to obtain the top-level menu's textual name (rather than an itemID number). This method expands the code further to reformat this text into a usable, readable format which can be used to style a page in an understandable way. It's more code-heavy than method 2, but provides an easier-to-understand output that works in exactly the same way.

Let's first examine the original code:

defined('_JEXEC') or die('Restricted access');

class modBreadCrumbsHelper
{
	function getList(&$params)
	{
		global $mainframe;

		// Get the PathWay object from the application
		$pathway =& $mainframe->getPathway();
		$items   = $pathway->getPathWay();

		$count = count($items);
		for ($i = 0; $i < $count; $i ++)
		{
			$items[$i]->name = stripslashes(htmlspecialchars($items[$i]->name));
			$items[$i]->link = JRoute::_($items[$i]->link);
		}

		if ($params->get('showHome', 1))
		{
			$item = new stdClass();
			$item->name = $params->get('homeText', JText::_('Home'));
			$item->link = JURI::base();
			array_unshift($items, $item);
		}

		return $items;
	}

	function setSeparator($custom = null)
	{
		global $mainframe;

		$lang =& JFactory::getLanguage();

		if ($custom == null) {
			if($lang->isRTL()){
				$_separator = JHTML::_('image.site', 'arrow_rtl.png');
			}
			else{
				$_separator = JHTML::_('image.site', 'arrow.png');
			}
		} else {
			$_separator = $custom;
		}
		return $_separator;
	}
}

We can immediately remove the second part of the code that sets the separator, since we don't need that. Also, since we only need to return the parent item's text, we don't need the loop in place. We shall also use the Application Object since
$global mainframe will be removed in Joomla 1.6, so:

$global mainframe;

Becomes:

$app = &JFactory::getApplication();

Which gives us the completed code below:

class getParentMenuTitle {
	function getList() {
		$getParent = &JFactory::getApplication();
		// Get the PathWay object
		$pathway =& $getParent->getPathway();
		$items = $pathway->getPathWay();
	return $items;
	}
}
$list = getParentMenuTitle::getList();
$count = count($list);
if ($count !== 0) :
	$parentmenu = $list[0]->name;
	$parentmenu = ereg_replace(" ", "-", $parentmenu); // replace spaces with a dash
	$parentmenu = ereg_replace("[^+A-Za-z0-9-]", "", $parentmenu); // strip special characters
	$parentmenu = strtolower($parentmenu); //set name to lowercase
else :
	$parentmenu = "home"; // Set parentmenu to "home" if there are no items
endif;

How To Use The Code

This block of code can be inserted directly into your active template's index.php file before the HTML is started. Remember to enclose the code block in PHP tags. Alternatively you can include it from an external file.

Once working in the template, you can apply the variable $parentmenu to a top-level container to initiate a CSS hook. Where you add this will depend on what you need to influence in the design, but the further up the hierarchy the more things you will be able to affect in the design – for example:

…will allow you to influence the design across the whole template, such as:

body#menu-link-name a {color:red;}

…which will change all links on the page to red for that particular top-level menu link.

Method 2: Using the Jsite Object

This method is by far the simplist of the two methods, and unless you need a more human-readable format for the menu class/ids then it's by far the recommended method of the two. It uses the Jsite object to obtain the parent menu's ItemID and stores it in a variable which can then be applied to any class/id in the template:

$parentmenu = JSite::getMenu()->getActive()->tree[0];

You can obtain the ItemID of any menu links in the pathway by altering the value of tree[0].

How To Use The Code

Again, this code needs to be inserted into the template. The ItemID is stored in the $parentmenu variable, just as it was before, so you can use a similar method to above – but prefix the class/id with something or else you may have problems, for example:

Why Would You Need To Use Method 1?

The first method could be useful in instances where you (as the developer) might want to pass more control onto someone who is less technically-minded – the class/id names which are generated using this method are very easy to predict, whereas method 2 requires the administrator to lookup the itemID for each menu item that requires styling.

Something to Share?

Have an alternative technique, or have you used this (or something similar) on a site before? Please do share it in the comments.

Many thanks to Gergő Erdősi and Amy Stephen for the code presented in method 2 above.

Anatomy of a Newsletter

Dan Luton — Mon, 04 Jan 2010 11:12:59 +0000

Newsletter crafting can be pretty straightforward but cumbersome at times due to the way they must be constructed in order to retain the original designs – even more so if the designs are quite complex and laden with images.

Getting Started

First off, work from a design so you know how the final construction will look. This can be a full-blown Photoshop mock-up, or a wireframe…however you make it, just make sure it's designed as you'd like the final newsletter to appear.

Once your design is ready, you will need to create the framework of the newsletter, using HTML tables and a combination of carefully defined table-cells. You can save some time here by using a visual (WYSIWYG) editor such as Dreamweaver to visually create the layout; this will save a significant amount of time over hand-coding the table layout. In fact, you can use a visual editor to create the whole thing – but I personally prefer to see exactly what's going on, so tend to hand-code once the basic structure is defined.

Note that the table I've used here is quite narrow (600px) and centered – you can use your own dimensions and alignment here, but this arrangement seems to work best for most email clients and display resolutions.

I've also left the border active (border="1") which will help when I add content to the layout. You can disable this later if you do not wish the borders to be displayed in the final newsletter.

Adding Content

Once you have your basic structure in place, you're ready to start adding content (text and images) to the newsletter. For now, don't worry about the styling; just add the bulk of the text and any images you have to the layout.

If you don't have final images, use exact-sized placeholders until the graphics are ready. This will help to get the layout exactly right, and show where any fine adjustments to the table layout is needed.

Images should be added using the absolute path to the server where they are stored:

…this will ensure the images load correctly into the document. Note that many email clients will require user approval before they fully display embedded images – it is not possible to override this.

Adding the Style

This is where most of the time is consumed – actually adding the inline CSS to the layout in order to get the look to match the design you've made. Inline styling offers the best and most widely compatible method to add styling to the newsletter. If you're comfortable with hand-coding the styles, this is the best way – but of course you can always use a visual editor…just keep an eye on the way the styling is added to the document – some editors (such as Dreamweaver) may define styles in a stylesheet format which won't work for the newsletter.

The styles must be applied to each and every element that needs to be altered from the default. You can of course apply a global style to the whole container (the main table definition) to set a standard font size/colour/style to start you off:

This will give you your text style for any text that does not have it's own definition. Much of the styling information will be applied to things like headers and links:

Here's My Title

Check out the following link:

My Link

It is necessary to add all styling information in this way. You should also refrain from using shorthand CSS as some email clients will ignore this method of styling, such as:

This is my paragraph.

Viewing the Newsletter in Other Formats

If your mass-mail system supports a plain-text version of the newsletter, you should take the time to create this alongside your HTML version so that users who cannot view mail in HTML format can still read the email.

If this is not practical or possible, provide a link to the HTML document on your server at the top of the email, this way readers who cannot properly view the newsletter will at least have the option to view the newsletter in their browser, which has a good chance of being rendered as you intended it.

The finished example (click to view the actual document in your browser)