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.

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.

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.

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()

I tweeted back that it was already easy and so here is the proof of concept code which shows you:

• How to add a user meta field to the page
• How to process the new value when it is updated.

These can the been displayed on the front-end using the standard template tags get_the_author_meta() and the_author_meta()

<?php
/*
Plugin Name: PJW User Meta
Plugin URI: http://blog.ftwr.co.uk/archives/2009/07/19/adding-extra-user-meta-fields
Description: Allows users to configure some random extra meta value.
Author: Peter Westwood
Version: 0.02
Author URI: http://blog.ftwr.co.uk/

Use of the frontend as get_the_author_meta('something') or the_author_meta('something')
*/

class pjw_user_meta {

 function pjw_user_meta() {
 if ( is_admin() )
 {
 add_action('show_user_profile', array(&$this,'action_show_user_profile'));
 add_action('edit_user_profile', array(&$this,'action_show_user_profile'));
 add_action('personal_options_update', array(&$this,'action_process_option_update'));
 add_action('edit_user_profile_update', array(&$this,'action_process_option_update'));
 }

 }

 function action_show_user_profile($user)
 {
 ?>
 <h3><?php _e('Other Contact Info') ?></h3>

 <table>
 <tr>
 <th><label for="something"><?php _e('Something else'); ?></label></th>
 <td><input type="text" name="something" id="something" value="<?php echo esc_attr(get_the_author_meta('something', $user->ID) ); ?>" /></td>
 </tr>
 </table>
 <?php
 }

 function action_process_option_update($user_id)
 {
 update_usermeta($user_id, 'something', ( isset($_POST['something']) ? $_POST['something'] : '' ) );
 }
}
/* Initialise outselves */
add_action('plugins_loaded', create_function('','global $pjw_user_meta_instance; $pjw_user_meta_instance = new pjw_user_meta();'));
?>

Enjoy!

Updated to correctly use the $user/$user_id passed to the actions rather than the global $user_id

What a different world it was, upgrading WordPress took time and people just didn’t bother even though new versions which contain security fixes had been released.

Now we are just about to get WordPress 2.8, people can upgrade with the click of a button and there hasn’t needed to be a security release for WordPress 2.7 how things change.

In celebration of this I have decided to take down the web-service which supported the plugin and have started the shutdown process by changing the message returned to point to this blog post.  So please un-install the plugin and rely on the notification that has been built in to WordPress for a few releases now.

Oh and don’t forget if your one of those people who has been ignoring these messages and are still running v1.5.2 (yes you know who you are) then please upgrade.

I am now happy to announce that I can provide these examples and have updated the plugin documentation on in the WordPress plugin directory to match as well.

Firstly we have an example page template (based on the default theme) for listing the children of a page:

<?php
/*
Template Name: Page with Children
*/
get_header(); ?>

<div id="content" role="main">

<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
<div id="post-<?php the_ID(); ?>">
<h2><?php the_title(); ?></h2>
<div>
<?php the_content('<p>Read the rest of this page &raquo;</p>'); ?>

<?php wp_link_pages(array('before' => '<p><strong>Pages:</strong> ', 'after' => '</p>', 'next_or_number' => 'number')); ?>

</div>
</div>
<?php endwhile; endif; ?>
<?php edit_post_link('Edit this entry.', '<p>', '</p>'); ?>
<div id="children">
<dl>
<?php query_posts('static=true&posts_per_page=-1&child_of='.$id.'&order=ASC'); ?>
<?php if(have_posts()) : while (have_posts()) : the_post(); ?>
<dt><a href="<?php the_permalink();?>"><?php the_title();?>:</a></dt>
<dd style=""><em><?php the_excerpt(); ?></em></dd>
<?php endwhile; endif; ?>
</dl>
</div>
</div>

<?php get_sidebar(); ?>

<?php get_footer(); ?>

Next we have an example page template, again based on the default theme, for listing grandchildren:

<?php
/*
Template Name: Page with GrandChildren
*/
get_header(); ?>

<div id="content" role="main">

<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
<div id="post-<?php the_ID(); ?>">
<h2><?php the_title(); ?></h2>
<div>
<?php the_content('<p>Read the rest of this page &raquo;</p>'); ?>

<?php wp_link_pages(array('before' => '<p><strong>Pages:</strong> ', 'after' => '</p>', 'next_or_number' => 'number')); ?>

</div>
</div>
<?php endwhile; endif; ?>
<?php edit_post_link('Edit this entry.', '<p>', '</p>'); ?>
<div id="children">
<dl>
<?php query_posts('static=true&posts_per_page=-1&child_of='.$id.'&order=ASC'); ?>
<?php if(have_posts()) : while (have_posts()) : the_post(); ?>
<?php     $inner_query = new WP_Query("post_type=page&posts_per_page=-1&child_of={$id}&order=ASC");
while ($inner_query->have_posts()) : $inner_query->the_post(); ?>
<dt><a href="<?php the_permalink();?>"><?php the_title();?>:</a></dt>
<dd style=""><em><?php the_excerpt(); ?></em></dd>
<?php endwhile; endwhile; endif; ?>
</dl>
</div>
</div>

<?php get_sidebar(); ?>

<?php get_footer(); ?>

Hopefully these examples are illuminating!

According to there counts I have made 500 commits to the trunk section on the WordPress subversion repository.

The plugin is also now hosted on WordPress.org Extend as PJW Query Child Of and I have also writen up some example php code so as to make it really easy to use!

curl "http://phpdoc.wordpress.org/trunk/li_WordPress.html" | grep "wp_list_pages" | sed "s/^.*'\(.*\)'.*'.*'.*$/http:\/\/phpdoc.wordpress.org\/trunk\/\1/"

It needs some optimisation though.  It’s too long to tweet!

For me, responsible open security practises should mean that as well as providing a quick response to security issues you provide enough detail about the issue to your users to allow them to make a judgement call about how important the upgrade is to them.  Do they need to do the upgrade immediately because the issue is easy to exploit or can it wait till the weekend when they have more time to ensure they have a backup and a plan for when the upgrade goes wrong.

The WordPress project tries to provide this information and we provide clear security release announcements on the development blog which is syndicated into everyones dashboard.  The habari project however seems to be happy with a release announcement which basically says – “Hey, you blog is vulnerable to some critical security issue but we fixed it for you upgrade now!“.

For example in the WordPress 2.6.2 announcement we have:

Stefan Esser recently warned developers of the dangers of SQL Column Truncation and the weakness of mt_rand().  With his help we worked around these problems and are now releasing WordPress 2.6.2.  If you allow open registration on your blog, you should definitely upgrade.  With open registration enabled, it is possible in WordPress versions 2.6.1 and earlier to craft a username such that it will allow resetting another user’s password to a randomly generated password.  The randomly generated password is not disclosed to the attacker, so this problem by itself is annoying but not a security exploit.  However, this attack coupled with a weakness in the random number seeding in mt_rand() could be used to predict the randomly generated password.  Stefan Esser will release details of the complete attack shortly.  The attack is difficult to accomplish,  but its mere possibility means we recommend upgrading to 2.6.2.

Comparing this to the recent habari annoucement:

The Habari Community announces the release of version 0.5.2. This version is a critical security update; all users of any version prior to 0.5.2 should upgrade at once. Additionally users of HEAD should also update to the latest revision.

Thanks are due to the entire community for identifying and patching this bug in a timely manner.

This isn’t very detailed and leaves me wondering – What was the issue? How serious was it? Is the issue such a bad example of security aware development that they don’t want to highlight how wrong they got things?

Don’t get me wrong, I am please that security matters for the habari project and I know the difficulties involved in developing secure software, I just feel that you need to be open with your issues to build trust with your users.

Update:  There is now a much clearer release announcement for habari v0.5.2.