Category: Development

Anything and everything development related

Switching from Manual to Automattic

On By westiIn Development, WordPress23 Comments

Over the past few years I have been an active member of the WordPress.org community in my spare time whilst having a day job which was completely unrelated to WordPress.  I have found it a useful learning experience, gaining knowledge from all the smart people we have in the community and have also found it rewarding to help people realise their full potential.

This level of enjoyment has led me to consider at a number of points in time whether or not I should switch job and work full-time on WordPress.org as a freelance consultant or as an Automattician.  In the end it felt like the right thing for me to do was to apply to be an Automattician.  This will hopefully ensure that I have a dependable long-term income stream and the ability to spend my spare time on the things I love: Music, Photography, Food, and of course WordPress.

It is with great pleasure that I am therefore able to reveal that I will soon be switching and starting a full-time job working for Automattic as a “Happiness Gardener”.

So what does this mean, I hear you cry?  Well to me it means a number of things:

First of all I will be getting to work with the fantastic team at Automattic on a daily basis and helping the Happiness Engineers to improve the tools they have, and the experience bloggers have, by working to remove some of the issues which are a frequent source of support tickets.

Secondly this means that I will have an easier time structuring my work around contributing to the core of WordPress.org.  In the short-term my availability to work on WordPress.org may be reduced solely because there are a lot of things the Happiness Engineers would like me to do to make it easier for them to ensure that all of the bloggers on WordPress.com are as happy as they could be.  In the long-term I hope to be able to spend some of my work time working on WordPress.org and helping Automattic give back to the community even more than it already does.

Thirdly it means that I might be able to attend a few more WordCamps in order to listen to community feedback in person and answer questions on both WordPress.org and WordPress.com.  I am certainly not going to stop listening to the feedback from the community at large or focus my WordPress.org contributions on things which Automattic want to be done.  I think one of the most positive things about WordPress.org is that it is a meritocracy and everyone can play a part, my new job will not change my attitude or contributions.  I want the WordPress.org community to continue to grow organically as it has over the past years, and together we can all ensure that WordPress.org continues to be the simplest and most beautiful open-source online publishing platform.

Mangling strings for fun and profit

On By westiIn Development, Tutorials, WordPress15 Comments

As a WordPress lead developer, every time I see someone recommending editing a core WordPress file, a little bit of me dies.

You should always avoid editing the core files and put your modifications into a plugin so as to ensure you have a smooth upgrade experience to a future WordPress version.

Therefore inspired by the following forum post here is how to change one of the translatable strings in WordPress without hacking a core file using the filters available in the translation functions:

<?php
/*
 Plugin Name: PJW Translation Mangler
 Plugin URI: http://blog.ftwr.co.uk/#
 Description: Example of how to mangle translated strings.
 Author: Peter Westwood
 Version: 0.01
 Author URI: http://blog.ftwr.co.uk/
 */

class PJW_Translation_Mangler {
 /**
 * Filter the translation string before it is displayed.
 *
 * @param $translation The current translation
 * @param $text The text being translated
 * @param $context The context for the translation
 * @param $domain The domain for the translation
 * @return string The translated / filtered text.
 */
 function filter_gettext($translation, $text, $domain) {
  $translations = &get_translations_for_domain( $domain );
  if ( $text == 'View all posts filed under %s' ) {
   return $translations->translate( 'See all articles filed under %s' );
  }
  return $translation;
 }
}
add_filter('gettext', array('PJW_Translation_Mangler', 'filter_gettext'), 10, 4);
?>

The filter used in this example gettext is one of a set of filters in the translation functions in wp-includes/l10n.php which also include gettext_with_context, ngettext, and ngettext_with_context.

Feeding on feedback and progress

On By westiIn Development, Tutorials, WordPress2 Comments

Keeping track of a projects progress is a common desire and if the project you are interested in happens to be a WordPress plugin then there are a number of RSS feeds which are an important resource for you (replace plugin_slug with the plugins slug!).

http://wordpress.org/support/rss/tags/plugin_slug
http://plugins.trac.wordpress.org/log/plugin_slug?limit=100&mode=stop_on_copy&format=rss

The first of these contains all the support forum posts relevant to a particular plugin and the second is all the code changes that are happening in the plugins repository.

To keep track of these you have a couple of choices.

Firstly you could subscribe to them in your feed reader or if like me you like to receive emails for this sort of thing you can setup a cool tool called rss2email on your pc/server to email you new posts/changes.

A better meta API for WordPress

On By westiIn Development, WordPress10 Comments

One of the things that we have being discussing for a very long time is extending WordPress with a comment meta api or even the idea of a generic meta api for WordPress and indeed this is something we are discussing at the moment and I thought I would jot down some thoughts on what I would like to see from an API point of view.  Over the weekend at WordCamp UK we also heard about situations where some people are already adding comment meta tables for plugin usage and so the demand is definitely there.

I don’t really care how the data is stored, be it single table or multi table, all I care about is having a good stable API for plugins and the core to work with.  If the API is good and well thought out they don’t need to care about the table structure and we can always change it later.

Therefore I thought I would summarise the features I would like to see in a generic meta api:

  • Flexibility to easily create a different kind of meta without having to care about adding tables yourself.
  • Ability to store anything in a meta value – i.e. The same kind of functionality we have we options.
  • Ability to get things back based on key ranges or operations – i.e. Getting all cron meta values where the meta key (which would be a timestamp) is before a particular time.

So I am thinking of an api like this:

/*
* Register a new meta type.
* If we have a table per meta this will create the table for you if required
*/
register_meta_type('cron');

/*
* Returns the meta value for a particular key
*/
get_meta_value('cron', $key);

/*
* Sets the meta value for a particular key
*/
set_meta_value('cron', $key, $value);

/*
* Returns the meta values for a particular key based search
*/
get_meta_values('cron', $search_value, $search_type);

/*
* Deletes the meta value for a particular key
*/
delete_meta_value('cron', $key);

I would envisage us enabling the use of the new api with wrapper functions for different meta types as required. These wrapper functions would only be included if required, for example we could create a comment_meta wrapper api around these generic meta api functions which would only be available if a plugin / theme called enable_comment_meta_api()