Tag Archives: WPMu

New BuddyPress plugin: Enhanced BuddyPress Widgets

I just posted at the CUNY Academic Commons Dev blog about a new plugin I’m releasing for BuddyPress. The plugin adds two new widgets to your BP/WP install – Groups and Members – which duplicate the functions of the core widgets of the same name, with the added feature that users can choose whether the default view will be Newest, Active, or Popular.

If I can think of other ways in which those widgets could be enhanced, I might add them to the plugin in the future. If you can think of some ways, please let me know.

Why are you still reading this? Go download the plugin already, and enjoy having my name on your WordPress plugins page yet again.

Sitewide Tag Suggestion in Wordpress MU 2.8+

A recent project of mine has been to improve the “Choose from the most popular tags” button that’s built into the Wordpress edit post screen. The default behavior is to find the most frequently used tags from the current blog. My goal is to add a link that lets you select from frequently used tags across the entire Wordpress MU installation. It’s an idea that Matt Gold gave me. Aside from being kind of gimmicky and neat, such a feature might facilitate the emergence of a more unified folksonomy in a community. In other words, the ability to see what tags other people are using for their posts makes it more likely that I’ll use the same tags that you use when we post about similar things. In this way, we can avoid having people tagging their posts “Wordpress”, “WP”, “Wrdprss” as if these were different things.

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

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,
      [sourcecode language=”php”]$tags = get_terms( $taxonomy, array( ‘number’ => 45, ‘orderby’ => ‘count’, ‘order’ => ‘DESC’ ) );[/sourcecode]
      must be replaced with the corresponding get_terms_custom declaration:
      [sourcecode language=”php”]$tags = get_terms_custom( $taxonomy, array( ‘number’ => 45, ‘orderby’ => ‘count’, ‘order’ => ‘DESC’, ‘blog_id’ => 28 ) );[/sourcecode]
      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:
    [sourcecode language=”php”]

    [/sourcecode]
    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!

Sharing hacks

Open Ed 09 just ended, and I’ve got lots of things to blog about. Here’s a quick one that came out of a conversation that I had this morning with some of the guys from UBC’s Office of Learning Technologies (Enej, Michael, and Alex, if I’m remembering correctly).

The conversation started off as a show-off session of the different things we were doing with the combinations of WPMu, BuddyPress, MediaWiki, and so on. After some oohing and aahing (that’s what I was doing, at least), we turned to the question of why we – groups of people doing such complementary stuff – aren’t in better contact with each other. Finished, polished stuff is pretty easy to share, through outlets like the WordPress plugin pages. Only sharing the big stuff, though, means only helping each other a fraction of what we could. After all, things that have been formally released are bound not to need as much input from the community as unfinished, rough code. Moreover, arguably, our days are consumed as much by the small hacks and workarounds as they are by the big plugin projects.


cc licensed flickr photo shared by Stevie Rocco | Drinking this coffee got me giddy about sharing code

Communication about code is a hard thing. On one end of the spectrum is internal communication. The gang at OLT keeps internal notes of the small hacks they do on their system, as do we at the CUNY Academic Commons. On the other end is end-user documentation, meant for a broad and largely non-technical audience. The kind of communication that’s missing here is the stuff in the middle, between groups doing similar sorts of work.

What are some good ways to get this kind of sharing moving? What we’re trying to do at the Academic Commons is to keep a development blog. The success of this strategy is limited by a couple factors, though. First, other people have to know where the blog is, and add its feed to their readers, to glean any benefits. Second, a dev blog is only as good as what you post to it, and I for one have a real tendency to think that lots of things are simply too small to bother with. As a result, only the big things tend to get posted – but then we run up against the problem I mention above.

So here’s a rule that I’m setting for myself: If an issue/hack/workaround/patch/spitshine takes more than two hours for me to figure out, I’m going to blog about it. The more I put out there – even if I think that it’s not all that significant – the more likely someone else is to find it and make use of it.