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!
Some friends of mine (Joe Ugoretz and Jim Groom) were chatting on Twitter yesterday about how Userthemes, the WPMU/MS plugin they rely on to allow user customizations of copied system themes, had broken with WordPress 3.0. I decided to take a look at it. After digging a little, I found the immediate cause, as well as a workaround.
Please note that this workaround is very much a hack. It shouldn’t cause any security issues (see explanation below), but it will break the next time you upgrade WP.
Joe’s problem was that the plugin was only working for Super Admins. Administrators of single Sites could not copy new Userthemes, and they were redirected to the dreaded wp-admin/?c=1 when they tried to access the Edit Userthemes panel on the Dashboard. I figured it was a problem with permissions, and it was: all of those functions are triggered only for those users with the capability edit_themes, but for some reason only Super Admins, and not Administrators, were showing up as having that ability. (The weird thing – when I did a var_dump of WP Roles, I saw that Administrator *did* have edit_themes.) Maybe there’s some setting in WPMS that allows users to edit themes, but I couldn’t see it.
So the solution is to change the edit_themes check to something else. switch_themes seemed like an obvious choice to me, since anyone with the ability to switch themes on a given blog would also have had the ability to edit themes on that same blog. So there shouldn’t be a security problem – only blog admins should have the ability to make userthemes.
You’ll need to modify the plugin, as well as a few lines in the WordPress core.
Back up. I’m not responsible for anything that goes wrong!
Open the userthemes.php file. (I’d link to it, but I can’t find it anywhere on the web. When I’m at a better internet connection, maybe I’ll upload a version for you to edit. Maybe someone out there has a copy to share.) Search for all instances of ‘edit_themes’ and replace with ‘switch_themes’.
From your WP root directory, open wp-admin/theme-editor.php. On line 12, change ‘edit_themes’ to ‘switch_themes’.
From your WP root directory, open wp-admin/menu.php. On line 173, change ‘edit_themes’ to ‘switch_themes’.
This should restore the basic functionality of Userthemes (though Joe says that there’s still some bugginess – if you can’t access the Edit Userthemes from the main Dashboard page, try going to the Userthemes panel first). I must repeat that this is an ugly hack, and I’m hoping that someone smarter than me will step in and tell me why this is happening in the first place.
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();
}
I’m extremely pleased to announce (after weeks of keeping mum until the official word was released!) that I’ll be co-mentoring several projects for Google Summer of Code and WordPress. For those of you who don’t know, GSoC is an initiative by Google to support summer coding projects by undergraduate and graduate students working on various established open-source projects. WordPress has 15 projects this year, several of which are related to BuddyPress. As a mentor on two of the projects, I’ll be helping to hone the project scopes, do code reviews, and in general lend a hand where I can to my two mentees. Here they are:
Francesco Laffi has a two-part project. 1) He’ll be working on a rich media component for BP, building on his already popular BP Album. 2) He’ll be constructing a reporting/moderation plugin for BP group forums, which will allow the general user base to play a role in moderating good and bad content within a community. I’ll be co-mentoring Francesco with Andy Peatling, the lead dev for BuddyPress.
Stas SuÈ™cov will be working on BuddyPress in educational contexts. The germ of his idea is to take ScholarPress Courseware (with its scheduling, bibliography, and assignment tools), combine it with a nice gradebook (maybe something like KB Gradebook), and put it inside a BuddyPress shell. I’ll be co-mentoring Stas’s project with Jeremy Boggs, developer of Scholarpress.
As promised in my last post, I’ve reworked the Import from Ning WordPress plugin so that it is BuddyPress-aware. That means that, if you run the plugin on a blog where BuddyPress is activated, additional steps will be added to the import process, allowing you to automatically import whichever profile fields and data you’d like from the Ning export.
I also got rid of the pesky copy-and-paste requirement in favor of a direct .csv file upload.
