Entering the world of mainstream WordPress Plugin development

Having written quite a few private WordPress plugins, I am now about to take on the task of creating a WordPress plugin for the general public (GPL License…obviously). It’s quite a different task from creating plugins for self or a limited use, but nonetheless one i’m looking forward to having in my own portfolio and my place of works.

I’m currently weighing up some options in terms of what to create, but at my place of work (Bytewire) we use WordPress alot for our clients and indeed many of our own projects. We have in this time come across some annoying problems which potentially a great plugin could very much help to overcome. Deciding on a feasible plugin to create is often one of the hardest things for a developer, especially so if it’s your first. I’m not venturing into making a plugin for any other reason than to help others and ticking off a personal milestone.

When developing a plugin for general public use you do have to remember a heck load more stuff, here’s some of the stuff i’m preparing my plugin to be ready for, and to handle.

Developing general release WordPress Plugins

When your developing for the general public you have to remember that your own integrity will be judged by the very integrity of your own plugin. If your plugin breaks a prospective users site, or, simply doesn’t do as it says, the user is likely to be very unhappy and potentially blacklist you as a plugin developer choice for future needs. How can you overcome these problems? Well, the simple answer is – be thorough, very thorough.

  • Make sure you check your plugin can function in a WordPress MU setup, by providing different or extra funtionality if is_multisite()
  • Comment your code well – WordPress is based on a GPL license, and actively encourages, code sharing and the ability to delve into one anothers code and make changes where seen fit. This helps with learning and extendability.
  • Debug your code – Using the WordPress functionality, make sure you debug your code so that you are not using deprecated functions or code
  • Build your plugin for the current WordPress version, do not attempt to support older versions of WordPress. As wrong as this may seem, Worpdress actively encourages this and warns all users not on the most up to date versions of WordPress they are not guaranteed a secure service unless they are. This can often be enough alone to persuade many clients and blog owners to upgrade. Generally WordPress wants to encourage upgrades as much as possible and with the possibility now to perform the upgrade in a matter of a handful of clicks, any user could do it. Suggesting to me if a user needs to use your plugin and he can’t without upgrading, WordPress effectively gets what it wants from your support as well.
  • Ensure you provide the properly formatted readme.txt file when submitting it to the plugin repository on WordPress
  • Make sure you are familiar with Subversion, you are required to use this to make changes to your plugin going forward.
  • You are most likely to find that your WordPress plugin is naturally fairly backward compatible, depending on the functions it makes use of, but as a general rule of thumb you could make sure it’s compatible with at least the last two major releases. Given that they are done on a 3-4 month basis, this would give you all users in the last 8 months by default and any that have upgraded in that time. Which is fine.

These are just a few things that are notable about diving into the world of WordPress public plugin development, there but many more. Perhaps as time goes by I will look to add to this post and grow it with my experiences. In the mean time if your a reader and you’ve got any great ideas for a killer WordPress plugin then i’d love to here from you.

A quote about me

I was laying there in bed last night and wrote this quote about myself, I liked it.

I am driven by anger and competition, motivated by difference and inspired by heroics. #thatisme

How to query wordpress posts by custom meta

WordPress custom meta for posts and pages (including custom post types…obviously) can open the door to extending WordPress in many great ways.

One such way is enabling custom input areas on the backpanel for specific post types and using them to store more specific information for each project you undertake.

For example say you’ve got a wordpress project which your client needs to be able to add and edit farm animals onto their site. Great! Custom post type time I here you say.

But wait…! You can use the title for the name of the animal and the main body to explain a bit about it, but what about storing the animals weight or how many you have of that animal on your farm. Simple answer, you can’t, well least not in a nice way.

Enter custom meta.

I’m not going to get into how to add custom meta to a custom post type, or indeed any type of post on WordPress, but I will show you how to use it in a WP_Query so you can query what you’ve created on the front end.

Now lets consider querying the top 5 weight heavy animals on the farm where farm animal type = nondairy.

    $loop = new WP_Query( 
        'meta_query' => array(
		'_myfarm_animal_type' => 'nondairy',
	'post_type' => 'services',
	'posts_per_page' => 5,
	'caller_get_posts' => 1,
	'orderby' => 'meta_value',	
	'meta_key' => '_myfarm_animal_weight',


Great huh? Not quite farmville, but you get the gist.

I may extend this post further in the future so check back if it interest’s you.

Setting Default WordPress FTP, SSH & SFTP Details

Sometimes hosts are really un-helpful and don’t set up your WordPress ftp details for you, or maybe you set your WordPress install up yourself and WordPress is asking you for FTP details.

Either way, what you’ll quite quickly find, or have already found (hence your now here reading this post) is that downloading plugins is slick when WordPress just WORKS. When it asks you for FTP credentials everytime, well…that’s just annoying.

So how can we stop this? Well it’s pretty easy actually.

What you’ll need

  • Access to editing your wp-config.php file
  • Your host’s FTP or SFTP details

Get cracking

Open up your wp-config.php file, found in the root of your WordPress install.

Add the following if you just want standard FTP connection.

define('FS_METHOD', 'ftpext');
define('FTP_BASE', '/home/site-name/www/');
define('FTP_CONTENT_DIR', 'wp-content');
define('FTP_PLUGIN_DIR ', 'wp-content/plugins/');
define('FTP_USER', 'yourFTPUsername');
define('FTP_PASS', 'yourFTPpassword');
define('FTP_HOST', 'yourFTPhost');
define('FTP_SSL', false);

To connect with SFTP then all you’ll need to do is add to the above, the following definitions and add your credentials paths.

define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');

wordpressFTP1 Setting Default Wordpress FTP, SSH & SFTP Details

Trust me when I say this, when Wordpres just WORKS. It is a great experience!

Mac Screenshot Shortcuts + Commands

I find this continuously frustrating to remember so I thought i’d write a quick blog about the possible mac os x commands for screenshot capturing and what they do for future reference.

  • Command-Shift-3: Take a screenshot of the screen, and save it as a file on the desktop
  • Command-Shift-4, then select an area: Take a screenshot of an area and save it as a file on the desktop
  • Command-Shift-4, then space, then click a window: Take a screenshot of a window and save it as a file on the desktop
  • Command-Control-Shift-3: Take a screenshot of the screen, and save it to the clipboard
  • Command-Control-Shift-4, then select an area: Take a screenshot of an area and save it to the clipboard
  • Command-Control-Shift-4, then space, then click a window: Take a screenshot of a window and save it to the clipboard

Just useful for future reference and for anyone to bookmark for future reference, mac os x screenshot commands.