SublimeCodeIntel in Sublime Text 3

There is now a Sublime Text 3 compatible version of SublimeCodeIntel, thanks to the hard work of Germán M. Bravo (aka Kronuz). I had a job getting it to correctly index my project files though. I’m posting here what I did, in the hopes it’ll help someone else out.

1. Use the development branch

I’m not using the Package Control version of SublimeCodeIntel (I’ve looked at the version numbers and they are the same, but I couldn’t get it to work). Instead, I’m using a Git checkout of the development branch.

In the Sublime Text menu, go to Preferences -> Browse Packages. From this directory I ran the command:

git clone -b development [email protected]:SublimeCodeIntel/SublimeCodeIntel.git

2. Clear your codeintel cache

Your codeintel cache probably needs clearing if, like me, you’ve had older versions of SublimeCodeIntel installed.

To do this, quit Sublime Text then go to your home directory and delete the entire .codeintel directory (eg. on OS X this is at ~/.codeintel). If you have a config file in there that you’ve made changes to, back it up first.

3. Fix the language-specific config

This appears to have been the key problem for me. Inexplicably, SublimeCodeIntel’s default config disables project scanning for PHP and JavaScript files. Why? Who knows.

To fix it, open the Sublime Text menu and go to Preferences -> Package Settings -> SublimeCodeIntel -> Settings – Default. At the bottom of this file are language-specific settings for Python, JavaScript, and PHP.

Do not edit this config directly. Instead copy its contents completely and paste it into your user settings (Preferences -> Package Settings -> SublimeCodeIntel -> Settings – User). Then delete the PHP and JavaScript settings from the bottom, or at least change the codeintel_scan_files_in_project settings to true.

4. Be patient

When you first begin typing a function name or other entity that triggers codeintel, the status bar will show you that the initial scan is taking place. I’ve noticed that this status message disappears before scanning is actually complete, or it’ll state that scanning is complete when it’s not. Be patient, and it will get there eventually.

WordPress Contributors on a World Map

As a fun data visualisation experiment – and as a way to practice my new found interest in Node.js – I decided to plot on a map of the world all the people who contributed to the recent release of WordPress 3.6. The map can be seen further down, but first a brief description of how I went about it.

I decided to generate a GeoJSON file of the contributor’s locations so it can be displayed wherever and however the open GeoJSON format is supported, not least on GitHub which recently added support for automatic rendering of GeoJSON files.

In order to get the location data for each contributor I would need to scrape it from In my simple Node script I started by using Node’s HTTP interface to fetch the 3.6 announcement blog post. The content of the post was then loaded into Cheerio which provides a wonderful implementation of jQuery’s core for working with the DOM, and used this to find the list of links in the blog post to profile pages.

Next step was to loop over each profile URL and fetch the page in order to pluck out the location data from the map shown for each user. With 225 contributors, it was clear this was going to be slow. Luckily the async module provides a super simple method for asynchronous iteration, so I used that to asynchronously fetch the profile pages.

The next step was to pluck out the user’s location from the markup using a straight forward regex, and then send this off to Google’s Geocoding API in order to get us the geographic coordinates we’d need. Out of the 225 contributors, 61 didn’t have their location displayed on their profile page.

The final step was to load all the data into the GeoJSON.js module in order to give us a valid GeoJSON file, and then pretty print it using the native JSON.stringify method.

Here’s the end result:

You can find the Node JavaScript in the GitHub repo if you’re interested.

A History of WordPress Contributors

I thought I’d run some stats on WordPress contributors over the years. The only contributor stats I have are the ones published in each release announcement on, so I’ve put these stats together myself from those lists.

Unfortunately the release announcements have only listed the contributors since version 2.9 (June 2009). If anyone wants to get me the list of contributors for earlier versions I’ll happily update this post. It’d be interesting to see the numbers over the years.

Contributors by Version

Version 3.0 has so far seen the highest number of individual contributors. The latest version – 3.4 – comes in second with 187. I thought I might see a steady increase with each version, but this is not the case, and we’ll see why below.

Also shown is the number of Trac tickets closed with each version. There’s a noticable reduction in the number of tickets closed since version 3.0 which closed over 1,200 tickets, with recent releases closing fewer than half that number. This correlates nicely with the recent drive to clearly define the scope of each release. We can probably all agree that Jane Wells is to thank for playing a big part in keeping WordPress releases on schedule recently.

Version Contributors Tickets Closed
3.4 183  592
3.3 179  587
3.2 132  409
3.1 173  840
3.0 210 1217
2.9 145  501

Version Involvement

WordPress sees long-term involvement from many people. Almost two hundred people have contributed to at least two different versions of WordPress since 2.9. The list got a bit long, so below I’ve listed the 120 people who have contributed to at least three out of the six versions released. While it’s not a good indication of the level of contributions by each person, it does demonstrate active involvment and an ongoing commitment.

Total Contributors

WordPress has seen 541 individual contributors over the three years and six versions since 2.9 in July 2009.

And Finally

It’s unfortunate that it’s not as simple to measure the involvement of all those people who contribute to WordPress in ways other than Trac tickets and patches. There are literally hundreds of people who spend their time helping others on the support forums and mailing lists, those who organise and attend WordCamps and WordPress meetups, and those who build and release plugins & themes. Without those people, the almost ten thousand improvements to WordPress wouldn’t be so useful.

Stats Elsewhere

A few other people have previously generated stats regarding contributors to WordPress. If you know of any more articles on contributor stats, leave a comment and I’ll add them to the list.

WordPress Plugin: Pocket Read It Later Links

Latest version: 1.0- Released June 15th, 2012:

  • Initial release.


This plugin allows you to display Pocket 'Read It Later' links next to each post on your blog. You can see an example on the Pocket blog. You can automatically insert the links adjacent to your blog posts or you can use the template tag to insert the links wherever you like.

What the hell is Pocket?


Pocket (formerly Read It Later) helps people who discover an interesting article, video or web page, but don’t have time to view it. Once saved to Pocket, the list of content is visible on any device — phone, tablet or computer. It can be viewed while waiting in line, on the couch or during commutes or travel — even offline.

Check out for all the details and to sign up.


You can install this plugin directly from your WordPress dashboard:

  1. Go to the Plugins menu and click Add New.
  2. Search for Pocket Read It Later Links.
  3. Click Install Now next to the Pocket Read It Later Links plugin.
  4. Activate the plugin.

Alternatively, see the guide to Manually Installing Plugins.

Once activated, check out the front page of your blog. A ‘Read It Later’ link will now show adjacent to each post.


By default, this plugin adds a ‘Read It Later’ link adjacent to each blog post on your blog. You can control where the ‘Read It Later’ links show up by going to the Settings -> Pocket Links menu in WordPress.


This plugin requires WordPress version 3.3 or later. Tested up to 3.4.2.

Version 1.0 ZIP file from

Any comments, questions, queries, suggestions, complaints, etc, please leave a comment!

Saving Post Meta Field Revisions in WordPress

If your plugin or theme uses custom post meta fields then you may want to store revisions to these fields when a post revision is saved. It’s easy to do.

For each of our meta fields, we’ll need to do three things:

  1. Store a revision of the meta field when a post is saved
  2. Revert to the correct revision of the meta field when a post is reverted
  3. Optionally, display the meta field on the revisions screen

In the code below I’m just saving revisions to one meta field, ‘my_meta’. You can of course save revisions to more than one meta field by looping over a list of fields your plugin uses.

Sorry about the poor code formatting in this article. I really need to fix the CSS on my site.

Storing a revision of the meta field when a post is saved

For this we hook into the save_post action and save the post meta data only if the post being saved is a revision. We need to use the low level add_metadata() function because if we use add_post_meta() then the meta data will be stored against the post instead of the revision.

function my_plugin_save_post( $post_id, $post ) {

        $parent_id = wp_is_post_revision( $post_id );

        if ( $parent_id ) {

                $parent  = get_post( $parent_id );
                $my_meta = get_post_meta( $parent->ID, 'my_meta', true );

                if ( false !== $my_meta )
                        add_metadata( 'post', $post_id, 'my_meta', $my_meta );


add_action( 'save_post', 'my_plugin_save_post' );

Reverting to the correct revision of the meta field when a post is reverted

For this we hook into the wp_restore_post_revision action and update the meta field to the version stored at the revision we’re reverting to. Again we’re using the low level get_metadata() function instead of get_post_meta() so we can grab the meta data from the revision instead of the current post.

function my_plugin_restore_revision( $post_id, $revision_id ) {

        $post     = get_post( $post_id );
        $revision = get_post( $revision_id );
        $my_meta  = get_metadata( 'post', $revision->ID, 'my_meta', true );

        if ( false !== $my_meta )
                update_post_meta( $post_id, 'my_meta', $my_meta );
                delete_post_meta( $post_id, 'my_meta' );

add_action( 'wp_restore_post_revision', 'my_plugin_restore_revision', 10, 2 );

Displaying the meta field on the revisions screen

For this we need to hook into the _wp_post_revision_fields action to tell WordPress which fields to show on the revisions screen, and hook into the _wp_post_revision_field_my_meta filter to display the meta field. Note that the filter name is specific for each field, so you’ll need to add a hook for each of your meta fields in the format _wp_post_revision_field_{field_name}.

function my_plugin_revision_fields( $fields ) {

        $fields['my_meta'] = 'My Meta';
        return $fields;

add_filter( '_wp_post_revision_fields', 'my_plugin_revision_fields' );

function my_plugin_revision_field( $value, $field ) {

        global $revision;
        return get_metadata( 'post', $revision->ID, $field, true );

add_filter( '_wp_post_revision_field_my_meta', 'my_plugin_revision_field', 10, 2 );

Putting it all together

Download the example code as a plugin here.

You’ll need to manually add/edit the ‘my_meta’ field using the Custom Fields panel on the post editing screen, then you can play around with viewing and reverting revisions.

Some considerations

The code used to display the meta field on the revisions screen will generate a PHP notice because WordPress looks for the my_meta element of the post object before calling the field callback function. There’s a ticket on Trac somewhere about improvements to the revisions screen but I can’t find it currently.

When you compare two post revisions using the compare functionality on the revisions screen the meta fields won’t be taken into account. Again, the revisions screen in WordPress needs some improvements in this area.