scribu

Putting Some Backbone Into Posts 2 Posts

The last major release of WordPress (3.5) got the first dose of Backbone.js in the form of the revamped media manager.

Since I’ve been itching to play around with it for a while, I decided to backboneify the javascript-heavy metabox from the Posts 2 Posts plugin, following this guide.

In the first part, I organized everything into Backbone Views. Even though there were some awkward parts, I already felt this was a big improvement.

In the second part, I started using proper Backbone Models, successfully separating AJAX logic from DOM manipulation.

After this little experience, I think Trek’s summary is spot on:

Backbone is approachable if you've spent some time writing applications with jQuery and are familiar with callback-style evented architectures. Backbone's DNA is basically jQuery custom events on steroids.

P2P 1.5 isn’t ready yet, but if you want to play around with it, you can get it straight from github:

git clone --recursive git://github.com/scribu/wp-posts-to-posts.git

WordCamp Norway 2013

Last weekend I had the pleasure of attending WordCamp Norway 2013.

On the first day, I gave a talk entitled Command Line Learnings For Make Benefit Glorious Nation Of WordPress. (I’ll link to the video when it shows up on wordpress.tv.)

After the main conference event, there was an after-party, which was more of a fireside chat actually (we were literally sitting next to the fireplace in the hotel lobby), and it was great.

On the developer day, I just threw together a few links to useful resources about automated testing of WordPress things.

I thought it was cool that there was also a charity hackathon organized for improving the WordPress site of a non-profit organization.

Oh, and did I mention the t-shirts?

PS: If you’re wondering what I used to make the slides, see github.com/scribu/wordcamp-norway-2013.

Mobile OS Mess

The last time I pondered on operating systems, it was all about how tablets and their touch interfaces are affecting the traditional desktop OS. Now, I’d like to consider the mobile scene specifically.

The current landscape is dominated by iOS and Android, which both work on smartphones and tablets.

Microsoft is trying to get Windows Phone 8 off the ground, with a half baked attempt to bring the same interface to other devices, in the form of Windows 8.

Canonical recently announced Ubuntu Phone OS, with support for both webapps and native apps. They actually have some credibility when they make the claim of shipping a unified interface across all devices.

Probabily the most interesting development is from Mozilla, which has a relatively new project called Firefox OS, where everything is a webapp.

So, we’ll soon have two competing open-source mobile operating systems from two reputable FOSS organizations. A lot of pundits are saying things like They don’t stand a chance against iOS and Android; they’re already entrenched.

I, for one, don’t really need a mobile OS that everybody uses. If they work well enough and a healthy ecosystem of hackers emerges around them, it’s a win.

In the mean time, the most pressing question is this: What should I replace my aging iPhone 3GS with?

Update: For a much more thorough overview of the situation, see Early Thoughts on New Operating Systems.

Switched to Jekyll

WordPress is about democratizing publishing; that is to say it’s meant to be easy to use by anyone, whether they have technical knowledge or not. Jekyll, in contrast, is designed to appeal to developers. It allows you to treat your content as source code, employing familiar tools such as text editors and version control systems.

No more logging into wp-admin and clicking around to manage content. I can write blog posts from the comfort of vim. ¹

No more worrying about making database and file backups. Everything is stored in git.

No more worrying about caching and scaling. Serving static files is a walk in the park for even the frailest of web servers.

No more keeping WordPress and plugins up to date.

No more ssh-ing into the server to work on the theme; develop locally using jekyll --auto --serve and deploy with a simple git push. ²

Comments are handled by Disqus. If you’re thinking “I would never entrust my site’s comments to a third party”, just keep in mind that they’re not your comments; they belong to whoever wrote them.

I did have to give up a few things outright: search, tag and date archives, oembeds, random quotes in the footer. They’re nice to have, but not essential.

For the migration, I used the wordpress-to-jekyll-exporter plugin. The design is a modified version of the wp-svbtle theme, ported to Jekyll.

I don’t know if it’s a post-CMS world, but there are definitely more options to choose from.

The chief lesson I have learned in a long life is that the only way to make a man trustworthy is to trust him; and the surest way to make him untrustworthy is to distrust him and show your distrust.

Henry L. Stimson

Contributing To WordPress (Using Github)

More and more people are realizing that git is awesome. Although the official WordPress source code still lives in an svn repository, you can contribute patches without having to touch svn ever again.

So, without further ado, here’s how you can generate and manage patches for WordPress Core (it assumes you’re comfortable with the command line).

1. Find a ticket to work on.

Patches need to be attached to tickets. You can browse through existing tickets in trac or create a new one. The Contributor Handbook has more details on the bug tracking workflow.

2. Clone the official mirror.

There’s an official mirror of WordPress on github, so let’s use that:

git clone git@github.com:WordPress/WordPress.git wp
cd wp

3. Make a feature branch.

Once you’ve got the ticket number, create a branch:

git checkout master -b some-feature/123

where 123 is the ticket number.

Now, make the code changes you need to make and commit them (you can do several commits; it doesn’t matter):

... edit some files...

git commit -am "fixed the bug"

... edit some more files

git commit -am "fixed edge case"

3. Generate the patch.

Here’s the clever part: you can generate an svn-compatible patch directly from git:

git diff master... --no-prefix > some-feature.123.diff

If you want to skip the --no-prefix arg, you can update your gitconfig:

git config --global diff.noprefix true

All you have to now is upload some-feature.123.diff to the trac ticket. Done.

Optional: Publish your feature branch.

If it’s a big feature and you want to get feedback on it – without having to upload a new patch each time you make a change – you can push your branch to github.

First, you need to fork WordPress/WordPress (there’s a button for that) and register that fork in your local clone:

git remote add scribu git@github.com:scribu/WordPress.git

After that initial step is done, whenever you want to publish a branch, you can just do:

git push -u scribu some-feature/123

WP-CLI Gets A New Home

WP-CLI is now at version 0.7.

Going forward, all announcements related to the WP-CLI project will be posted on the WP-CLI blog.

For an illustration of how people’s emotions drive technical decisions and opinions, read any flame war about anything, ever.

On Being A Senior Engineer

defaultdict In PHP

In the little experience I’ve had with programming in Python, I’ve found the defaultdict class to be one of the most useful.

PHP already has a limited version of this feature built in, called autovivification:

$arr = array();
$arr['foo']['bar'] = 1;

print_r( $arr['foo'] );  // Result: Array ( [bar] => 1 )

print_r( $arr['baz'] );  // Result: Undefined index: baz

As you can see, it doesn’t work when accessing an undefined value; when implicitly setting a value, you can only construct arrays.

Fortunately, it’s pretty easy to implement our own version of Python’s defaultdict by using the special ArrayAccess interface (requires PHP >= 5.3.4):

You use it just as if it were a regular associative array:

$counts = new Defaultdict(1);

echo $counts['foo']; // Result: 1

$counts['bar']++;

echo $counts['bar']; // Result: 2

And you can even pass an anonymous function for constructing new default values:

$instances = new Defaultdict( function( $key ) {

	$value = new stdClass;
	$value->id = $key;

	return $value;
} );

print_r( $instances['bar'] );  // Result: stdClass Object ( [id] => bar )

WordPress Plugin Troubleshooting Flowchart

A few days ago I made a little flowchart describing how, given plugin X, you could determine if it was conflicting with some other plugin Y, or with your theme.

It seems to have really taken off on twitter, so I’m posting it here as well, for safe keeping:

To the extent possible under law, scribu has waived all copyright and related or neighboring rights to WordPress Plugin Troubleshooting Flowchart. This work is published from: Romania.

There’s also a Japanese version.

It seems I went over the process of figuring out why a plugin is broken before.