I wrote a plugin this afternoon that solves a small but potentially annoying limitation of BuddyPress: its inability to show comments from non-members in the sitewide activity stream. In a streak of extreme creativity, I dubbed the plugin “BP Include Non-Member Comments”. Read more about it, and download it for your own use, here.
Tag Archives: plugin
Class blogrolls: No sweat
Last week, in the post where I announced my new WPMU plugin Shared Blogroll, I briefly mentioned the use case that I had in mind, which was of course education-focused. Yesterday and today I did some more work on the plugin itself (MORE AJAX 4EVA) and some of the supporting players. I thought I’d spell it out a little more so that others could implement what is probably the coolest system for shared blogrolls on earth, or at least on WPMU, which amounts to pretty much the same thing.
The plugins
- Shared Blogroll. This creates a widget that allows bloggers to embed a link category from any other blog on the system on their own blog.
- Add Users Sidebar Widget. This plugin is already pretty great, as well it should be seeing as it’s written by good-looking Canadians. I made some edits to the plugin to make it a bit more flexible.
- First I removed the RSS box from the Add User widget. For most of my users, it’ll confuse; for all of them, it’ll be redundant, since they’ll all be using Wordpress blogs and thus will have feeds that are very auto-discoverable.
- As the plugin stands in the repository, links are automatically put into the blog’s default link category (or, if they’re using FeedWordPress, the FWP link category). For most users, that’s something unhelpful like “Links” or “Uncategorized”. I altered the plugin so that the blog owner can choose which link category the added links will be put into. As I’ll discuss below, I think that this will add a lot of flexibility to the way that the plugins can be used together. You can download the text of my modified version of Add Users Sidebar Widget here: add-link-sidebar-widget.txt. Save as .php before uploading – and make sure that you uninstall previous versions of the plugin before uploading, or you might get whitescreened to death.
- Optional step. The default WP Links widget is set up so that you can’t select to display an empty category of links. As you’ll see below, I want to have instructors create a new category for their blogrolls, and I figured it’d be pretty confusing if they couldn’t create a sidebar widget corresponding to a link category until at least one student had posted a link (thus populating the category). So I wrote a little plugin that replaces the default Links widget with one that allows you to pick an empty links category. Drop this into mu-plugins: link_widget_allow_empty_cat. Be warned, though, that this plugin deregisters the default Links widget, which might have the effect of removing every links widget on your installation of WPMU. (I haven’t tested it.) For me, it’s OK, because I don’t have any active users yet. As an alternative, you could edit the core of WP (making sure to back up, take note of where you made the edit for future upgrades, blah blah blah) in the following way. In wp-includes/default-widgets.php, line 139 reads [code language=”php”]$link_cats = get_terms( ‘link_category’);[/code] Replace it with [code language=”php”]$link_cats = get_terms( ‘link_category’, ‘hide_empty=0’);[/code] That should leave all of your pre-existing links widgets in place.
The process
The immediate goal of this setup is to allow a class blogroll to be shared effortlessly between members of a class. (Though I can imagine lots of other very cool uses.) Here are the directions I’m going to give to instructors and students on how to leverage these two plugins to make it happen.
Instructors
- Create a new Link Category for your class blogroll – let’s say you call it “ENG 110 Blogroll”.
- Add a Links widget to the sidebar, making sure to select “ENG 110 Blogroll” from the category dropdown.
- Add an Add Links widget to the sidebar. Again, be sure to select “ENG 110” blogroll as the target category for added links.
- Give your blog’s ID number to your students and give them the following directions.
Students
- After creating a blog, visit the professor’s blog and enter your site’s URL into the Add Link sidebar widget.
- Add a Shared Blogroll widget to your own blog’s sidebar. Enter the professor’s blog ID number as the source blog, select “ENG 110 Blogroll” from the dropdown list, and Save.
I hope that the instructors and students get into this blogroll sharing thing. It distributes what would otherwise be a huge amount of work for the instructor, or *worse yet*, for me.
New WPMU plugin: Shared Blogroll
I just wrote a widget that lets a blog admin pull a link category from any blog on the same WPMU installation. It is pretty much the bomb, and you are going to love using it so much that you may have to take downers in order to get yourself under control.
Side note: I’m going to start creating separate pages (as opposed to posts) for each of my software releases. That way all comments/support regarding a given plugin will be in the same place, with a pretty URL. That’s why I’m turning off comments on this post.
Blog-specific email plugin for WPMU users
A quick WPMU hack that I think will help a lot of people using an installation of WPMU for multiple classes.
The plugin Email Users by Vincent Prat allows blog authors/admins to email users in two different ways: 1) by emailing a group of users (such as those corresponding a particular role on your blog), or 2) by emailing individual users. The problem, though, is that this second option brings up a list of every single user on the installation of WPMU. This can be a bit of a pain for the normal blog user, as teachers or students in a class would probably only want to see a list of those people who are in the class, or on the blog.
Here’s a hack that will make the Email Users plugin show list only the members of the current blog for everyone except for the site admin:
- In the main plugin file (email-users.php), find the function mailusers_get_users. It should start around line 404.
- Look for the lines of code (414-417 in my version) that define the variable $users in the first conditional clause:
[code language=”php”]
$users = $wpdb->get_results(
“SELECT id, user_email, display_name ”
. “FROM $wpdb->users ”
. $additional_sql_filter );
[/code] - Replace that line with the following code:
[code language=”php”]
if ( is_site_admin() ) {
$users = $wpdb->get_results(
“SELECT id, user_email, display_name ”
. “FROM $wpdb->users ”
. $additional_sql_filter );
} else {
$wp_user_search = new WP_User_Search(”, ”, ”);
$user_list = $wp_user_search->get_results();
$user_array = join(‘,’, $user_list);
$users = $wpdb->get_results(
“SELECT id, user_email, display_name ”
. “FROM $wpdb->users ”
. “WHERE id IN ( $user_array ) ” );
}
[/code]
Here’s the use case I envision. The instructor for a class places the Add User Sidebar Widget (by my boys at UBC’s OLT!) in the sidebar of his or her blog. As part of the first assignment of the semester, the instructor asks each student to register for an account, and click the “Add Me” button on the instructor’s blog. That will automatically populate the email list above.
File this tip under “who needs Blackboard?”.
2009 by the numbers
What’d I do in 2009? Some of my numbers are paltry and lame, but here they are anyway.
I posted 51 posts to this blog, teleogistic.net (and a handful of posts in other places). Those posts brought 183 legit comments. 3,299 unique visitors stopped by from 84 countries and 49 US states (WTF South Dakota?). The most popular search terms that led people here were: 1) read it later kindle, which led people to this post, 2) os x migration “less than a minute remaining”, which led people to this post, and 3) boone gorges, which led people to my beautiful face. The most popular posts on this blog were 1) Help me alpha test BuddyPress Forum Attachments (which is listed as the help page for a BuddyPress plugin I released, and so probably gets a lot of confused eyeballs), 2) Displaying the BuddyPress Admin Bar in Other Applications, which got added to StumbleUpon and, appropriately enough, contains hacks that did not originate with my paltry brain, and 3) Hub-and-spoke Blogging with Lots Of Students, which was interlinked with a lot of other great posts on the issue of classroom blogging. Not terrible for the first year of a blog, considering that BLOGS ARE DEAD.
I learned a lot about coding during 2009. When 2009 started, I knew quite a bit about HTML and CSS, as well as a smattering of PHP. I opened my first WordPress code file in about March. Since then I have released seven WordPress/BuddyPress plugins, a MediaWiki extension, and a handful of smaller hacks through the GPL, comprising some 4300 lines of code (about half of which was modified from existing code, and half of which is more or less from scratch).
I tweeted around 3300 times this year.
I racked up somewhere in the neighborhood of 180 hours of time this year commuting to and from work. Less impressively, I ran a pathetic 675 miles.
As some of you know, I do lots of crossword puzzles. According to my back-of-the-envelope calculations, I did around 1,960 crosswords this year, a number that is made up mostly of the first 13 puzzles listed on this page. I made a pledge at the beginning of the year to do my crosswords with pencil and paper (rather than on the computer) to improve my lackluster performance at ACPT. I stuck to that pledge: I can remember doing about three crosswords on the computer this year, as the rest were done on paper. We’ll see how all the practice pans out in February.
Here’s to a better 2010!
TinyMCE in Buddypress
I threw a little something together today to add WYSIWYG editing to BuddyPress, using TinyMCE. I want to be careful about the tags I allow, so I’m whitelisting, which is a bit tedious. As a result, there are only a few buttons available: a, em, strong, ul, ol, li. It’s a start, though.
Seems to work everywhere in BP: forums, wire, messages, profile pages.
A note about TinyMCE: WP ships with TinyMCE, and I thought it made sense to use that version instead of attaching one to this plugin. I think that the path to TinyMCE (line 20 of the plugin) should work on all installations, but you may have to tinker if you don’t see it popping up in the head of your BP pages. Moreover, the language files for WP’s version of TinyMCE are misnamed, which means that they don’t work right out of the box (at least for me they don’t). You may need to change the name of wp-includes/js/tinymce/langs/wp-langs-en.php to en.php in order to get the hover and help text in the TinyMCE box to work.
Download the plugin here. Don’t use in a production environment unless you are very certain that you are satisfied with the security of this plugin!
New BuddyPress plugin: Invite Anyone
Some members of the still-young CUNY Academic Commons, eager to start groups in support of various projects, have been getting hung up on the process of putting a group together: first, each person has to sign up for the Commons; second, each person has to become friends with the group admin; third, each person has to request membership or wait to be invited (in the case of private groups). I just released a plugin called Invite Anyone that cuts out the second step: with the plugin activated, group admins can invite anyone from the installation, not just friends.
Read more about it, and download the plugin, at the CUNY Academic Commons Dev blog.
EDIT: Please leave further comments or questions regarding this plugin at its permanent home: Invite Anyone
Streamlining Group Blogs
Cross-posted at the CUNY Academic Commons Dev Blog
Rodney Blevins and Marius Ooms wrote a fantastic plugin for BuddyPress called Groupblog, which allows BP groups to easily create a blog associated with their group. The killer feature of the plugin is the ability to add all group members to the blog (as authors, editors, subscribers, whatever you’d like) in a more or less automatic fashion – a far, far easier task than adding users manually through Dashboard > Add User.
I found, though, that the process wasn’t quite as automatic as I’d like. They’d based the code for adding users on a plugin by Burt Adsit called Community Blogs. Community Blogs only triggered the user adding process on a one-by-one basis: members of a group weren’t added to the group’s blog until they visited the blog. This is problematic for a few reasons. First, it’s an added step that creates some confusion among group admins and members, who assume that community blog membership should be automatic. Second, we’ve enabled various levels of privacy for blogs at the CUNY Academic Commons, and group members who were not yet members of a private group blog couldn’t really visit the blog to kick start the process. (Strictly speaking, that’s not true: the add user process was hooked to a process that took place when the blog’s login screen popped up, which happens when you persistently try to visit a blog to which you don’t have access. But this is extremely confusing.)
I took a bit of time today to rework how Groupblog handles the add user process. With the new setup, every member of a group is added to the group blog at once. The process is put into motion when the blog’s administrator updates and saves the group’s Group Blog settings. Other members of the BP community who join the group after the initial blog setup are added automatically to the blog as well, in accordance with the settings that the admin has determined for member permissions.
All the changes I made to the plugin are found in the main plugin file, bp-groupblog.php. You can download the modified file here: bp-groupblog.php.txt (don’t forget to make sure that the file is named bp-groupblog.php to make the plugin work). Just replace the stock version of the file with this one to make the changes. I intentionally did not clean up the plugin – all the original code is deactivated but still present beside the new code – because I wanted users to be able to differentiate what I had written from what the original authors had written (at least for now).
Upgrading from BuddyPress 1.0 to 1.1
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.
- 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.
- Export your bbPress database to a local file.
- 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.
- 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).
- 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.
- Upgrade BuddyPress. Deactivate, upload, reactivate.
- 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.
- 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.
- Move bp-sn-parent, bp-default, and your child theme to the main WP themes folder. In most cases this is wp-content/themes.
- Activate the themes in Dashboard > Site Admin > Themes. No need to activate bp-sn-parent, since it’s not used directly.
- Apply the child theme of your choice (either bp-default or your custom theme) to the main blog.
- 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.
- Set up BP forums. In Dashboard > BuddyPress > Forum Setup, set up forums as a new installation.
- 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_.
- 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.
Dealing with bbPress forums
Upgrading
The instructions at buddypress.org are quite helpful. Here’s a short version:
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:
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.
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!
Forum Attachments for BuddyPress
I posted about this a while ago, but I have ported _ck_’s bb_attachments plugin to BP 1.1.x. I took some time today to clean up the readme files and submit the plugin to the wordpress.com plugin database. Nothing about the plugin itself, or the hooks you’ll have to put into your theme, has changed since my last post; but at least now you’ll receive the file with full documentation and can use the WP plugin installer to install and maintain this bad boy.
Get it here or by searching for “forum attachments” on WP’s Add New Plugin page.
Bug reports (and especially patches!) are welcome.