Subversion, Coda, and WordPress

I’ve been using Panic’s Coda to develop my WordPress plugins and manage my sites and I love it.  When I published my first plugin, it took me quite a while to find any real resources on using Coda with WordPress’s Subversion servers.  It’s fairly simple stuff really, but updating plugins baffled me for the longest time and I’ve finally figured out the proper steps to do it without errors or partial uploads (as evidenced by the version 0.32 of ArtistDataPress plugin that didn’t include the widget, css, or images folders…).

Random tip: when developing, use the trunk files.  These files aren’t the ones given to the public and if you have more than one developer, this is where each of checks out the files you’re working on.

For those using Coda and wanting to develop for WordPress, these are tested instructions for updating a plugin:

Make changes as needed to your plugin files.  Be sure to update the stable version number in your main plugin and readme files.

Go into the tags folder.  Duplicate the latest tag folder in there.  When it asks if you want to update, say yes.

Change the name of the folder to the latest version number.  Say yes to updating.

Copy the updated files from the trunk folder into the newly-created tag folder.  At this point, there should be a green A next to that tag folder.

After all the files have been copied to the tag folder, click the green A.  This will add this folder to the SVN repository.  Coda will ask you to type in notes about the changes – make them as detailed as possible, this is the only thing people in the future will see when looking at why the plugin was changed to a new version.

The new tag folder and all the updated files should be added to the SVN repository.  Wait about fifteen minutes and you should see the changes reflected on the plugin’s page in the WordPress plugin directory.

If the steps above don’t work or you start getting odd errors (like you need to force an update), copy your trunk files to your desktop and remove the site.  Then add the site back and check out the repository again.  Then follow the steps above.  I just ran into this today (2/11/2012) and this worked for me.

How to Hide the BuddyPress Admin Bar (aka BuddyBar)

Many sites tell you how to hide the BuddyPress Admin Bar (aka BuddyBar), but only this code eliminates it completely from your site.

I’ve seen a bunch of sites that supposedly show you how to do this, but none are complete.  I have a client who wants to use BuddyPress, but doesn’t want the Admin Bar (I call it the BuddyBar) across the top of every page.  So I’m building a plugin called BuddyBar Widget that includes a sidebar widget with all the BuddyBar links in it.  Another part of the plugin hides the BuddyBar completely, even when you’re on Dashboard.

To hide the BuddyBar from users that aren’t logged in, go to the BuddyPress General Settings page and select “Yes” for the Hide admin bar for logged out users? option.

That’s great, but it doesn’t hide it if you ARE logged in.  For that, we’ll need some code.

EDIT ( February 1, 2012):

Ignore the old post from below. After trying to get that to work properly, I’ve switched to something far more effective. Paste the code snippet below into your wp-config.php file. I put it right above the “Authentication Unique Keys and Salts.” comment block. This works for sure. It’s not what I had hoped to do, but it works.

I created a function (I’m calling it remove_buddyadminbar), then used define to tell WordPress to turn off the BuddyBar.  This, by itself, will turn off the BuddyBar.  It may complete overkill, but I also use remove_action hooks as well.  BuddyPress uses the add_action hook in the WordPress footer to activate the BuddyBar.  Remove_action simply negates that call from BuddyPress.  You’ll notice, I also include the call for the admin_footer, which should hide the bar on your admin pages, including Dashboard.

While that’s all well and good, now you’ll notice a nice gap at the top of your admin pages.  When you kill the BuddyBar for the Dashboard, it doesn’t undo the CSS formatting that creates room for it at the top of your admin pages.  This bit of CSS takes care of that:


Using those two bits of code will completely eliminate the BuddyBar from appearing on your site.  I’ll post again about this when the plugin is ready to ship.

WordPress 3.0 “Thelonius” is out!

Update your blogs, WordPress 3.0 is out!

Log into your Dashboards and update your installation, 3.0 is out and available! I’ll be writing up some articles about the new features soon. I’ll also be updating Your Band Blog to reflect 3.0 and the changes it offers us musicians. Until then, get your blog updated!

W3 Total Cache

Load and activate the W3 Total Cache plugin to see significant improvement in your WordPress blog load times.

I just discovered an amazing caching plugin, thanks to  It’s called W3 Total Cache and is available through the WordPress plugins directory.  I’ve endorsed WP Super Cache in Your Band Blog, but frankly, I never really noticed it making my site faster.  When I installed and activated W3TC, I noticed.  I completely believe their claims of a 10x load time improvement.

The best part is, it doesn’t require much tweaking, most of the default settings are great.  I had one minor issue: for some reason the plugin wasn’t able to put its file, advanced-cache.php, in the plugins folder, so it disabled that portion of the plugin.  I manually uploaded the file, reloaded the plugin options page, and all was well.

Here are the settings I changed from the defaults:

Page Cache Settings:

Change HTTP compression to gzip and deflate (best).

Minify Settings:

Change HTTP compression to gzip and deflate (best).

Check the enable box for HTML minify settings.

That’s it.  The plugin will prompt you to empty the cache after each change, just wait until you’ve made all three, then you’re good to go.  You should notice a dramatic increase in your page load times, I know I did.  I have yet to gather any concrete data, like Google Page Speed analytics, but it appears to load much faster than before.  Give this plugin a shot and I think you’ll be happy with the results!


BuddyPress was recently updated to include support for single WordPress installs. Is this useful or just another social network?

Last May, I read about BuddyPress, a new plugin from Automattic, which also produces WordPress, that would bring social networking to WordPress blogs.  I immediately began dreaming up ways to create a community of my music’s fans.  Then I read up on it.  It required WordPress MU, which allows you to create blog networks (like for a school, company, etc).  Since I wasn’t running MU, and didn’t know any bands that were, I forgot about it.

BuddyPress 1.2 was released Friday, February 26th and can be used with a single WordPress install, so we can all have social networks related to our band blogs!  However, I’m a little hesitant: do our fans need yet another social network?  While I’m sure there are bands that could easily support their own (think: Phish, Dave Matthews Band, or KISS to name a few), most of us don’t have enough fans to justify it.  We’re better off with sticking to Myspace, Facebook, and Twitter because our fans are already on those sites.

Before you think I’m just being pessimistic, I’m in favor of using this plugin.  I just wonder how effective it will be for most artists.  If you have a community created around your band already, this will work well to help you unite them.  For the rest of us, it could assist you in building that community around your music.  Either way, this is a good step for this plugin and I hope to start working it into some artist blogs to see if it’s helpful or just another useless social network.  Once I have some first-hand knowledge, I’ll write some more (but I’ll bet you see this plugin in the next version of my book).