All New WordPress.com

Almost 2 years ago, I wrote about how the future of WordPress needed to be a REST-based API, with a JavaScript client on top of that. There were even public rumors that, gasp, we were thinking about porting WordPress to Node.js. Well, while that’s not exactly true, it’s closer to the truth than a lot of people probably realized.

We are in fact using Node.js to power part of WordPress.com now. If you go to https://wordpress.com while logged in, your request is handled by a Node.js server, and the entire UI is written in JavaScript, although the majority of it is actually React.js. Unless you end up back in wp-admin, your admin/editing/posting/dashboard experience on WordPress.com is now handled entirely (well, almost; we’re still working on some pieces still) with JavaScript.

The UI is fully responsive (optimized for multiple screensizes, and flexible in between). Data updates are live (combination of polling and websockets, moving more to sockets over time). No full-page refreshes (it’s a single-page app). All API-driven (which means we can, and are, using the same APIs to power portions of the native mobile apps). Speaking of apps, we’re able to bundle our single-page, JavaScript application as a native app, so we did (OSX for now, Linux and Windows coming very soon). Leveraging our infrastructure, and the power of Jetpack, we can provide self-hosted users with the same experience as those we host directly (with more Jetpack-specific functionality coming soon as well).

This is a lot of change. But it goes deeper than just the entire technology stack we’re working on now. This was a complete culture-shift for Automattic, a now-400-person company traditionally made up of approximately 100% PHP developers. To get here, we at Automattic took a step back and asked ourselves;

What would WordPress.com look like if we were to start building it today?

As part of answering that question, we made a lot of changes internally:

  • Cross-trained all of our PHP developers (and some of our mobile developers!) into modern, performant JavaScript developers.
  • Switched to a completely GitHub-based workflow.
  • Every commit is now peer-reviewed.
  • Shifted to a very component-minded architecture.
  • Moved our WordPress codebase to be entirely API-driven. New features are now only launched as a new/modified API endpoint + data layer + UI layer.
  • Change in thinking from being very “plugin-oriented” (similar to WP-core) to a much more integrated and cohesive way of thinking of things across the web and mobile apps.

So today, in keeping with the DNA of Automattic, which shares the DNA of WordPress, we’re releasing what we’ve been working on as open source. It’s code-named “Calypso” (long story), and we’re extremely proud of what we’ve built over the last ~18 months. I truly hope that this can help guide or influence WordPress.org‘s future.

I wrote this post in the Calypso/WordPress.com Desktop app, and published it via Jetpack. That feels pretty darned good.

One Less Plugin, Thanks Jetpack

As a developer, I’m a huge fan of “red changesets”; when you get to delete more code than you add. Less code means less maintenance, less potential for bugs, security problems, etc. Today I got to “red changeset” the plugins powering this website because I realized I could just go ahead and delete the plugin I was using for update notifications.

I’ve been running a plugin here for a while now that emails me when I have updates available for plugins, themes or core on my WordPress installation. With the latest version of Jetpack though, I get that notification via a simple little indicator on WordPress.com (and I’m there every day already). In addition to the notification, I’ve enabled the auto-update feature for all plugins on all sites connected via Jetpack, so now I don’t even have to think about keeping my plugins up to date.

There’s a lot more cool stuff coming in this Jetpack/WordPress.com integration, and I’m really excited to see (and work on) what we can do to help make life easier for self-hosted users while leveraging the power of WordPress.com.

Simple Search Operators

I’ve long wanted to be able to do some simple, operated-powered searches within WordPress (especially relevant in a project I’m working on at Automattic). After a conversation with Allen, where he wanted to do the same thing, I figured I’d just whip up a quick plugin to see how hard it’d be. Turns out the answer is “not very”.

Simple Search Operators is a quick plugin that expands the functionality of the default search system in WordPress so that you can use a few useful operators (might look at adding some more at some point) [all links in the following list go to live searches on this site, using that operator]:

  • author:beau will limit results to posts written by the author with the username/slug ‘beau’
  • tag:burrito will only return posts which are tagged with ‘burrito’
  • category:posts (or cat:posts) to search for posts categorized as ‘posts’
  • tag:burritofriday cancun author:beau to search for posts containing ‘cancun’, written by ‘beau’, tagged as ‘burritofriday’

Some caveats:

  • Not heavily tested! May well be capable of generating server-melting queries
  • Only supports one of each operator for now
  • Operators and freeform searches may be combined (e.g.: “tag:burrito cancun”)
  • Does not support spaced strings for operators, so you can only do things where a no-space string attached to an operator will get you what you want
  • Because of the way it manipulates query variables, might mess with other plugins or themes in adverse ways. Like I said, not heavily tested.
  • Not available via the WP Plugin Repo yet; will get it up there once it’s baked a little bit

If you’d like to give it a shot, please do. If you’d like to add more operators; shoot me a pull request and we can expand this out a bit.