Tag Archives: CUNY Academic Commons

Upgrading from BuddyPress 1.0 to 1.1

· 2 Replies

The upgrade from BuddyPress 1.0.x to BuddyPress 1.1 on the CUNY Academic Commons posed a number of challenges. Between the big changes to theme structure, the one-click installation of bbPress forums, and ongoing plugin compatibility issues, a lot of planning and testing was required. This week, I and the rest of the CAC development team finally made the switch. Over the course of a few practice upgrades in development environments, followed by an upgrade on the production site, I developed a pretty detailed set of instructions for myself. I thought I’d write up an annotated version of those instructions, for the benefit of anyone who might be facing a similar upgrade.

The Academic Commons had previously been set up roughly along the same lines as Jim Groom describes here: with bbPress storing its data in a separate database, but through the cunning use of various clever plugins, sharing user data, cookies, and BP group info with the WPMU installation. BP 1.1 does things differently: the one click installation of BP forums expects to store its data in tables that exist in the BP/WP database. In order to save the old data, we had two choices: move the old data into the new structure, or make BP 1.1 recognize the old db setup. Fellow dev team member Chris Stein and I decided that the former choice would be the easiest and most future proof. Here’s how it was done.

    Dealing with bbPress forums

  1. Move orphan forums into groups. Strictly speaking, this doesn’t have to be done first, but if you’ve got bbPress forums that aren’t attached to groups, you’ve got to get them in a group in order for them to display in BP. To the best of my knowledge, there’s no really way to do this from the bbPress or BP admin panels, but it’s easy to do manually. Set up a new group for each forum (a “Help” forum might get a “Help” group, for example), make sure the group has discussion forums enabled, and then find the line in table wp_bp_groups_groupmeta corresponding to the group_id of the new group and meta key `forum_id`, and change the meta_value to match the forum number of the orphan group. Rinse and repeat.
  2. Export your bbPress database to a local file.
  3. Replace HTML markup. bbPress (my installation at least) stored formatting in HTML. The most common markup has to do with line breaks: bbPress interprets a single line break in a forum post as <br />, and double line breaks as </p> and <p>. Opening the local version of the bbPress db in a plain text editor, I did a couple big search-and-replaces:
    • </p>\n<p> became nrnr (redundant UNIX newlines)
    • Some <p> and </p> tags still remain (single paragraph posts), which I replaced with an empty string
    • <br /> became nr

    You’ll also need to make sure that all references to tables in the SQL dump are replaced with the proper names. For me, that meant replacing things like bb_posts with wp_bb_posts, but it might be different depending on the prefixes you use for bbPress and WP. If you’re not sure about how BP will name the tables, do the one-button forum setup in BP 1.1 (as a new installation) and post a test forum item, to make sure the forums get created. Then check out the database to see how BP formats table names on your install.

    4. Upgrading

    The instructions at buddypress.org are quite helpful. Here’s a short version:

  4. Deactivate BP-dependent plugins. I once neglected to do this. If you do, and then deactivate BP, there is a very good chance that your entire site will go white-screen-of-death, as the plugins will be making reference to BP functions that do not exist. Check your plugin list three or four times to make sure you’ve deactivated each one that has to do with BuddyPress. I like to make a list, so that I remember which ones to activate after the upgrade (though some, like the bbPress integration plugins, won’t be necessary).
  5. Back up all your data. Always! I like to take a snapshot of the whole database, and then an individual export of the wp_sitemeta table. That way, if I screw anything up (say, by deactivating plugins in the wrong order!) I can bring the site back to life by reverting to a previous state that is known to work.
  6. Upgrade BuddyPress. Deactivate, upload, reactivate.
  7. Reactivate BP dependent plugins. I didn’t have too many issues with plugin compatibility, but you might, depending on what you use. Some plugins will not be necessary anymore, while others (like Forum Attachments for BuddyPress) become useful.

    8. Themes

    The CUNY Academic Commons was in the midst of a redesign, so it made sense to have the new design implemented in BuddyPress’s new, parent-child theme environment. Buddypress.org has some instructions that you might find helpful. Our theme consists of a highly customized home page, header, and footer, with interior BuddyPress pages that are more or less similar in terms of markup to the BuddyPress parent theme. Thus it made sense for us to create a child theme in wp-content/themes (by copying and renaming the bp-default folder that comes with BuddyPress), make our CSS changes, and fill our child theme with only those templates where our markup had to differ from bp-sn-parent. For us that means home.php, header.php, footer.php, functions.php (which does not override but adds to bp-sn-parent/functions.php), and a few other miscellaneous files. How to implement:

  8. Rename bp-themes. If BuddyPress sees the bp-themes folder, it will assume that you’re going to use the older, deprecated theme structure. I renamed it to bp-themes-old, and will remove it altogether once we’re 100% done with the migration.
  9. Move bp-sn-parent, bp-default, and your child theme to the main WP themes folder. In most cases this is wp-content/themes.
  10. Activate the themes in Dashboard > Site Admin > Themes. No need to activate bp-sn-parent, since it’s not used directly.
  11. Apply the child theme of your choice (either bp-default or your custom theme) to the main blog.

    12. Setting up the forums

    You’ve exported and modified the forum data from the bbPress standalone version, but you’ll still need to get them into BP.

  12. Rename /forums. In our case, our previous installation of bbPress just happened to live at [BP install dir]/forums – exactly where the BP 1.1 forum directory goes. I don’t think it’d hurt anything to leave that folder named the way it is (because of the order in which BP handles URL arguments), but just to be safe I changed it to forums-old.
  13. Set up BP forums. In Dashboard > BuddyPress > Forum Setup, set up forums as a new installation.
  14. Drop the empty forum tables from the BP database. I can’t remember whether BP creates the forum tables upon installation or upon the first forum post, but in any case you won’t be able to import your old data properly without first dropping any table prefixed with wp_bb_.
  15. Import the modified local version of your forum data. I did it in PHPMyAdmin, which was easy because the file had been exported in the form of a huge INSERT command. If all goes well – and it should! – you should now be able to navigate to your groups and see the proper forum posts for that group.

There are kinks we’re still trying to work out of the system. Some strange things happened to some users’ avatars after the upgrade. And tweaking the theme is turning out to be a hassle in a lot of ways. But overall, the migration of data – which I had lost a bit of sleep over – went extremely smoothly. Good luck!

Sitewide Tag Suggestion, Part II, Sort of

· 1 Reply

If you are interested in the Sitewide Tag Suggestion plugin that I blogged about a few weeks ago, you might like to know that I have finally found some time to write up some proper instructions and implement the changes on the CUNY Academic Commons. If you’re interested, you can download the bugger from the Commons dev blog, and let me know what you think.

Sitewide Tag Suggestion in Wordpress MU 2.8+

· 6 Replies

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!

Empowering through openness – my application for the OpenEd 2009 travel scholarship

· 3 Replies

This blog post is my application for one of the travel scholarships to OpenEd 2009. Here’s how the prompt goes:

  1. What you would “bring” to the conference? What can you contribute, be it a willingness to volunteer to moderate a session, some special expertise or project, an already accepted proposal…
  2. What you see as the most critical issue facing you in your efforts around Open Education, and how you think the conference can help you address it?

I approach the subject of Open Education from two different angles. The first angle is a humanist one. I’m trained as an academic: I’m doing my doctoral studies in philosophy at the CUNY Graduate Center. This academic training fuels an interest in education, and especially the way that education might (or must) move toward openness as time passes. The second angle is a technical one. I’m (in the process of becoming) a coder and developer of web applications. Working primarily with open source applications like Wordpress, Mediawiki and Drupal, I’m developing an increasing sense of the user-empowering potential of open source software. These two angles on openness converge in my career in various ways, both in my day job as an instructional technologist at Queens College and as a developer for the CUNY Academic Commons.

As such, I think I could bring to OpenEd 2009 an interesting perspective on the nature of openness. As a user of – and contributor to – open source products, I can speak confidently to the community benefits that emerge when powerful tools are developed in an open way. And, more specifically, as someone who has used these tools toward both educational purposes (for example, in support of blogging initiatives both in my classes and in the classes of others) as well as in more broadly scholarly contexts (like the community of collaborative research that the CUNY Academic Commons is designed to foster), I have a concrete sense of the way in which openness in one realm – the realm of software – can foster and feed another kind of openness in the educational realm.

In service of these (somewhat abstract!) goals, I’m willing to participate in as many concrete ways as possible at the conference. I’m an active and energetic Twitter backchannel user (see, for example, the Twitter conversations I took part in at this year’s THATCamp, as well as my previous musings on the role of Twitter at conferences). In discussions both on and off Twitter, I can offer up experience both theoretical (I am a philosopher, after all) and practical (I’m also a geek). I’d also be happy to moderate a panel, if I were asked to do so.

As for what the conference will do for me, I envision that my attendance at OpenEd 2009 would help me to further bridge the gap between the practical and the technical that characterizes so many of the things I do in my career. As an instructional technologist, I think it can be easy to think of yourself as a purveyor and teacher of tools, tools that merely replicate the kinds of learning that have always happened in classrooms. This, after all, is often the path of least resistance. The challenge, I believe, is empower faculty members (and, ultimately, the students themselves) not only to use technology but to understand the extent to which it shapes the world and, by extension, ourselves; only by appreciating this can an individual engage with the technology in such a way that it expands (rather than controls) his or her humanity. Openness is the linchpin: students cannot make the connection between what happens in a class and what happens in the rest of their lives unless the window between the two is open. So I guess my goal is to see what kinds of practical approaches are being taken by people in positions similar to mine, in order to help faculty and students understand how they can empower themselves by embracing openness.