Switching from Manual to Automattic

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.

WordPress Sussex and Surrey meetup group

As I mentioned in my previous post I’m thinking of starting a meetup group for all things WordPress in the Sussex and Surrey areas.

I’m not sure of the exact format yet but I’m thinking if we start with small ambitions and try organise a monthly meetup for users and developers interested in WordPress and any of its sister projects.

I am thinking of organising something on a week night with the first meetup to happen in August and then try to arrange them to occur on a monthly basis.

So as I can get an idea of interested numbers and ideal locations please comment on this post if you would be interested in attending letting me know if there are any week nights you can’t do and with the area you would be travelling from so I can try to pick somewhere that is easily accessible to as many people as possible.

Once I’ve got a good idea of numbers and localities I will arrange the first meetup.

Thoughts on #wordcampuk 2010

This past weekend was the 3rd WordCamp to be held in the UK and I had a great time both as a speaker and a participant.  It is great to see how the event has grown over the past 2 years from a small affair with around 50 attendees up to one with around 150.

I am really impressed with the way in which a disparate group of people have pulled together with little central coordination and pulled together a great event. However I do think that we need to sit back and reflect on where we have come from where we are going and what is going to serve the community at large.  The community of WordPress users and developers has grown at an astounding rate over the past few years and so has the number of WordCamps.

For me this years WordCamp had some great learning points for how we can do better – these come from things that have affected me directly and also feedback I have received from others.

  • We need to get tickets on sale earlier – people like to organise their weekends and travel in advance
  • We need to organise the schedule better – having focused tracks for different audiences with a list of topics and presenters available in advance so that people can plan their schedule and know what they are going to find out.
  • We need to think about how we lay out the rooms – It was harder to get to know the other attendees this year because we were in front facing lecture theatre style layout rather than the Banquet/Cabaret style layout we’ve used in the past
  • We need to think about naming – WordCamps are big and small and I think that the UK community has reached the tipping point where it could support more than one some years. We could do more to emphasise that by thinking about the name and maybe name the next one after the City/Town/Region that it is held in to make it really obvious that other UK based WordCamps would be great.
  • I think we should try harder to organise some more regional groups to try an emulate the success that has been achieved in Manchester – I wonder how many people would be interested in a monthly WordPress Sussex meetup?  Let me know!
  • We need to think more about the social events – It was great to get to visit FAC251 but it really wasn’t the best venue for networking and talking to other WordPress users / developers – I would have much preferred a quieter venue where I could have actually talked to people and not felt like I was melting.
  • We need to consider focussing on a single kick-ass day of major sessions and the leaving the second day for more informal networking and BarCamp style lightning talks – this is a format that quite a few other WordCamps around the world are using with great success and ensures that there is lots of time for the spontaneous connections to be made.

I know that some of these suggestions may seem controversial, and I’ve read about the wrap-up session that I missed, but we should remember that anyone in the community at large has the right to organise another WordCamp and if there are people in the UK that would like to organise other “competing” events I think we should try as hard as possible to support them in any way we can – we know how difficult it was to get the first event off the ground and have built an infrastructure of contacts and resources that they should be able to leverage to make it easier.

If you want to get involved in organising a WordCamp and want to find out more read on here and if you have any questions feel free to email me!

Don’t blame the Kitteh

During last nights WordPress dev chat we got distracted by the Kitteh.  Now we have a WordPress Kitteh meme – http://cheezburger.com/View/3444964352

My contribution:

Ok intarwebs, sawry, working on 3.0 now

Ok intarwebs, sawry, working on 3.0 now

Tags: ,

Mangling strings for fun and profit

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.

Missing dashboard css and the perils of smart quotes

This is the tale of a mystery and intrigue about the disappearance of the css from a blogs dashboard and how we hunted it down and fetched it back.

Thord Daniel Hedengren, one of the writers for Blog Herald, put out a plea for help on twitter and was pointed in my direction.

He was faced with a WordPress dashboard which looked like this and wasn’t much use:

WordPress 2.8.4 dashboard without all the styling

WordPress 2.8.4 dashboard without all the styling

This evening I hooked up with Thord and with the help of his server administrator we tracked down the issue and thought it a good idea to spread the message to help any one else out there who has a similar issue in the future.

I started off by looking at the headers returned by the php file which concatenates all the CSS files together and noticed something strange:

HTTP/1.1 200 OK
Server: nginx/0.7.62
Date: Tue, 29 Sep 2009 19:34:47 GMT
Content-Type: text/css;charset=“utf-8″
Connection: keep-alive
X-Powered-By: PHP/5.3.0
Expires: Wed, 29 Sep 2010 19:34:47 GMT
Cache-Control: public, max-age=31536000
Vary: Accept-Encoding

As you can see here the Content-Type header looks a little strange, it has a charset specified but the value being returned is not a valid charset and it looks like this is probably why Firefox is refusing to apply this css file to the page.

This was starting to look like a server configuration issue so we got in contact with the server admin and we tracked down the errant configuration to the php.ini file.

Within the php.ini file you can set a default charset to be used if one has not already been specified for the request this had erroneously been set in the file with some smart quotes rather than normal quotes and so php was outputting the smart quotes as well as the charset name into the HTTP header.

Now the headers look like this and Firefox is happy to display a fully styled WordPress dashboard:


HTTP/1.1 200 OK
Server: nginx/0.7.62
Date: Tue, 29 Sep 2009 19:39:17 GMT
Content-Type: text/css;charset=utf-8
Connection: keep-alive
X-Powered-By: PHP/5.3.0
Expires: Wed, 29 Sep 2010 19:39:17 GMT
Cache-Control: public, max-age=31536000
Vary: Accept-Encoding

In short, check the configuration you use for default_charset in your php.ini file and don’t use any quotes unless you need to the following works fine in my testing:


default_charset = utf-8

Feeding on feedback and progress

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

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



d
go to dashboard
l
go to login
h
show/hide help
e
edit post/page
r
comment on post/page
m
go to moderate comments
esc
cancel