» WordPress

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 WordPress sub-navigation using wp_list_pages

Dan Luton — Tue, 23 Nov 2010 14:37:19 +0000

We recently worked on a site development for evolveOD which needed a 3-level navigation structure, the top-level being the main navigation menu, with levels 2 and 3 displayed in the sidebar.

Whilst wp_nav_menu allows us to build such complex multi-tiered menus, it unfortunately doesn't (yet) let us have as much flexibility as we sometimes need – for building more flexible split-level menus, for example.

For this method we use a combination of careful page-hierarchy assignments and wp_list_pages to render the output in the sidebar.

Building the Hierarchy

First, you will need to make sure your pages are correctly assigned for this to work. This is done by simply assigning your sub-navigation pages as child pages of the top-level page (navigation parent).

For example, our navigation structure might be this:

Products
    – Toy Cars
    – Lego
            - Technic
            - Atlantis
            - Lego City
    - Dolls

Our page hierarchy must then echo this same structure by assigning your pages to the appropriate parent page.

Pre-requisites

This code uses the is_subpage() function to determine the parent page ID. To install this, simply copy the code below into your template's functions.php file:

function is_subpage() {
global $post;
if ( is_page() && $post->post_parent ) {
$parentID = $post->post_parent;
return $parentID;
} else {
return false;
};
};

The Code

Here's the code that generates the sub-navigation (level 2-3). It should be placed in the sidebar, or wherever you want the sub-navigation to appear:

ancestors[1];
if ($subPage) : // we're on a sub-page:
if ($ancestor) : // we're a sub-sub nav item...
echo "";
wp_list_pages("title_li=&child_of=$ancestor&sort_column=menu_order");
echo "";
else :
echo "";
wp_list_pages("title_li=&child_of=$subPage&sort_column=menu_order");
echo "";
endif;
endif;
?>

Don't forget to style the menu list as you need to via the main stylesheet.

Alternative Plug-in

There's a great little plug-in you might want to try first, called "Gecka Submenu":

http://gecka-apps.com/wordpress-plugins/gecka-submenu-pro/

It utilised the wp_nav_menu function to generate split menus, so in some ways is easier to organize and change your navigation. Unfortunately though, what it cannot seem to do is give a persistent split menu on the bottom-level menu – so if you are browsing the 3rd level menu, since there are no menus in the structure beyond this level, the menu disappears.

Our solution enables the 3rd level to always remain active, which in most cases, is what you need it to do.

Have any ideas or feedback? We'd love to hear from you, so leave us a comment.

Hiding your WordPress development site on a live server

Dan Luton — Wed, 23 Sep 2009 13:48:43 +0000

I recently wanted to develop a WordPress site on a live web server, in the root of the server, using the final domain name – however, I didn't want the public to be able to view the work in progress site.

What I would normally do in this situation is add an index.html file to the site root, then the following code into .htaccess to ensure the HTML file takes priority over WP's PHP version of the same file:

DirectoryIndex index.html index.php

However, this won't work with WordPress; it rewrites the URL to the domain root (as specified in the WP Settings panel), leaving me with access to my HTML holding page only.

So I set about a different technique. How about only allowing access to the WordPress files to my IP, and displaying the traditional HTML if the IP does not match? Well, that's what I did.

By adding a simple snippet of code to the WordPress template, you can deny access to the WP site to everyone except you (or, to be more specific, your IP address). The code looks like this:

Since my WP site used a static page for the landing page, this code needed to be inserted into my page.php template file. If you're showing posts on your landing page, add the code to the index.php template.

If you move to a different internet connection or use a dynamic IP, you will need to update the file with your current IP address.