This weekend at WordCamp NYC, John James Jacoby announced that I, along with Paul Gibbs, have been promoted to core committers on the BuddyPress project. Needless to say, I’m honored and extremely excited.
For my academic friends who might not know what this means, here’s a (very brief) description of open-source development model used by WordPress (and, by extension, BuddyPress). Anyone who downloads the BuddyPress software can view and modify the source code at will. Likewise, anyone can report bugs, suggest enhancements, or file actual patches (small bits of code that, when added to the distribution version of the software, fix bugs or add features) on the BuddyPress bug tracker, which is the communication hub for the developers who work on the software. However, only a small handful of individuals can “commit” to the “core”. In other words, while anyone can submit code for consideration, only core committers can add those patches to the version of the software that is distributed via wordpress.org. Being added as a committer means that the existing committers (Andy, John, and Marshall) trust and respect my work enough to, in effect, hand me the keys to the car.
It’s a very cool thing for me because I don’t have any formal background in programming or in software. Before roughly the spring of 2009, I had only a smattering of programming knowledge, and had never cracked the hood of WordPress or of BuddyPress. My work on the CUNY Academic Commons plunged me deep into the world of WordPress development. I found a natural home in the BuddyPress community, which is full of smart people thinking not just about how software works, but also about how it can enhance the ways we engage with each other online. I’m certain that I wouldn’t have been promoted to this position if I hadn’t been willing (and encouraged) to share, whether it be the free time I’ve spent writing patches for BuddyPress, helping others out on the forums, or writing code that is freely available (and supported with a smile!). It’s a testament to the fact that the extra effort it sometimes takes to share and to do one’s work in the open can come back to you many times over.
I’m looking forward to the next stages of BuddyPress development!
I’ve been working on a project recently with Kevin Prentiss and the other fine folks at Red Rover. Kevin is a big believer in the power of feeds, and I’m a big believer in the power of BuddyPress’s activity component, and together we realized that BuddyPress’s RSS support for its rich activity content is a bit lacking.
This new plugin, BP Lotsa Feeds, is meant to address the issue. It activates RSS feeds for just about everything in BuddyPress, from an individual member’s sitewide comments, to new group memberships for specific groups, to individual forum topics.
Read more about the plugin on its home page, and follow its development on Github. Thanks to Red Rover for sponsoring a cool plugin.
My palz Mikhail and Luke over at Blogs@Baruch needed an easier way to add users to sites in the WordPress network. They’d been using DDImportUsers, which worked, but was finicky: DDIU required you to specify too much information, its formatting was tough for instructors to understand, and, most importantly, it didn’t deal well with existing accounts, which it simply ignored instead of adding as new users to the site in question. So they asked me to modify the plugin for their purposes.
The result is a near-complete rewrite, released today under the name Simple Import Users. Instead of entering all sorts of information about username, password, display names, etc, Simple Import Users accepts only a single argument: email address. That makes it simple enough for anyone to use. Insert a list of email addresses into Simple Import Users, and it checks each email address in the following way:
If a WP user is *not* found with the email address in question, SIU creates a new user with that address. The username is automatically generated from the part of the email address before the @-sign, which means that this plugin will probably work best for those setups where you can guarantee unique email prefixes (like schools). Passwords are randomly generated.
Then the new user (or the existing user, if one was found) is added to the blog.
The user is then sent a customized welcome email. All users get a message saying that they’ve been added to the blog, with information on how to access the dashboard. In the case of new users, it contains their login info as well.
If you’re running BuddyPress, the email to new users also contains a message encouraging users to fill out their BP profiles, with a link to the Edit Profile page.
The plugin has no settings, and is intended for this very specific purpose. But if you’ve got a setup like Blogs@Baruch, it could save you a lot of time and effort.
[IMPORTANT: I am no longer supporting this plugin. You may contact me for a list of consultants who may be interested in providing Ning import support.]
Back when Ning announced that it’d be cutting off previously free accounts, I took a weekend and developed Import From Ning, a plugin that helped users pull their Ning user and profile data into a WordPress or BuddyPress installation. It was my own little BuddyPress-fanboyish way of helping all those Ningsters.
Several weeks ago, Ning released its Ning Network Archiver, which (finally) allowed network admins an easy way to take their content with them. On the heels of this release by Ning, today I am releasing version 2.0 of Import From Ning, which imports the content from a Ning Network Archive.
On the CUNY Academic Commons we have a MediaWiki installation running parallel to our WordPress/BuddyPress installation. In the past I had hacked together an inelegant and constantly breaking solution for importing wiki edit notifications into the BP activity stream. I’ve just written a small plugin called BP External Activity which solves the problem by using the BP activity API and RSS.
The plugin can be used to pull items from any RSS feed and add them to your BP activity stream, with customizable text. It’s feature-light right now (and requires some hand-coding to work) but it’s still pretty much the coolest thing ever. I will update it to be better when I get around to it.
A few people have asked recently for a list of the plugins installed on the CUNY Academic Commons. In the spirit of Joe’s post, here I thought I’d make it public. I’m going to limit myself to the BuddyPress plugins here, for the sake of simplicity. (I’d like to write a series of posts on the anatomy of the CUNY Academic Commons; maybe this will be the first in that series.) Here they are, in no particular order other than the order in which they appear on my plugin list.
BP TinyMCE. This plugin is messed up, and I have part of it switched off, but I still use the filters that allow additional tags through, in case people want to write some raw HTML in their forum posts, etc.
BP Groupblog. Allows blogs to be associated with groups, displaying posts on that group’s activity feed and automatically credentialing group members on the blog. I did some custom modifications to the way the plugin works so that clicking on the Blog tab in a group leads you to subdomain address rather than the Groupblog custom address (thereby also ensuring that visitors see the intended blog theme rather than the BP-ish theme).
BP MPO Activity Filter. This plugin works along with More Privacy Options to ensure that the new privacy settings are understood by Buddypress and that blog-related activity items are displayed to the appropriate people.
BuddyPress Group Documents. This one is crucial to our members, who often use the plugin to share collaborative docs.
BP Include Non-Member Comments makes sure that blog comments from non-members are included on the sitewide activity feed.
BP External Activity – an as-yet unreleased plugin I wrote that brings in items from an external RSS feed and adds them to the sitewide activity feed. We’re using it for MediaWiki edits.
BP Group Management lets admins add people to groups. Very handy for putting together a group quickly, without having to wait for invites.
BP System Report. We’re using this one to keep track of some data in our system and report it back to members and administrators.
BuddyPress Terms of Service Agreement, another as-yet-unreleased plugin (this one by CAC Dev Team member Chris Stein) that requires new members to check TOS acceptance box before being allowed to register.
Forum Attachments for BuddyPress. Another of our most important BP plugins, this one allows users to share files via the group forums.
Group Forum Subscription for BuddyPress. This is our legacy email notification system, which is going to be in place until I get back from my honeymoon and can replace it 🙂
Invite Anyone lets our users invite new members to the community and makes it easier to populate groups.
Questions about any of these plugins or how they work with BuddyPress? Ask in the comments.
I’m quite happy to announce the release of a more-or-less stable (we hope!) version of BuddyPress Group Email Subscription, a BuddyPress plugin that allows for fine-grained, user-controllable email subscription to group content in BuddyPress.
This plugin is different from some of my others in that it was truly a group endeavor. The base of the plugin was written by David Cartwright, with a little bit of code from me. A nearly complete rewrite of the front-end and most of the guts of the plugin was undertaken by Deryk Wenaus. I wrote the daily and weekly digest functionality, along with some of the settings pages and various bugfixes throughout. The current codebase of the plugin is probably 60% Deryk, 30% me, and 10% David.
It was my first time working on a truly collaborative software development project like this, and it was a real pleasure working with both of these gentlemen. Thanks, guys.
A local development environment is a collection of software and files on your local computer that replicates a server environment. There’s a number of reasons why doing web development in a local environment and then pushing it to a remote server is a good idea:
Convenience: You don’t need an internet connection
Speed: Because you’re not transferring files remotely, there’s no save or reload lag
Power: You have total control over the environment, in a way you don’t on, eg, shared hosting
Safety: You can set up as many parallel environments as you’d like on your local machine, and if you destroy one of them, you can wipe it out and replace it in just a few clicks
I just got a new computer and so have been going through the process of rebuildling my local dev environment. For the benefit of those just getting into web development, here’s how I set it up, with a bit of explanation. Keep in mind that I’m working with OS X 10.6, developing for WordPress; if you’re running a different operating system, or developing for a non-PHP based framework, your setup will differ from mine.
Create a /sites directory: To make navigation from the command line a bit easier, I like to keep all my development environments in first-level directory called sites. Open a Terminal window and type:
[code language=’text’]mkdir /sites[/code]
Download and install MAMP: Strictly speaking, MAMP isn’t required on OSX, since the OS comes with Apache, MySQL, and PHP installed (enabled through System Preferences > Sharing > Web Sharing). But MAMP has a nice preferences interface, and comes with useful tools like PHPMyAdmin, so I use it. Get MAMP and install it.
Configure MAMP: Open MAMP and click the Preferences button.
Configure Start/Stop. I like to uncheck the “Stop servers when quitting MAMP” box, so that I don’t have to keep MAMP open all the time.
Switch the ports. You can use the port settings that MAMP comes preconfigured with, but I like to change it because it can make managing domain names a bit easier. Click “Set to default Apache and MySQL ports”. The downside of changing this setting is that each time you start up MAMP (for me, that’s every time I start the computer, which is once every week or so), you’ll need to type in your OSX administrator password. That’ll happen when you save your settings at the end of this step, too – don’t be alarmed.
Switch the Apache root directory. On the Apache tab, change the root directory to /sites.
When you click on OK to save your preferences, you will probably be asked for your admin password. Your local environment is now up and running, and it’s time to configure it to handle WordPress.
Configure your hosts file: By default, you can reach your local installation in a browser by visiting http://localhost or http://127.0.0.1. The first option doesn’t work very well with WordPress (WPMU, at least), and the second one isn’t very attractive. We can set up a more attractive host name by editing the /etc/hosts. Open /etc/hosts, ideally at the command line with
[code language=’text’]sudo nano /etc/hosts[/code]
‘sudo’ is important here, as you’ll need admin rights to change this file. Modify the line that says
[code language=’text’]127.0.0.1 localhost[/code]
so that it says
[code language=’text’]127.0.0.1 localhost boone.is.awesome[/code]
Now clearly you don’t have to use ‘boone.is.awesome’ (though you probably should, because I am awesome). You can use any combination of words you want, separated by periods, like a URL – ‘local.dev’, perhaps. Don’t use a real URL. Save the file (if you’re at the command line, hit Ctrl-X, and then Y when you’re prompted to save) and test your new hosts file by visiting http://boone.is.awesome (or whatever) in a browser window.
Create a database: In MAMP, click the “Open Start Page” button, which will open the MAMP start page in the browser. Click on the PHPMyAdmin link on the start page. PHPMyAdmin is a graphical interface for your MySQL database that you might find handy as you do development. Click the Databases tab, and create a new database – I’m calling mine ‘wp-trunk’. You may also want to choose a default text encoding: ‘utf8_general_ci’ works pretty well if you think you might be doing development in different character sets (Cyrillic, Arabic, etc).
Download WordPress: I like to get WP via SVN, which makes it easy to keep track of any core hacks I might make. Here are the Terminal commands to create an installation called ‘wp-trunk’:
[code language=’text’]cd /sites
mkdir wp-trunk
svn co http://core.svn.wordpress.org/trunk wp-trunk/[/code]
You’ll see a bunch of files being downloaded. In this example I’m downloading the trunk, or development, version of WP, rather than the stable version. If you’d like to get a specific version, say 2.9.2, use svn co http://core.svn.wordpress.org/tags/2.9.2 wp-trunk/ instead. (More on using svn with WordPress, from Mark Jaquith)
Install WordPress: In your browser, go to http://boone.is.awesome/wp-trunk (or the corresponding path on your machine). This should load the WordPress installer. If you’ve followed along with my instructions, the settings in this image ought to work for you. You’ll notice that I’m using the root MySQL account, with the default password, because it automatically has all privileges on all databases. You should obviously never do this on a database that is connected to the internet. I should also note here that I’m installing the beta of WP 3.0, but the same process will work for any version of WP, even WPMU. With MU, though, you may have some problems if you choose the subdomains option for secondary blogs.
That’s it! You should now be able to log into your installation at http://boone.is.awesome/wp-trunk/wp-admin. When I plan to use an installation of WP to develop for BuddyPress, I check out the trunk version of BP in a similar fashion to step 6:
[code language=’text’]cd /sites/wp-trunk/wp-content/plugins
mkdir buddypress
svn co http://svn.buddypress.org/trunk buddypress/[/code]
Well well, what do we have here but another MIND BOGGLING BuddyPress plugin? This one is called BP System Report, and it allows admins to take periodic snapshots of some interesting data in their BP installation.
During the recent upgrade from BuddyPress 1.1.x to BuddyPress 1.2.x, and the subsequent move away from group wires to interactive group activity streams, one thing that some users on the CUNY Academic Commons missed was the “Notify members by email” checkbox of the old wire.
This morning I wrote a bit of code to add that kind of functionality to group activity streams. There are three functions, each of which goes in your plugins/bp-custom.php file.
First, adding the checkbox to the activity box. Notice that it only shows up when you’re on a group page.
[code language=’php’]
function cac_email_activity_checkbox() {
if ( !bp_is_groups_component() )
return;
?>
Second, handling the data when it gets to the server and sending the emails. Obviously, you’ll want to change the text of the email to match your own site and your own preferences. The line “remove_action( ‘bp_activity_after_save’ , ‘ass_group_notification_activity’ , 50 );” is there to prevent an email notification from being sent if you’re using the Group Activity Notification plugin, a big official release of which is coming soon 🙂
[code language=’php’]
function cac_email_activity_handler( $activity ) {
global $bp;
if ( $_POST[‘mailme’] == ‘mailme’ ) {
$subject = sprintf(‘[CUNY Academic Commons] New update in the group “%s”‘, $bp->groups->current_group->name );
$message .= sprintf(‘You recieved this message because you are a member of the group “%s” on the CUNY Academic Commons. Visit the group: %s’, $bp->groups->current_group->name, $bp->root_domain . ‘/’ . $bp->groups->current_group->slug . ‘/’ . $bp->groups->current_group->slug . ‘/’ );
//print_r($message);
if ( bp_group_has_members( ‘exclude_admins_mods=0&per_page=10000’ ) ) {
global $members_template;
foreach( $members_template->members as $m ) {
wp_mail( $m->user_email, $subject, $message );
}
}
}
Finally, you’ll need some Javascript to make the AJAX activity submission work correctly. This is really just a copy of what’s in the bp-default JS file, with a few added lines to make it work.
[code language=’php’]
function cac_email_activity_js() {
if ( !bp_is_groups_component() )
return;
?>
var jq = jQuery;
jq(document).ready( function() {
jq(“input#aw-whats-new-submit”).unbind(‘click’);
/* New posts */
jq(“input#aw-whats-new-submit”).click( function() {
var button = jq(this);
var form = button.parent().parent().parent().parent();
/* Remove any errors */
jq(‘div.error’).remove();
button.attr(‘disabled’,’disabled’);
/* Default POST values */
var object = ”;
var item_id = jq(“#whats-new-post-in”).val();
var content = jq(“textarea#whats-new”).val();
var mailme = jq(“#cac_activity_mail:checked”).val();
/* Set object for non-profile posts */
if ( item_id > 0 ) {
object = jq(“#whats-new-post-object”).val();
}
