Once you’ve happily tagged your pages using Page Tagger you need to edit your theme’s page.php template. This is the template which gets used by WordPress whenever you view a static page (as opposed to a blog post) on your site. Inside this file you should have a section resembling “The Loop”:

<? php if (have_posts()) : while (have_posts()) : the_post(); ? >
...
<? php endwhile; endif; ? >

Inside this section you need to place a call to the the_tags() template method. This will output your page tags at that spot with some default formatting. Read the documentation for the_tags() for information on changing how it works. You can also use alternative functions such as get_the_tags()or get_the_tag_list() to achieve a similar effect.

If for some reason your page tags still aren’t showing on your page then please get in touch as it maybe a bug in the Page Tagger plugin.

Also, I’ve put up a few Java classes I wrote a while back as a small library called Common-Utils. Included within are the following:

• ArrayUtils – Utility methods to fill an array with a given value or check if it contains a given value.
• DynamicArray – A resizable “static” array for when you don’t quite need the full flexibility of ArrayList.
• NonMutableIterator – Wraps around a normal Iterator and disables use of the remove method.

Grab it now from here or the WordPress plugin repository.

Some users were reporting that the tag editing interface was unusable when used in conjunction with certain other plugins (e.g. the multi-level navigation plugin). Other users were having trouble getting the plugin to work in the latest version of WordPress (2.8.6). This release (hopefully) fixes these issues.

Grab it now from here or the WordPress plugin repository.

Update (Nov20): The plugin has been updated to 0.3.3 now. This fixes a callback bug which was preventing the plugin from initialising on certain installations.

First of all, there is no search box on my site just now because 1) I didn’t think I had enough content to warrant this, and 2) I tag all the content I create quite extensively. So my archives view doesn’t handle search results. Nor does it handle querying for specific dates, categories or authors. But I do handle querying for tags. Secondly, all the relevant template files from my theme for making this work can be found at the bottom.

Initial archives view

From the WordPress theme developer documentation we know that we should provide an archive.php template file in our theme folder to handle the viewing of blog archives. I’ve implemented this for my theme. It gets shown when you click the Archives navigational button at the top of the page. In order for WordPress to know that it needs to show this page when you visit /archives I have the following placed in my template’s page.php:

if ('archives' == SITE_SECTION)
{
    require_once('archive.php');
    exit;
}

(The SITE_SECTION constant tells me which top-level site-section the user is currently in. This is linked to how I generate the navigational links at the top – the code for this is in my theme’s functions.php).

I then create a publicly-viewable static page called ‘Archives’ and leave it empty, ensuring that its URL path is set to /archives. Now whenever someone visits this URL they get shown the contents of the archive.php template.

Inside archive.php I use the wp_tag_cloud() method to display a cloud of the most popular tags. I then have the following section of code to display all the posts, grouped by month:

    // get all posts in descending date order
    query_posts('posts_per_page=10000&orderby=date&order=DESC&post_type=post');

    $list_of_posts = array();

    // split entries into blog posts and static pages
    while (have_posts())
    {
        the_post();
        global $post;
        $list_of_posts[] = $post;
    }

    // show them
    require_once('archive_show_posts_by_month.inc.php');

The archive_show_posts_by_month.inc.php script does exactly what it says on the tin. It takes the $list_of_posts array and outputs the posts, grouped by month. Now you might wonder why I’m calling query_posts and performing a database fetch. It’s because by default WordPress has only fetched the contents of the static page located at /archives since that’s what it thinks is being displayed to the user. So in this code I fetch all the blog posts from the database (if you have more than 10,000 blog posts then by all means use a larger number in the query).

So that’s the display of the initial archives page done. Now for the tag-specific archives (example)…

Archives for a given tag

At the top of archive.php I have the following code:

global $wp_query;
$qry_tag_name = $wp_query->query_vars['tag'];
if ('' != $qry_tag_name)
{
    require_once('archive_results.php');
    exit;
}

When you try to view the archives for a specific tag WordPress will automatically invoke the archive.php template. This code then checks to see if you’re viewing a specific tag rather than viewing the initial archives page. If so, it invokes the archive_results.php template. Inside this template we have the following code:

// get proper tag name
$tag_name = single_tag_title("", false);

<?php if (have_posts()) : ?>

<?php
    $list_of_posts = array();
    $list_of_pages = array();

    // split entries into blog posts and static pages
    while (have_posts()) :

        the_post();
        global $post;
        if ('post' === $post->post_type)
        {
            $list_of_posts[] = $post;
        }
        else if ('page' === $post->post_type)
        {
            $list_of_pages[] = $post;
        }

    endwhile;   

    ?>
        <div class="results_pages">
            <p class="description">
                All pages tagged <strong>'<?php echo $tag_name; ?>'</strong>:
            </p>

            <div class="indented">
    <?php
        require_once('archive_show_pages.inc.php');
    ?>
            </div>

        </div>

        <div class="results_posts">
            <p class="description">
                All blog posts tagged <strong>'<?php echo $tag_name; ?>'</strong>, from newest to oldest:
            </p>

            <div class="indented">

    <?php
        require_once('archive_show_posts_by_month.inc.php');
    ?>
            </div>

        </div>

<?php else : ?>

        <p class="description">
            No posts tagged <strong>'<?php echo $tag_name; ?>'</strong> were found.
        </p>

<?php endif; ?>

This code splits the list of entries (already loaded by WordPress since you’re viewing tag-specific archives) into static pages and blog posts. It then calls archive_show_pages.inc.php and archive_show_posts_by_month.inc.php to display each set of entries one after another.

Files

Template files from my theme: ZIP file.

If you’re interested in sharing your own plugins with the WordPress community the instructions and FAQs are available at http://wordpress.org/extend/plugins/about/.

Update (Sep16): The plugin is now available in the WordPress plugin directory at http://wordpress.org/extend/plugins/page-tagger/

This plugin requires PHP 5 and WordPress 2.8.4. It has been tested on upto WordPress 3.0 RC1. An older version of the plugin is available below for WordPress 2.7 users.

WordPress plugin page: link.

License: GPL 3.

Current version: 0.3.6

Skip to: Installation Usage Changelog

Installation

WordPress 2.7

1. Download Page-Tags 0.2.
2. Unzip it into your WordPress plugins folder such that the plugin files are at wp-content/plugins/page-tags/....
3. Enable the plugin within your blog’s administration options.
4. All done!

WordPress 2.8.4 and above

1. Download the latest version from the WordPress plugin directory page.
2. Unzip it into your WordPress plugins folder such that the plugin files are at wp-content/plugins/page-tagger/....
3. Enable the plugin within your blog’s administration options.
4. All done!

Usage

To add tags to a page simply edit the page. You will see a tagging box on on the right-hand side which works exactly like the one you see when you edit a blog post. It should look something like this (assuming you’re using the default admin theme for WordPress 2.8):

Furthermore, when viewing the archives for a given tag you will now see the associated pages as well as the blog posts: Example.

Page tags will also appear within the tag cloud widget.

Changelog

• 0.3.6 (Jun 8, 2010)
  • The plugin now works with WordPress 3 RC1.
• 0.3.5 (Jan 16, 2010)
  • When clicking ‘Preview’ button ‘Add new tag’ no longer gets added as a tag
  • Updated documentation
• 0.3.4 (Dec 20, 2009)
  • Fixed to work with WordPress 2.9
• 0.3.3 (Nov 20, 2009)
  • Fixed callback bug which was preventing the plugin from initialising on certain installations.
• 0.3.2 (Nov 18, 2009)
  • Fixed plugin conflict issue which was sometimes causing the tag editing interface to stop working.
• 0.3.1 (Sep 8, 2009)
  • Plugin renamed to Page Tagger
• 0.3 (Sep 8, 2009)
  • Plugin now works in WordPress 2.8+.
  • If your page tags were no longer showing in tag clouds then you need to upgrade to this version (0.3) and then follow instructions to restore the correct post counts for each tag.
• 0.2 (Apr 3, 2009)
  • Fixed a bug which was preventing tags added whilst editing pages from appearing in the tag cloud widget.
• 0.1 (Jan 18, 2009) – the initial release.

Under the previous version of Page-Tags (0.2) upgrading to WordPress 2.8 may have caused your page tags to no longer appear in tag clouds. To rectify this install the latest version of the plugin and then re-save (edit and save without making any changes) all your pages. This will correct the post counts for each tag, which in turn will cause your page tags to show up again in tag clouds.

Note: Page-Tags 0.3 is not backwards compatible with WordPress 2.7, so if you’re running the older version of WordPress please stick to using Page-Tags 0.2.

Update (Sep8): The plugin has been renamed to Page Tagger. And it requires WordPress 2.8.4 to function correctly (thanks Leo).

Update (Sep15): Instead of editing and re-saving all your pages to update the post count you can simply run the following query in your MySQL database (replace wp_ with the appropriate prefix for your database tables):

UPDATE wp_term_taxonomy t set count=(SELECT COUNT(*) FROM wp_term_relationships r, wp_posts p WHERE p.ID = r.object_id AND (p.post_type = 'post' OR p.post_type='page') AND r.term_taxonomy_id = t.term_taxonomy_id)

This issue has now been fixed in the latest version. To get the tags you’ve already added showing, install the updated plugin, and then edit and save the corresponding pages without making any changes. For the developers among you, the cause of this bug is situated the callback function used to calculate how many posts are linked to a given tag:

function _update_post_term_count( $terms ) {
    global $wpdb;

    foreach ( (array) $terms as $term ) {
        $count = $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(*) FROM $wpdb->term_relationships, $wpdb->posts WHERE $wpdb->posts.ID = $wpdb->term_relationships.object_id AND post_status = 'publish' AND post_type = 'post' AND term_taxonomy_id = %d", $term ) );
        $wpdb->update( $wpdb->term_taxonomy, compact( 'count' ), array( 'term_taxonomy_id' => $term ) );
    }
}

As you can see it only counts blog posts. Page-Tags 0.2 simply replaces this callback function with one which also counts pages.

Note: The sidebar tag cloud widget will only show the top 45 tags (see the documentation for the wp_tag_cloud function).

And behold – the Server-Info plugin. Once enabled it will display a floating box at the top-left-hand corner of the webpage, containing the hostname and IP address of the webserver. The box will remain in that position, even when you scroll the page:

Note: You can change the look and feel and layout of the box by editing the CSS file that comes with the plugin.

By default the information box only gets shown when viewing an administration page. But in the administration options for the plugin you can set it to show on blog pages too, with the ability to restrict this to e.g. when the user is logged in.

Questions and comments are welcome.