This site is for a NZ-government agency, FEUT, which manages carbon emissions for government-owned forests.

The site design is by McGovern & Associates, and coded into a custom WordPress theme by Urban Legend web.

The site is coded in HTML5, and features some custom jQuery in the Licensed Crown Forests section, and on the contact page. It also gives its owners the ability to update a forests database from an uploaded Excel file using a customised WordPress plugin.

It uses modern @Font-face coding to render the desired font family across platforms.


Wrote this quick WordPress code snippet at WordCamp Louisville. It makes a /random/ URL on your site which redirects to a random post. Thought some people might find it useful.

Not a perfect little snippet, but gets the job done. Note the use of the little-used 307 redirect for temporary redirection. This is to make browsers not cache the results of the redirect, like some of them might do with a 302.

add_action('init','random_add_rewrite');
function random_add_rewrite() {
       global $wp;
       $wp->add_query_var('random');
       add_rewrite_rule('random/?$', 'index.php?random=1', 'top');
}

add_action('template_redirect','random_template');
function random_template() {
       if (get_query_var('random') == 1) {
               $posts = get_posts('post_type=post&orderby=rand&numberposts=1');
               foreach($posts as $post) {
                       $link = get_permalink($post);
               }
               wp_redirect($link,307);
               exit;
       }
}

There’s plugins that do this sort of thing too, but this is such a simple little thing that it doesn’t really need a big amount of code to do.

Edit: Added get_permalink() optimization from @Raherian.

If you read “how-to” stuff for WordPress sites around the web, then you frequently run across what many people like to call “snippets”. Short bits of code or functions to do various things. I myself post snippets frequently, usually made up on the fly to solve somebody’s specific problem.

One question I get a fair amount is “where do I add this code?”

The usual answer to this for a lot of people is “in the theme’s functions.php file”. This is a quick solution, but it is often a problematic one.

The reason this has become the more or less go-to place to add these snippets is because it’s complicated to explain to a newbie how to make a plugin and activate it, or to point out the problems with modifying core code, or plugin code. Saying to look for a specific file in their theme, on the other hand, is quick and easy, and until recently theme upgrades have been fairly rare.

However, as themes get upgrades, it becomes more and more incorrect to tell people to modify them directly. And telling people how to create child themes is complex, even if it’s easy to do.

So I’d like to start a new trend, and recommend that people start making Site-Specific Plugins. Most people who run WP sites on a serious level do this in some way already, but if you make it sorta-standard practice, then it’ll make things simpler all around.

How to create a Site-Specific Plugin

1. Create a new directory in the plugins directory. Name it after the site in some fashion. For example, /wp-content/plugins/example.com or something like that.

2. Create a new php file in that directory. Name is dealer’s choice.

3. Put this in the file:

<?php
/*
Plugin Name: Site Plugin for example.com
Description: Site specific code changes for example.com
*/

4. Finally, go activate your new blank plugin on the site.

Now you have a simple and specific place to add snippets. It will survive upgrades of any sort, and you can edit it to add new code on an as needed basis. What’s more, it’s kinda sorta break-proof. If the user uses the built-in plugin editor to edit it, and they add code that breaks the site, then the editor detects that on saving the code and deactivates the plugin, preventing the “white screen of death” for their site.

This is a much better way to use “snippets” than the theme’s functions.php file, and we should really use it more often in our replies to users.

The Parrot PlaceThe Parrot place is an online pet shop, offering pet supplies, fish food, and specialising in supplies for birds.

It is WordPress-driven, and uses the E-commerce plugin for online sales.

Urban Legend web was contracted to create the collapsible menus on the left side of the site, and to make changes to the backend of the E-commerce plugin to clarify the display of categories. We also helped with some minor styling tweaks to the main menus.

Marblehead GalleryMarble Head Galley is a restaurant in Marblehead, Ohio, USA.

Urban Legend web was contracted to provide a calendar application which let the site owners enter daily dinner specials by month. We used an existing WordPress plugin, calendar, and incorporated it into the slider mechanism used on the front page of the site.

We customised the calendar plugin so that the current week’s specials only were shown, with a link to the full calendar month.  We helped to style the calendar, but weren’t involved in the design of the site itself.

Google rolled out their +1 button today. So I added it here. You’ll find it below all the posts. Try it out.

Here’s the simple-stupid plugin I wrote to do it. While you can just edit your theme, I like making these sort of things into plugins. That way, I can turn them off at will, and I know exactly where to go to change them without having to dive into my theme code. Also, if I change themes, the code still works on the new theme.

<?php
/*
Plugin Name: Otto's Google +1 Button
Description: Add a +1 button after the content.
Author: Otto
Version: 999
*/

add_filter('the_content', 'google_plusone');

function google_plusone($content) {
	$content = $content.'<div class="plusone"><g:plusone size="tall" href="'.get_permalink().'"></g:plusone></div>';
	return $content;
}

add_action ('wp_enqueue_scripts','google_plusone_script');

function google_plusone_script() {
	wp_enqueue_script('google-plusone', 'https://apis.google.com/js/plusone.js', array(), null);
}

I wrapped the button in a div so that I could style it. In my particular case, I’m floating it right and giving it a margin, same as the Twitter and Facebook plugins. One day, I’ll make all these little Google plugins more generic and configurable, and roll them into a Simple Google Connect plugin. :)

One thing I don’t like is that the +1 button only works for people who are logged into a GMail account. Sorry Google Apps users, you’re out of luck. Complain to Google until they fix it.

If you want to add more parameters to the plugin and reconfigure it, you can find out about the available parameters here: http://code.google.com/apis/+1button/#configuration

I have seen many questions from people about how to create photo galleries in WordPress. But often I see these questions answered by somebody recommending a plugin or something like that. You don’t really need plugins to create photo galleries. WordPress has a huge amount of gallery functionality built right in. You just need to make your theme smarter in order to take advantage of it.

Note: Matt has one of the neatest photo gallery implementations around, and he often gets questions about it. So I’m going to refer to it from time to time in this post. Maybe you’ll want to head over there and familiarize yourself with some of the look and features of it.

Understanding the Gallery Concept

One of the first things you need to know is how WordPress organizes Galleries. A gallery is really just a post with a bunch of images attached to it.

While editing a post or creating a new one, you have the option to upload images or other files. When you upload a file through the file Uploader, WordPress creates a post just for that file. This post has a post_type of “attachment”. Images in particular get some extra processing, and they show up in multiple sizes, you can insert them into the posts, etc. You probably already knew that. You probably have seen the gallery inserter, which just inserts the “gallery” shortcode into your post.

What you might not have known is that it’s doing more than you think. It’s not just resizing those images you’re uploading, but it’s pulling out metadata and other information about the image too. It’s grabbing alot of the EXIF data from the image and storing it as postmeta items for that attachment post. The post itself, being a post, gets its own URL, which is the post that it is attached to’s URL followed by the attachment posts title. Basically, an attachment post is sorta like a child of the parent post, which contains the gallery. So all a gallery really is is the sum of the attachments posts that are children of the gallery post itself.

Graph of the Gallery concept

Is that clear as mud? Don’t worry, it’s simpler to work with than you think.

Create an Image Template

First thing you need to do is to edit your theme (or create a child theme, if you prefer). What you’re going to do is to make an “image.php” file.

(Side note: If you browse through the source of WordPress, you’ll never find where it loads the “image.php” file, because it isn’t there. What it is actually doing is looking for the mimetype of the attachment as a filename. So since you uploaded, say, a JPG file, then the mimetype is image/jpeg. It splits that and looks for image.php, followed by jpeg.php, followed by image_jpeg.php, and finally just attachment.php as the generic base. It does this for any and all attachments, and any and all mime types. So you can have a video.php for video attachments, audio.php for audio attachments, etc.)

The image.php file is the template that will load for “single images”. A gallery shows thumbnails, but when you click on them, you go to the attachment page for just that image. An easy way to start with your custom image page is to copy your existing single post page to it. Just copy single.php to image.php. If you don’t have a single.php, maybe you should try copying the index.php file instead.

Modify your Image Template

Since this is an image, it’s going to have things in it that normal posts don’t. It’s also going to need special navigational entries that other posts don’t have.

For starters, it has a parent, which is the post containing the gallery. So what if we want to display the gallery post’s name? Easy, we can reference the parent using $post->post_parent. So code like get_the_title($post->post_parent) will get us that title so we can echo it. Similarly, using something like get_permalink($post->post_parent) will get us the link back to the gallery. So this sort of code in our image template will display that link:

echo "<a href='" . get_permalink($post->post_parent). "'>Go back to ". get_the_title($post->post_parent) ."</a>";

For navigation, we have special functions. previous_image_link and next_image_link will let us display links to the previous or next images in the gallery order. Each of these takes two parameters. The first is the size of the previous or next image we want to display (or false to not show a thumbnail at all), the second optional parameter is some text to put in the link. So to show a couple of text navigational links, this code would work:

echo previous_image_link(false,'Previous Photo');
echo next_image_link(false,'Next Photo');

If I wanted to display image links instead, I could change that false to ‘thumbnail’ to display the thumbnail sized images. Or ‘medium’. Or whatever size I preferred.

Next we want to display the image. The wp_get_attachment_image function takes care of that easily:

echo wp_get_attachment_image( $post->ID, 'medium' );

The second parameter there is the size we want to display it at. You could also use ‘large’, ‘full’, ‘thumbnail’, etc. Any of the image sizes. If you want the image to be clickable, you might wrap it in an A tag and link it to the image itself.

But remember that attachment posts are still posts. All those fields you can enter on the image uploader are available to you to use. For example, the “Title” is stored in the normal Post Title field, so calling the_title() will display that. The Description is stored in the Content field and can be displayed with the_content(). The Caption is stored in the Excerpt field and can be displayed with the_excerpt(). You should use these as needed.

EXIF Information

Here’s an example of one of Matt’s single image pages, showing a balloon: http://ma.tt/2011/05/balloon-ride/mcm_9033/.

Nice shot. Scroll down a bit and look on the right hand side of that page, where it says INFO. Lots of nifty information there. But he didn’t put any of that in, WordPress did it all by itself.

To gain access to that information in your image.php file, you use this code:

$imagemeta = wp_get_attachment_metadata();

If you examine this array, you find that it contains widths, heights, filenames of the various sizes of thumbnails generated, etc. But it also contains an array called “image_meta”. This is an array of information that represents everything WordPress was able to glean from the image itself. After you know this, it’s just a matter of displaying it properly.

For example, to display the camera name, he has code similar to this:

if ($imagemeta['image_meta']['camera']) {
	echo "Camera: " . $imagemeta['image_meta']['camera'];
}

There’s other bits in there, like Aperture, Focal Length, ISO settings, and Shutter Speed. Most of these are straightforward, except for shutter speed which is often not in an easy format to display. Usually it’s a fractional value, represented as a decimal. Often we want to convert this to the fractional display. Here’s a bit of code I wrote to do that. It’s not perfect, but what is?

if ($imagemeta['image_meta']['shutter_speed']) {
	echo 'Shutter: ';

	// shutter speed handler
	if ((1 / $imagemeta['image_meta']['shutter_speed']) > 1) {
	echo "1/";
		if (number_format((1 / $imagemeta['image_meta']['shutter_speed']), 1) ==  number_format((1 / $imagemeta['image_meta']['shutter_speed']), 0)) {
			echo number_format((1 / $imagemeta['image_meta']['shutter_speed']), 0, '.', '') . ' sec';
		} else {
			echo number_format((1 / $imagemeta['image_meta']['shutter_speed']), 1, '.', '') . ' sec';
		}
	} else {
		echo $imagemeta['image_meta']['shutter_speed'].' sec';
	}
}

Ugly, I know, but it gets the job done, more or less. Works on most shutter speeds I’ve tested it with.

Gallery Formatting in the Stream

Now, obviously you want your posts to look good in the normal flow of the blog as well. Twenty-Ten and the upcoming Twenty-Eleven themes both show you how to do this rather easily. Twenty-Ten used the “gallery” category for this at one point, before Post Formats came along and made that method obsolete. Now it uses the gallery post format instead.

So first, obviously, your theme will need to support the gallery post format. This is easy, just add this to your theme’s functions.php if it doesn’t have gallery support already (or add “gallery” to it if it does have post format support).

add_theme_support( 'post-formats', array( 'gallery') );

Now that that’s done, you have the option of choosing gallery as a post format. So you need to edit your theme to use that flag as an indicator to display things differently.

There’s plenty of tutorials on post formats out there, so I’ll assume you’re more than capable of figuring out how to use has_post_format(‘gallery’) or the “.home .format-gallery” CSS indicators to style the posts as needed.

What you need to know for specific gallery formatting in the main stream of the blog is how to display a selected representative image from the gallery there instead of the whole thing. There’s two basic steps to this.

First, you have to write your post appropriately to begin with. Take one of Matt’s posts for example: http://ma.tt/2011/05/20/

Here’s how that post actually looks in the editor:

Description text at the top here... Went for balloon ride, etc.
< !--more-- >
[ gallery ]

In other words, he puts the description first, then the more tag, then the gallery after it. This has the effect of giving a natural separation of the description content and the gallery itself. The gallery is not displayed on the front page, because it’s after the more tag. So a call to the_content() on the stream pages will only show the description.

Secondly, you can easily adapt the Featured Image function to let you choose which image to display in the stream. All the user has to do is to upload their gallery then select one and set it to be the featured image. Voila, it’ll be the main representative one used.

if ( has_post_thumbnail() ) {
        // use the thumbnail ("featured image")
        $thumb_id = get_post_thumbnail_id();
	the_post_thumbnail( $size ); // whatever size you want
}

By tossing a div around that, you can then float it left, or right, or whatever you prefer to do. With some extra code and the use of the get_children function, you can make this default to the first image in the gallery if they don’t choose a featured image.

else {
	$attachments = get_children( array(
		'post_parent' => get_the_ID(),
		'post_status' => 'inherit',
		'post_type' => 'attachment',
		'post_mime_type' => 'image',
		'order' => 'ASC',
		'orderby' => 'menu_order ID',
		'numberposts' => 1)
	);
	foreach ( $attachments as $thumb_id => $attachment )
		echo wp_get_attachment_image($thumb_id, $size); // whatever size you want
	}
}

Using tricks like this, you can get the bits of the gallery yourself and display them in different ways.

Make a Gallery Specific Page Template

Matt’s Gallery Page is itself customized. It displays the galleries in an entirely different way. There’s a big copy of the featured image, along with a few thumbnails below the description, and it even has a count of the images in each “album”. This is all done with a pretty straightforward page template.

So to start, make a Page Template:

/*
Template Name: Gallery
*/

Right at the top of the template, we’re going to add a special taxonomy query, which will get all the gallery posts (as well those in the gallery category, since we’re being backward compatible and all). So here’s the code:

$args = wp_parse_args($query_string);

query_posts(array(
         'tax_query' => array(
                'relation' => 'OR',
                array(
                        'taxonomy' => 'post_format',
                        'terms' => array('post-format-gallery'),
                        'field' => 'slug',
                ),
                array(
                        'taxonomy' => 'category',
                        'terms' => array('gallery'),
                        'field' => 'slug',
                ),
        ),
        'paged' => $args['paged'],
) );

First we parse the normal arguments, then we override them with our own query. The only argument we really use from the normal set is the page number, for multiple paging.

Our overriden query uses an advanced taxonomy query. In this case, it selects any posts in the gallery post format, or any post with a category of gallery. By passing this to query_posts, we override our main page query, and thus our main Loop will now display the gallery posts only.

After this, it’s just a matter of displaying what we want to display.

The main Loop itself is pretty straightforward. To display that featured image, we use essentially the same code as we used before, only passing it a bigger size.

To display the description, we just use the_content() as per usual. One thing we have to do though is to set the global $more value to zero, so that it stops at the !–more– tag, preventing it from continuing to display the whole gallery.

Getting the count turns out to kinda suck. There’s no good function in WordPress to do this for you easily. So, reluctantly, I resorted to an SQL query.

echo $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->posts WHERE post_parent = '$post->ID' AND post_type = 'attachment'" ) .' PHOTOS IN THIS SET';

The four thumbnails you can do using the get_children trick. However, there’s a catch. We don’t want to display the featured image as one of those four thumbnails. So, since we’ve already displayed that image (see the code above), we have the $thumb_id variable still. So we’ll use that to not get that image. Like so:

$attachments = get_children( array(
	'post_parent' => get_the_ID(),
	'post_status' => 'inherit',
	'post_type' => 'attachment',
	'post_mime_type' => 'image',
	'order' => 'ASC',
	'orderby' => 'menu_order ID',
	'numberposts' => 4,
	'exclude' => $thumb_id )
);
foreach ( $attachments as $img => $attachment ) {
	echo '<a href="'.get_permalink($img).'">'.wp_get_attachment_image( $img, $size ).'</a>';
}

By using the exclude parameter, we can get the first four images in the gallery without getting that featured image again, if it’s in those first four images.

Update

Andrew Nacin pointed out that I can combine the act of getting those four children and getting the attachment count into a single new WP_Query, like so:

$images = new WP_Query( array(
    'post_parent' => get_the_ID(),
    'post_status' => 'inherit',
    'post_type' => 'attachment',
    'post_mime_type' => 'image',
    'order' => 'ASC',
    'orderby' => 'menu_order ID',
    'posts_per_page' => 4,
    'post__not_in' => array($thumb_id),
    'update_post_term_cache' => false,
) );

This creates a new secondary query that I can loop through like so, to show the children:

foreach ($images->posts as $image) {
	echo '<a href="'.get_permalink($image->ID).'">'.wp_get_attachment_image( $image->ID, $size ).'</a>';
}

It also has the side benefit of doing the primary counting of the images for me, via the SQL_CALC_FOUND_ROWS that WordPress uses in full-blown queries. However, the count will be off by 1, since we’re excluding the featured thumbnail. Therefore, I just have to add one to it:

echo ($images->found_posts+1) . ' PHOTOS IN THIS SET';

That combines both of those elements into one query instead of two, and eliminates the need for the direct SQL query.

(Side note: I also set ‘update_post_term_cache’ to false to prevent it from doing an extra query to get the terms for these posts into the internal memory cache. This saves us a bunch of unnecessary queries, since I’m not using the terms here anyway. Using full WP_Query objects instead of the simpler ones like get_children can take a little bit more thought and effort, but can save you time in the long run, if used wisely.)

Sizes

Throughout this post I’ve used $size as a generic indicator of where to put the size parameter. WordPress creates sized images by default, as we all know. These are thumbnail, medium, large, and full which is just the full sized uploaded image, unmodified.

But WordPress can create other sizes too, if you like. At different points throughout Matt’s gallery pages, you’ll see images displayed in all sizes. These sizes are custom, and they’re added in the functions.php file.

add_image_size( 'nav-thumbnail', 100, 100, true );
add_image_size( 'random-thumbnail', 200, 150, true );
add_image_size( 'gallery-thumbnail', 250, 200, false );
add_image_size( 'gallery-large', 660, 500, false );
add_image_size( 'gallery-pagethumb', 70, 70, true );

The add_image_size function takes a width, a height, and a flag to cause it to crop or not. So those tiny thumbnails on the gallery are “gallery-pagethumb” sized, and are 70×70, cropped. Anywhere I need one of those sizes, I can just pass that parameter instead of $size and voila.

Obviously though, adding too many sizes is undesirable, because it takes time to create those sizes (they’re created on upload of the images), and it takes storage space to store them. Hopefully a future version of WordPress can work around this issue.

Conclusion

These are the basics of making cool galleries, without plugins, without special uploaders, and while being able to style it to match your theme. Play with it. Experiment. There’s a ton of functions in WordPress specifically for dealing with these. Take a look through wp-includes/media.php and look at some of the function names. You might be surprised.

Saw a post over on the WordPress Stack Exchange site a while back, and though I sorta went into it in my answer there, I figured it would make a decent topic.

Custom taxonomies are great. But they’re not great for everything. When designing a custom solution, it’s helpful to understand this in advance, so you can choose what goes where properly.

What is a Taxonomy?

According to Wikipedia, Taxonomy is the practice and science of classification. I like this definition a lot, because it really points out what you’re doing with taxonomies. You’re classifying things. Or better yet, grouping them.

That word is important: Grouping. You’re putting things into groups. The taxonomy is the sum of those groups.

In the case of WordPress, you’re putting posts into groups. Maybe they’re custom post types of some kind (actually, they probably are if you’re doing it properly), but they still fit into the wp_posts table, so lets call them posts. You’re grouping posts together.

Categories group posts together. Tags group posts together. The way that these two are used is somewhat different, but that’s the basic end result here, right?

The group itself is the important bit. Not the term, the term you use for that group is just a label. It has no real significance whatsoever.

Now, I know that we often display the term, and I think that this is what confuses people. The category or tag is probably a word, in English (or your own language), and words have meaning. So yes, it does matter when I add “php” as a tag, or use the “Rants” category. But what’s important to realize is that that word only has meaning to people, not to the computers, and certainly not to our data design.


Enter Postmeta, Stage Left

Let’s say I’m building a new site, and I want to make, say, television shows be a custom post type. TV Shows are a pretty good choice for this example, as well as what the original SE question was about.

What makes sense as a taxonomy for a TV Show? Title? Actors? Episode numbers? Season numbers? For each item, you need to consider whether it makes more sense as a taxonomy or as pure post meta, or (rarely) both.

Titles makes perfect sense for a taxonomy. You’re grouping all the episodes of that show together, and people will want to see an episode listing. So yes, it’s a taxonomy.

Actors also makes sense as a taxonomy. Actors act in many roles, it would be nice to see what various shows and episodes they’ve been in.

Season and Episode numbers is another one. Every show has it’s own season and episode number. Usually this is represented as Season 1, Episode 1, sort of thing. At first glance, season numbers kinda makes sense as a taxonomy, since you can pull all of season 1 out. But on further reflection, no it doesn’t, because it doesn’t stand alone. Every TV series has a season 1. We don’t want to pull out all season 1 shows from all series, it’s not something we’ll need to do. Same goes for episode numbers, when are we going to make a query based on episode numbers, to get all the first episodes of all shows? Makes no sense. These should be postmeta (or “Custom Fields” as some people insist on calling them).

The difference is one of grouping. For Titles and Actors, we’re grouping individual things together in a meaningful way that stands alone. Sure, our labels (terms) will have meaning to us humans, but not to the act of the grouping itself. The group is a natural one. For seasons, the grouping is meaningful, but less so because it’s shared among non-similar things (different shows). It doesn’t stand alone. You could get around that by saying that your term would be title-season# or similar, but it really makes more sense as postmeta, since the season and episode number, taken together, are unique to the item we’re storing.

Postmeta as Unique Information

That’s the difference: Postmeta is bits of information that are specific to the post item itself. Taxonomies are bits of information shared, in a meaningful manner, by many different items. Title is shared across all episodes of a TV Show, and defines a meaningful relationship to all those episodes. Season number is shared, but it’s not meaningful because all shows have similar season numbers.

Notably, there’s easy ways to order by postmeta, but not by a taxonomy. Ordering by a taxonomy makes no real sense, because lots of items will share the same terms in that taxonomy. If I have 20 items all with “foo” as a term in a taxonomy, then what am I ordering them by? They’re all “foo” items.

As for querying, I can query based on either postmeta or taxonomy, if I really want to. Ideally, I’d do both. For example, if I wanted Firefly, Season 1, Episode 13, then I could specify both a tax_query for title and a meta_query for “S01E13″ and get that one unique item. If I wanted all episodes of it in order, then I specify the tax_query for title and the meta query to select the season/episode metadata, then use the orderby to put them in the right order.

Choose Wisely

So if I can query by them both, but only order by postmeta, then what’s the difference? Why not use postmeta for everything?

Speed. Querying for a taxonomy is loads faster than querying for posts with certain meta information. Even better, I can use both to make things even speedier. The meta_query for S01E13 is going to be loads faster when I specify that title taxonomy, because now it’s only looking for S01E13 amongst Firefly episodes, not amongst all episodes of all shows.

The bottom line is that it’s best to use a taxonomy for attributes that a) define a natural grouping of your items, and b) which are natural labels and not inherently useful data to your methods. The title is not inherently a useful data (it’s just text, could be anything), but the episode number is a number which you will want to order by and display/change/set. You use that episode number for doing something.

Also, it’s perfectly understandable for individuals to disagree on any given example. There is no “right” answer, there’s only the answer that satisfies your own personal use cases. When designing your taxonomies, just remember to think about grouping of items and how you’re going to use the data you’re defining. If it’s a group in how you are going to use it, then a taxonomy works better than postmeta. But if you need the attribute to be manipulated in some manner, then a postmeta works better.

This portfolio site is for multi-disciplinary designer Elisa Cachero, and shows her design work in textiles, art direction, print & web design, and event planning.

It uses the WordPress engine with the popular portfolio theme Autofocuspro . Urban Legend web was contracted via wpquestions.com to update that theme so that;

  • the front page displays in the way usually used for category pages
  • the number of posts shown beneath the feature image on the home page is limited
  • copyright information can be included on single post pages which use the JQuery image slider
  • the default ‘next’ and ‘previous’ post arrows on the front page are hidden
  • show front-page post titles only on mouse hover

Via the wpqestions.com site, I’ve now worked on a number of WordPress autofocuspro installations, and invite further queries relating to that theme.

This site is te-awa.org.nz, The Great New Zealand River Ride, an outdoors project based on New Zealand’s largest rvier, the  Waikato.

Urban Legend web was contracted by Cube Media to install and configure wordpress, code an original theme using that publishing platform, and based on supplied graphics, and add functional extensions.

The site features a JQuery slider on the front page, a JQuery-based drop-down menu, custom widgets, and customised plugins, including a subscription service.