The Future of WordPress: REST API + Javascript single-page app?

DISCLAIMER: These are my personal thoughts only, based on what I’m seeing around the web over the last few years.

Working on o2 for the last few months, and spending more and more time in amongst the Javascript community at events like jQueryConf, BackboneConf and dotJS, I’ve started thinking about the future of WordPress differently.

WordPress currently consists of a large, complex, PHP codebase, sitting on top of a MySQL backend. plugins are primarily PHP, with a light sprinkling on Javascript to mostly provide UI “candy”. Part of the reason for that is probably because:

  1. It’s pretty hard to interact with WordPress on any real depth using Javascript, and;
  2. If you’re trying to provide any custom functionality for WordPress, you pretty quickly end up doing it in PHP because that’s where all of the internal APIs and functionality resides.

That’s been a fine approach for the last 10 years, but I believe that things are changing, and we need to change with them to remain relevant. Full page reloads with heavy server-based everything is no longer really acceptable for a solid UX. With that in mind, here’s a possible future for WordPress, extrapolated out from where some things seem to be going (on the wider web, not necessarily currently within WordPress development):

WordPress core becomes 2 “separate” portions; one is a PHP-based REST-style API. Effectively, a layer that provides a structured API onto our database. That would cover all posts, users, settings, queries, meta data etc that lives within the WP DB. The other piece would be (ideally) a pure Javascript, single-page web application which fully implements the API to deliver what we currently know as wp-admin.

Plugins would create additional endpoints within the backend API, or would supplement existing ones (e.g. post/meta) with additional data and/or actions. They could also be implemented via pure JS, depending on what they were built to do. Themes could potentially be built using no PHP at all — making queries directly to the API via JS, and then using something like Mustache to template the output back to the user. This would have SEO ramifications, but we can always figure something out there, and search engines are constantly improving.

To get there would take a long time, and at many points it would no doubt break all sorts of plugins. This would be a huge shift and I think would actually be really hard to accomplish within the community, which makes me scared because I think it will be rejected as a direction (or at least slowed down a LOT) because of backwards compatibility at the very least. Perhaps we can maintain backwards compatibility for some plugins by at least making the new wp-admin a hybrid app, which leverages a JS-based approach for all truly core functionality/views, and then falls back to full page reloads for plugin-based admin functionality. Without a lot of work, that approach would still break for “integrated” plugins (where they inject settings  into or manipulate existing admin pages), if we assume that all of those pages would become powered by/created via Javascript + API interactions.

Unfortunately a crucial point where backwards compatibility would be important would be the Post Editor, which is also where some big performance/UX improvements could potentially be seen by switching to a largely JS-powered UI.

I don’t know if this is really where WordPress will go, or if it is, exactly how it will get there. There’s a project currently to build a core REST API which I’m eagerly observing and will be trying to get more involved in. It has the potential to become the kernel of the future of WordPress if it’s done right. This is going to be a long road either way, so I’m excited for where we can all go from here.

Do you think WordPress can (or should) move in this direction?

A Whole New Dented Reality

Back in April, this blog celebrated 10 years of existence, and it’s been almost five years since the theme on this site changed. Yesterday I decided to just go ahead and flip the switch on something I’ve been working on here and there since late last year. It’s a complete new, very experimental theme that I call “Homeroom“.

There are some specific things driving what I was aiming for with Homeroom:

  1. First and foremost, a lot of the decisions are based around the intention that it would use Keyring and the Social Importers to pull in my content from all over the web. With that much data being collected and displayed here, I realized I couldn’t go exactly with a traditional blog layout, and had to get a bit creative with some types of data.
  2. It’s intentionally heavily integrated with Jetpack (although it works without it). Jetpack powers the comments, infinite scroll, sharing buttons and more. I’ve taken care to try to make that integration feel as native as possible (although I know there’s more to be done there).
  3. Homeroom started out as an _s-based theme, although it’s been pretty radically modified from there.
  4. I’m using a technique that I’ll call “post lookahead” when going through the loop to check the next post, and do some things like collapse sequential posts if they’re the sam type of thing.
  5. I wanted something with a bit of a timeline feel, since it’s now collecting some much data, and it’s all sequential; I wanted to show the relationship of different things along that sequence of time.

It’s not particularly beautiful because, well, I’m not a designer :) In the near future I’ll be talking to some friends who are though, so hopefully I can get some advice on improving things there. I’ve been mainly focused on getting it working the way that I wanted it to. Here are some other bits that might be interesting:

  • Allows custom Header and Backgrounds via wp-admin
  • Options (currently defined in a file, because I haven’t built a UI) to control some preferences around stuff like hiding Foursquare check-ins until a set amount of time after they happened (to help avoid the creepers!).
  • Heavy use of Post Formats
  • Ability to hide Twitter replies, which you probably don’t want showing up on your site.
  • There’s the beginnings of a front-end post box (partially inspired by o2), although it doesn’t actually work yet
  • Handles Foursquare checkins differently. Rather than showing them all as individual posts, it “collects” them and shows a single, multi-point map at the end of each day.
  • Shows a map automatically on any post using the WordPress-recommended postmeta fields.
  • Using the new taxonomy introduced in Keyring Social Importers 1.4, allows you to easily filter your display based on where posts were imported from.
  • Includes a custom icon font from IcoMoon to display social icons indicating where things were imported from.
  • Search results use a Masonry-based layout so that you can quickly scan the results. Unfortunately something is broken with the search mechanism on this site right now, so that’s not working :(
  • Automatically lists out child-pages when you view a Page that has them, for example my Projects page.
  • Dynamic heading re-writes: format your posts for individual viewing, and the H1 etc tags are automatically “stepped down” on listing pages to maintain hierarchy
  • Has some fun mapping stuff for TripIt in particular, which draws out a “flight path” between airports. Check it it out in my TripIt section. Here’s a fun one.
  • Uses Photon to apply some effects to images in places
  • Borrows liberally from the styling of sites like Instapaper and Readability.

There’s still a lot of work to go, both on the theme itself and the importers that power a lot of the content. I wanted to get this online because I knew that’d motivate me to spend more time on it. I’m also hoping that other folks might be interested and/or have some ideas on ways to improve the theme. I haven’t got all of my content imported yet (that takes a while :) ), but you’ll see more and more things fill in over the coming week hopefully.

If you’ve got any ideas for improvements, I’d love to hear them down in the comments!

Keyring v1.5 & Social Importers v1.4

Yesterday, I released version 1.5 of Keyring, and version 1.4 of the Keyring Social Importers bundle for WordPress. This update moves the Social Importers away from using a postmeta value (keyring_service) and introduces a new taxonomy that keeps track of where posts were imported from. It’s optimized towards management within wp-admin, but you can also use it for front-end queries of your posts. The update for Keyring introduces a new service file for Moves, and fixes a bug in the OAuth2 base service.

The new taxonomy for the Importers is called keyring_services on the backend, and is labeled “Imported From” in the admin UI. It will auto-create itself based on all of the importers installed. You’ll see it within wp-admin under the Posts menu, and will be listed on the “All Posts” listing as well:

Screen Shot 2013-09-15 at 9.10.59 PM

Clicking the name of a service under the “Imported From” heading will filter the posts list by that service (e.g. Twitter). The main reason that the taxonomy is exposed through the admin UI is so that you can tweak the slugs if you’d like to. I noticed that on my install, I’d already used things like ‘twitter’ and ‘foursquare’ as tags, and so they had claimed the namespace for that slug. WordPress’ shared terms are annoying like that :). So, if you’d like to use the slugs of source services in URLs, you might want to rename them:

  1. Go to Posts → Tags
  2. Search for and rename the slug for each of the services (e.g ‘twitter’, ‘foursquare’, ‘flickr’). Name the slugs something like ‘twitter-3′
  3. Go to Posts → Imported From and rename the slugs for each service to the “clean” version (without a ‘-2′).
  4. Optionally go back to Posts → Tags and rename those tags again back to the -2 versions.

As part of this change, you’ll want to update any previous posts that you imported to using the new taxonomy. I’ve included a quick and dirty script to do this. It’s called migrate-keyring-postmeta-to-taxonomy.php and can be found in the root of the plugin. To use it, you need to move it to the root of your WordPress install, and then you can just access it through your browser. It’s likely that it’ll run out of memory or time out, but it’s written in a way that you can just run it over and over again until it finishes cleanly. On my server, once it was finished and produced no output, Chrome decided to display a “friendly” error message instead of anything useful. Once that’s done, your existing posts should all be converted over to using the new taxonomy, and there should be no more postmeta entries for keyring_service.

If you’re doing a clean import, I recommend doing it without auto-import enabled, and then once you’ve fully imported everything, enable auto-import and let it run from there.

o2 at WordCamp San Francisco

I just realized that I never posted anything about speaking at WordCamp San Francisco. This was my 8th WordCamp SF (I’ve been to every one since the first, in 2006), and the second one at which I have spoken. Matt invited me to give a short introduction to the work we’re doing with o2, which is the next generation of P2. It’s not available for external (non-Automattic) use yet, so I had to settle for a relatively surface introduction, and couldn’t give people a link to download it or anything which was a bit of a pity, but it still got a good reception.

o2 is a pretty different approach to building on top of WordPress, and has meant a steep learning curve for my team and me. We’ve been digging deep into the world of front-end development, and ramping up quickly on Backbone.js, Underscore.js and a bunch of new development approaches and workflows. It’s been really fun. I’ll let the presentation do the talking though (you can also watch it on WordPress.tv):

And here are the slides I used, which you can also see on Slideshare.net.

We’re really excited to get o2 out into other people’s hands, but we’ve got a lot to build still before other people can experience it in a similar way to how we do at Automattic. The future is bright.