Related posts:

1. Sitewide Tag Suggestion in Wordpress MU 2.8+
2. Making Sitewide Tags work
3. Custom Profile Filters for BuddyPress

It looks like the developer of Simple Tags is going to be working this sort of functionality into an upcoming version, but it’s not nearly as fun to just use someone else’s version if you can hack one out yourself.

Sitewide Tag Suggestion

I got it working through a series of hacks and plugins. I’ll describe some of the details below, enough so that you should be able to get a similar setup on your own system. A caveat: I can only attest to the setup (I’ll call it Sitewide Tag Suggestions, or STS) on WPMU 2.8.2, the sandbox version I’m running. The only production version I’ve got access to – the CUNY Academic Commons – is running a version of 2.7. Between 2.7 and 2.8 there were pretty significant changes to the way that the admin AJAX works, and I haven’t yet figured out how to make these changes stick on 2.7. (Moreover, I’m wary of sinking a bunch of time into retrofitting an outdated version of WPMU.)

STS starts off with the plugin WordPress MU Sitewide Tags, which I blogged about recently. Conceptually, the idea is simple. Sitewide Tags creates a blog that aggregates all posts from across the installation. From the tags blog one can then collect tags that reflect all sitewide activity. To make STS work, then, one simply has to duplicate the core WP tag suggester, altering it to pull the most popular tags from the tags blog, rather than from the current blog.

I managed to get some of the key functionality into a standalone plugin. You can download the plugin here. A quick rundown of this plugin’s contents:

• get_terms_custom is really the heart of STS. It’s a modification of WP core’s get_terms (in wp-includes/taxonomy.php) that allows for an additional argument: blog_id. This allows you to pull taxonomy terms (like tags and categories) from any blog on a WPMU install.
• sitewidte_tags_selection is the PHP function that writes to the header of the WP admin screen the jQuery function tagCloud2. tagCloud2 is the function that listens for the user to click on the “Choose from the most popular sitewide tags” link, and then posts the AJAX request for the proper tags.

STS has two more parts, one of which could probably be moved into the plugin proper, and one of which probably has to remain a core hack. I’ll cover them in turn.

1. tagCloud2 sends an AJAX request to the server with the action name ‘get-tagcloud2′ (can you tell that there was a lot of cutting and pasting from the core?). The code for the AJAX response is put into wp-admin/admin-ajax.php. It’s basically a copy of the get-tagcloud function already in admin-ajax.php. That means you should copy everything between case 'get-tagcloud' : and break; roughly lines 568-600, making the following changes:

   • change ‘get-tagcloud’ to ‘get-tagcloud2′;
   • the line that declares the variable $tags,

     $tags = get_terms( $taxonomy, array( 'number' => 45, 'orderby' => 'count', 'order' => 'DESC' ) );

     must be replaced with the corresponding get_terms_custom declaration:

     $tags = get_terms_custom( $taxonomy, array( 'number' => 45, 'orderby' => 'count', 'order' => 'DESC', 'blog_id' => 28 ) );

     Don’t forget to replace “28″ with the blog_id of your tags blog.

   I am well aware that there are ways to add ajax responses in plugins, i.e. without hacking the core, but for the life of me I couldn’t get it to work. I imagine part of the problem is that back in tagCloud2, I’m replicating the core’s ajax syntax, while a plugin’s syntax has to be more explicit about where’s it’s sending its requests. (That’s what wp_ajax_ is for, I think.) So I’m chalking this one up to my own ineptitude and the fact that I have no idea how to work computers.

2. Finally, you’ve got to add some markup to the edit post page itself so that STS can actually be used. It’s possible of course to use WP’s hooks to add fields to the edit post page, but I really wanted to include the link right underneath the core “Choose from the most used tags” link. So I put the link in a core file, wp-admin/edit-form-advanced.php. Right after the code for the most used tags link, I added my own:

   <p class="tagcloud2-link hide-if-no-js"><a href="#titlediv2" class="tagcloud2-link" id="link2-<?php echo $tax_name; ?>"><?php printf( __('Choose from the most used sitewide tags'), $box['title'] ); ?></a></p>

   Be sure that each instance of tagcloud is changed to reflect the new ajax call (in my case, tagcloud2).

I think that STS has some potential to be really cool, especially if used in a community that is large enough for rich folksonomies to emerge. If you’ve got any suggestions about how to make it better, or how to fix any of my stupid errors, please don’t hesitate to leave a comment!

Related posts:

1. Sitewide Tag Suggestion, Part II, Sort of
2. Making Sitewide Tags work
3. Class blogrolls: No sweat

Sitewide Tags is a cool plugin by Donncha O Caoimh that pulls blog posts from all over a WordPress Multi-User installation – like the one here on the CUNY Academic Commons – into a supplementary catch-all blog. The power of this plugin is that, with all sitewide blog posts aggregated into one place, you can begin to see the kinds of topics and trends that emerge from the community of bloggers. More specifically, Sitewide Tags allows you to create a tag cloud that reflects blogging activity across the entire community. (See the tag cloud at Wordpress.com for a sense of what this looks like.)

I’ve got Sitewide Tags up and running here on the Commons – see our tag cloud (scroll down the page) and our aggregated blog. Getting things running seamlessly took a bit of tinkering though, and I thought it might be useful to share some of the tinkering here.

Read on for more of this (unexpectedly!) long process.

Theming and navigation

The appearance of the Commons’s main page is determined by a fairly heavily-modified version of the WPMU Nelo theme. The first step to integrating the tags blog into the rest of the site was to apply the Nelo style. Simply applying the Nelo style wholesale doesn’t work right, for a few reasons that I’ll discuss; the tags blog’s theme needs some modification. There are really two ways to accomplish this: (1) apply the same Nelo theme to the tags blog and then create new page templates that are customized for the tags blog, or (2) copy the Nelo theme, rename it (in the header of style.css), and make the necessary modifications to that theme’s template. Option 1 is probably the more streamlined and upgrade-friendly route, but of course I didn’t really think of this until I had pretty much finished the customization, so I went with option 2.

Perhaps the most important modification I made to the nelo-for-tags theme (as I, in a fit of extreme creativity, dubbed the copied skin) has to do with the navigation. On the main site, the nav buttons that appear directly below the CUNY Academic Commons logo are links that point to WP pages within that blog. An easy way to copy the nav into nelo-for-tags would be to copy and paste the nav markup into nelo-for-tags/header.php (in place of the wp_list_pages command) , but this is not very future-friendly: if we change the name or order of any nav pages in the future, we’d have to apply those changes manually to the tags blog. A bit of Googling led me to a solution. Dusty Reagan wrote a function that he calls wp_list_main_pages that pulls the navigation dynamically from the main site blog onto any other blog on the site. Brief instructions:

• place the function into nelo-for-tags/functions.php
• change the number in $wpdb->set_blog_id(1); (near the end of the function) to the id of your main blog – in our case, it was 1, which means that no change was necessary
• in nelo-for-tags/header.php, change wp_list_pages to wp_list_main_pages

A few things need to be done to clean up the nav. First: wp_list_main_pages imports nav links as relative links, which means that (for example) “Groups” points to http://tags.commons.gc.cuny.edu/groups instead of the correct http://commons.gc.cuny.edu/groups. So I added a line to wp_list_main_pages, immediately after the line that reads $output = str_replace("pressroom/", "", $output);, that looks like this:

$output = str_replace('http://tags.commons', 'http://commons', $output);


In other words, replace every instance of (the incorrect) ‘http://tags.commons’ in the nav bar to ‘http://commons’. Next, because wp_list_main_pages makes the nav import work by tricking WP into thinking that the current blog (tags) is actually the main blog, we need to end the ruse if we want further self-reference to work on the page. Immediately after the line just added, add another line:

$wpdb->set_blog_id(28);

where 28 is the number of your tags blog. Finally, there are some remaining places in the nav bar – places, in particular, where the nav structure is not determined by the pages on the main blog – where the href must be changed manually. Replace instances of <?php bloginfo('url'); ?> in header.php with the URL of the main blog (http://commons.gc.cuny.edu in our case). This final step is perhaps not all that elegant, but it’s far less likely that the URL of the home page will change in the future than that the main blog’s nav pages will change.

Other changes to the tags theme

On an aggregating blog, it’s helpful to include different information than what is included in the standard page template of a regular blog.

1. Blog title – Because the posts on the page will come from many different blogs, it’s helpful to include “From the blog…” information alongside the title of each post. Two things need to happen for this information to appear: (a) you have to make sure that the required data (the title and URL of the post’s original source blog) gets written to the tag blog’s db table; and (b) you have to call that information into the template. Here’s what I cobbled together:
   1. Open up the Sitewide Tags plugin (stored at /wp-content/plugins/wordpress-mu-sitewide-tags/sitewide-tags.php, if you’ve already installed it). Lines 179-183, or thereabouts, should read like this:
      

      $post->ping_status = 'closed';
$post->comment_status = 'closed';
$p = wp_insert_post( $post );
add_post_meta( $p, "permalink", $permalink );

      Replace these lines with the following code:

      $post_blog_table = 'wp_' . $post_blog_id . '_options';

$global_post_source = $wpdb->get_row( "SELECT * FROM $post_blog_table WHERE `option_name` = 'siteurl'" );
$source_blog_uri = $global_post_source->option_value;


$global_post_source = $wpdb->get_row( "SELECT * FROM $post_blog_table WHERE `option_name` = 'blogname'" );
$source_blog_name = $global_post_source->option_value;

$post->ping_status = 'closed';
$post->comment_status = 'closed';

$p = wp_insert_post( $post );
add_post_meta( $p, "permalink", $permalink );
add_post_meta( $p, 'siteurl', $source_blog_uri);
add_post_meta( $p, 'blogname', $source_blog_name);


      The short story of this code: every time Sitewide Tags kicks in (which is whenever a blog post is published across the site), the plugin goes to the source blog’s table, finds the blog’s URL and title, and writes it as metadata to the new post in the tag blog’s table.

   2. Next, open up nelo-for-tags/page.php (or whatever your theme directory is) and find the place where you want the “From the blog…” information to appear. (I like it right below the title of a given post – see our tags blog to see my positioning.) Insert the following code:
      

      
<?php if ( is_object($id) && isset($id->filter) && 'sample' == $id->filter )
$post = $id;
else
$post = &get_post($id);

$post_id = $post->ID;

if (get_post_meta($post_id, 'siteurl', true)) {
$source_url = get_post_meta($post_id, 'siteurl', true);
$source_blog = get_post_meta($post_id, 'blogname', true);

echo '<h2 class="tags-blog-title">From the blog <a href="' . $source_url . '">' . $source_blog . '</a></h2>';
}?>

   Keep in mind that your tags blog will only show the source blog data for posts that are created after this point – the plugin does not go back and find source blog data for existing posts. So you’ll have to create new posts to test this.

2. Tag-specific page titles – In nelo-for-tags/home.php – the template that creates the main page at http://tags.commons.gc.cuny.edu – I added a page header just after the line <div id="post-entry">, so that visitors would know what this site was all about:
   

   <h1>Sitewide Posts</h1>
<h3>New blog posts from across the CUNY Academic Commons</h3>

   For nelo-for-tags/index.php, which creates the pages corresponding to specific tags (like this), I thought it would be helpful to include the tag itself in this header. So I inserted the following instead:

   <h1>Sitewide Posts - <em><?php wp_title(''); ?></em></h1>
<h3>New blog posts from across the CUNY Academic Commons</h3>

Tweaking the tag cloud

I wanted the sitewide tag cloud to be widgetized, so that we’d be able to put it on our News page, as well as anywhere else on the site that we might like. Sitewide Multi Widget by dsader is a flexible way to get this done. Once you’ve activated Sitewide Multi Widget, you can add it through Dashboard > Appearance > Widgets to any blog on the site.

I made a tweak to Sitewide Multi Widget code so that it would display all tags in the cloud, instead of the default 25 or 40 or whatever it was. Here’s how: Find the line that includes wp_tag_cloud(); (around line 112). The WordPress Codex URL in the comment http://codex.wordpress.org/Template_Tags/wp_tag_cloud has all the details about this function’s options. I changed mine to

wp_tag_cloud('number=0');

which displays all tags.

As it’s now configured, I think that the tags blog, and the sitewide tag cloud that it supports, is poised to be a real discovery engine for members of our community. I can envision putting the tag cloud widget in lots of places all over the site. I can also envision getting more information into the tags database – once BuddyPress supports tags natively, for instance.

I hope that someone out there can get some use from some of this information!

Related posts:

1. Making Userthemes work on WordPress 3.0
2. Sitewide Tag Suggestion in Wordpress MU 2.8+
3. Sitewide Tag Suggestion, Part II, Sort of