Commons 1.2.1

I’ve just released Version 1.2.1 of the CUNY Academic Commons. This is a bugfix release for the Commons, comprising a number of fixes and small improvements. Of note:

  • LaTeX support for MediaWiki (just embed your TeX in <math>TeX</math>
  • Improved support for group invitation autocomplete in newer versions of IE
  • Fixed bugs in WP Flickr Photo Album plugin
  • New WP theme: Erudite
  • New WP plugin: Twitter Blackbird Pie

For full details on the release, see the 1.2.1 milestone.

The technical side of Commons v1.0

As Matt @admin announced earlier today, we’ve just tagged the CUNY Academic Commons “version 1.0”.

The 1.0 milestone represents a couple of big changes in our development processes.

  1. Versioning

    The most obvious change is the use of version numbers. It might seem at first like a relatively minor and superficial alteration in the way we operate. In truth, it’s a big change.

    Prior to the switch, our development cycles were haphazard at best. Bugs would be fixed and features implemented whenever someone on the development team happened to get around to it. That system (or lack thereof) works pretty well for a small team. But the team behind the Commons has been growing steadily over the past year, both in sheer number and in breadth (of geographical distribution, of areas of technical expertise, of responsibility). Greater distribution requires more thoughtful coordination and communication, and releasing discrete versions is a tool that we hope will help us achieve these goals.

    There are many benefits to discrete versioning. Here are a few prominent ones, off the top of my head:

    • Improved ticket management · Our ticketing system works best when tasks can be clearly assigned to individual developers, and organized according to priority. Version numbers provide a framework for this kind of management, as important tickets get assigned to earlier versions, and developer workload balance for a given release can be easily assessed.
    • Improved roadmapping · Roadmaps – software development language for “schedule of upcoming features” – are easier to understand and to implement when they’re organized by release numbers instead of thrown into a single pile.
    • Improved testing · When features and bugfixes are rolled out one-at-a-time, it can mean near-nonstop testing for the development and community team. Having controlled releases means that testing for a whole set of changes can be managed at the same time, in the days leading up to the release itself. That’s a better use of everyone’s time.
  2. Better distinction between development, staging, and production

    In those halcyon days early in the life of the Commons, nearly all development was done in the live production environment. When fixing a bug or launching a feature, I’d edit the site while it was up and running. Danger, Will Robinson! So many things can go wrong when you’re editing a live site, it’s hardly worth enumerating.

    The dev team eventually did set up a development environment. But it was running on a different server from the production site, and so you could never be guaranteed that a fix on the dev site would translate to the live site. Moreover, all those little fixes that would get sneaked directly onto the production site meant the dev site and the production site got progressively more out of synch as time went on, until the dev site was sufficiently different from the live site to be next to useless as a development site.

    Our new setup is much more sophisticated and, we hope, more conducive to quality development. We have a staging environment running in exactly the same operating environment as the production environment. Development environments are all local, which is to say that each member of the development team has a functional copy of the site on his personal computer. To whatever extent possible, development takes place in those local environments, is tested in our staging environment to look for environment-specific bugs, and only then pushed to the production environmnet. The (lofty) goal is that we’ll never have to make tweaks directly to the production site.

  3. Version control

    By “version control” I mean something a bit different from (though related to) “versioning” as mentioned above. Version control is a way to keep track of every change made to the files. It used to be that, when I tweaked a template or plugin file, unless I made a backup, the previous version would be overwritten and lost. Now that we’re using Git, we can always revert changes if need be (or browse the source out of mere historical curiosity!).

    The need for version control is all the more pressing as our development team grows. It’s important to keep track of who is changing what. And when you have local, independent development environments, it’s imperative that you have a way of making sure that the changes that I make on my version are not overwritten by the changes made by another member of the team when we merge them together in the staging environment. Git is designed for this kind of distributed development, as it keeps careful track of who edited what (‘git blame’, appropriately enough) and allows graceful merging of disparate edits.

    Using Git with WordPress and MediaWiki posed something of a technical challenge. For one thing, we wanted to track the entire codebase, but not files that users had uploaded to the system. Furthermore, MW and WP store crucial configuration information in the database, which is not tracked by Git. Finally, in order for local development environments to work properly, some environment-specific variables (database passwords, for instance) needed to be abstracted out of tracked files like wp-config.php. Zach at Cast Iron Coding forged a path through this jungle, and we’ve come up with a system that allows us all to keep our versions in sync using Git. In the future, I hope to write in a little more techinical detail just how this works.

    We use Git not just in our local development environments, but on the staging and production servers as well. For instance, when a release candidate has been vetted in the staging environment and is ready to go live, it’s extremely easy to launch the version on the production site: I simply shell into the production server and git pull or checkout the tagged version from the repository.

New BuddyPress plugin: BP External Activity

Here on the CUNY Academic Commons, we have an installation of MediaWiki which runs alongside our WordPress/BuddyPress installation. Without some additional coding, edits on the wiki don’t show up in the Commons News feed, and as a result they tend to get a little lost in the shuffle. This new plugin, BP External Activity, addresses this issue by allowing the administrator of a BuddyPress installation to specify an arbitrary RSS feed whose items will be regularly imported into the activity stream.

The plugin imports RSS feeds every hour. You may find that you need to decrease your Simplepie cache time to make it work:
add_filter( 'wp_feed_cache_transient_lifetime', create_function('$a', 'return 600;') );
reduces the RSS cache to ten minutes, for example. Put that in your bp-custom.php file if you are having problems with the plugin.

At the moment, the plugin uses the Author field from the RSS feed to look for a matching author in your WP database. If it doesn’t find one, it uses the unlinked text ‘A user’, as in ‘A user edited the wiki page…’.

Thanks to Andy Peatling, whose External Group Blogs served as the inspiration for a good part of the code.

Visit the plugin homepage for more details.

Displaying the BuddyPress admin bar in other applications

By popular demand, here’s the method we used at the CUNY Academic Commons to get the BuddyPress admin bar to appear on the non-WP/BP portions of our site. In our case, that means MediaWiki and bbPress, but theoretically this method could work for any kind of software out there.

I should note that I did not devise this method. It was invented by the inimitable Zach and Lucas of Cast Iron Coding.

The concept is as follows. A bit of jQuery looks for a div of a certain ID on a page and, when it finds it, opens a dummy WP page that contains essentially nothing but the BP admin bar loader, which then appears on your page. Download the zip file containing the necessary files (admin-bar-integration) and follow these steps to make it happen.

  1. Upload the file page-component.php to your WP theme directory.
  2. Create a new page in WordPress. The page should be blank. In the Attributes box, select the Template called “Component (do not use)”. Name the page bpnavslug and publish it, making sure that you take note of the permalink. You’ll need that URL (relative to your site’s webroot) in step 4.
  3. If any part of your site creates a menu or a list of your WordPress pages, you’ll want to exclude this empty page from those listings. Find the function call wp_list_pages in your theme (often in header.php or index.php) and add an exclude argument. For example, if the page number of bpnavslug is 4, make sure all references to wp_list_pages read wp_list_pages('exclude=4').
  4. Open the file bp-bar-integration.js. On line 3, you’ll see the path /bpnavslug/. Replace it with the path to the bpnavslug post you created in step 2.
  5. Upload bp-bar-integration.js to your server. For the sake of argument, I’ll put mine at /wp-content/js/bp-bar-integration.js.
  6. Now let’s turn to the application where you want the admin bar to appear. Open the theme file that contains the </body> tag. In bbPress, for example, this is usually footer.php.
  7. Immediately before the body close tag, paste the following code:
    <div id="bpContainer">
    </div>
  8. Next, open the template file that contains the document head (header.php in bbPress, for instance). Make sure that jQuery is also called somewhere in the head. If it’s not, the following code will call up jQuery on a standard installation of WP:
    <script type='text/javascript' src='/wp-includes/js/jquery/jquery.js?ver=1.3.2'></script>
    Now paste the following line somewhere in the head (make sure it comes after the call to jQuery):
    <script type="text/javascript" src="/wp-content/js/bp-bar-integration.js"></script>
    Be sure to replace the src attribute with path from your upload in step 5.
    Finally, you’ll have to include the CSS for the admin bar. On a default installation of BuddyPress 1.0.3 or less, the following code will work:
    <link rel='stylesheet' id='bp-admin-bar-css' href='/wp-content/plugins/buddypress/bp-core/css/admin-bar.css' type='text/css' media='screen' />
    On a more recent version of BP (1.1+), the admin bar stylesheet has been rolled in with the rest of the styles. Either create your own stylesheet containing just the admin bar code, or import the entire stylesheet:
    <link rel='stylesheet' id='bp-admin-bar-css' href='/wp-content/themes/bp-default/style.css' type='text/css' media='screen' />

A note: This method appears to be incompatible with the Google Analytics WP plugin (which appends Google’s JS to the footer of every WP page, and thus into bpnavslug, and ends up gumming up the works). You could probably get around this with some creative if-statements in the GA plugin itself.

Good luck. Because of the diversity of people’s setups, I can’t guarantee that this method will work for everyone, nor can I provide support to everyone who tries it. But I do encourage you to post whether you’ve been successful in the comments, and to help each other figure things out.

Version 0.2 of BuddyPressActivity

Since releasing my MediaWiki extension BuddyPressActivity, which puts wiki edits into your BuddyPress activity stream, I’ve noticed a bug or two. In particular, the cool feature that filters out multiple edits of a page by a given author within a 24 hour period wasn’t working right. I’ve made the necessary fixes in v0.2.

Get the updated code today.

New MediaWiki extension: BuddyPressActivity

One of the most interesting vantage points from which to monitor goings-on around the CUNY Academic Commons is the BuddyPress activity feed. The sitewide feed – located on the Commons’s News page – lists all the activity happening the blogs, groups, and profiles around the site. There are activity streams for individual users and for those users’ friends as well – you can mine, for instance, here.

wiki-activity

Until recently, though, these streams did not include information the activity taking place in the wiki portion of the site. I’ve developed a extension for MediaWiki (the software that powers the Wiki section of the Commons) called BuddyPressActivity that rectifies this shortcoming. For websites – like the CUNY Academic Commons – that have integrated our homegrown MediaWiki/Wordpress MU integration, this extension will update BuddyPress activity streams to include edits to pages within the wiki, thus better reflecting the extent and variety of the action on the site.

You can find out more about the extension – and download the code for use on your own MW/WMPu installation – at http://www.mediawiki.org/wiki/Extension:BuddyPressActivity.