Using SVN and Coda to Develop for 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.

W3 Total Cache

I just discovered an amazing caching plugin, thanks to yoast.com.  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!

How to Register Plugin Options

I’m currently writing my first WordPress plugin: WP-jPlayer.  I’m taking the jQuery-based audio player jPlayer and managing the options and songs from the Admin pages.  The plugin isn’t finished yet, but I’ve already learned a ton, so I wanted to share the tips and tricks I’ve picked up.  Some were learned from other developer‘s plugins, some by reading articles on the web, and many by simply making mistakes.

WordPress has a wonderful API, which allows you to use WordPress’s built-in functions to accomplish certain tasks.  One of the first API hooks you’ll use is add_action.  Add_action connects your custom function to a WordPress action.  The proper usage of add_action is:

<?php add_action( $tag, $function_to_add, $priority, $accepted_args ); ?>

$tag is the WordPress action you want to hook onto.  This is required when using add_action.

$function_to_add is your custom function to hook onto the WordPress action.  This is required when using add_action.

$priority determines the importance of your function; 10 is the default setting.  If it’s higher priority, use a lower number, if it’s lower priority, use a higher number.  This is optional when using add_action.

$accepted_args sets how many arguments can be passed on to your function.  This is optional when using add_action.

Here’s some example code from my WP-jPlayer plugin:

// this function registers our settings in the db
add_action('admin_init', 'wp_jplayer_register_settings');
function wp_jplayer_register_settings() {

register_setting('wp_jplayer_songs', 'wp_jplayer_songs', 'wp_jplayer_songs_validate');
register_setting('wp_jplayer_options', 'wp_jplayer_options');

}

The first line is a note, documenting what the function does.  Documenting your plugins and themes is vital, especially for updating the plugin later or someone else reading your code.

The second line uses add_action and specifies the WordPress action admin_init will hook to my function wp_jplayer_register_settings.  Admin_init is the first action run when someone accesses the WordPress Admin area.  In this case, it tells WordPress to run my function when the plugin is activated.

The function itself is basic PHP, but the register_setting hook is a WordPress thing.  It registers your plugin settings with WordPress and hooks a function that will sanitize the data so it will be saved in the database properly without any issues.  I’ll do another blog post about sanitizing data.

The proper usage of register_setting is:

<?php register_setting( $option_group, $option_name, $sanitize_callback ); ?>

$option_group is the name of the settings group, which can be anything you want.  This is required when using register_setting.

$option_name is the name of the setting you want to save.  This is required when using register_setting.

$sanitize_callback is the custom function that sanitizes the data.  It is optional, but highly recommended.

As you can see from my example code above, I registered two settings for my plugin: wp_jplayer_songs, the player’s song data, and wp_jplayer_options, the settings for the plugin itself.

You can register as many settings as you want, but it’s advisable that you keep them to a minimum.  Each setting requires a database visit, which slows down your site a bit.

So there you go.  Copy my code above and paste it into the top of your plugin file and customize for your settings.  When the plugin is activated, your settings will be registered with WordPress and you’re ready to use them!