WordPress Planet

February 12, 2016

Matt: WordCamp US 2017 + 2018

When we chose Philadelphia to host the first ever WordCamp US, it was actually for two years, they’ll be hosting again this year December 2-4. We’re going to pick the host city and group for 2017 and 2018 in the next few months, though, and in fact the applications are open and closing in a few weeks. If you think your city and team have what it takes to wow the world with the best WordPress event, please put your hat in the ring!

by Matt at February 12, 2016 12:06 AM under Asides

February 11, 2016

WPTavern: WordCamp Europe Assembles 130-Person Volunteer Team


The call for volunteers for WordCamp Europe closed this week and organizers announced that they have assembled a team of more than 100 people to help run the event. The 130 applicants represent 33 countries from Europe and beyond, with the highest numbers from the United States, Germany, The Netherlands, Italy, and Romania.

The event will be held in Vienna at the end of June where the team will finally gather together in person. In the meantime, organizers are navigating the challenges of working remotely with a volunteer team that is spread across the globe.

“For now we are using Zapier with Trello as connected apps and lots of well organized columns,” said Milan Ivanović, one of the leaders of the Volunteer Team. “We contacted every volunteer via email manually and soon we will use WordPress Slack for general communication before and on the day of the event.”

WordCamp Europe organizers have high expectations for cities that apply to host future events. Potential cities will need to have a volunteer team with experience at previous events. This year’s event nearly doubles the number of volunteers from last year, expanding the pool of capable hands for 2017.

“The biggest challenge would definitely be meeting everybody’s wishes while assigning roles,” Ivanović said. “Next week we will do a final check of the venue and start working on assigning roles.”

Volunteers are expected to arrive a few days ahead of the event for a briefing and to familiarize themselves with the venue.

“Leading up to the event we are going to have weekly meetings and try to cover as much as we can to prepare as best as possible,” Ivanović said. “Volunteers are investing dozens of hours into this event. I also want to emphasize that we are not covering the costs, but there is something so noble and beautiful when volunteering.”

by Sarah Gooding at February 11, 2016 06:53 PM under WordCamp Europe

WPTavern: BuddyPress 2.5 Will Add Customizable Emails via a New BP Email API

BuddyPress 2.5 beta 1 was released this week with a list of new features and improvements to test, including a brand new BP Email API. The new API allows users to easily customize any email that BuddyPress sends, without having to leave the admin or write any code.


The ticket to overhaul BuddyPress emails was opened six months ago and has received more than 100 replies with feedback and patches from multiple contributors. BuddyPress lead developer Paul Gibbs spearheaded this initiative and summarized the outcome when introducing the new API on his blog:

In a nutshell, we moved emails into a custom post type (BuddyPress’ first!) with a supporting taxonomy (BuddyPress’ second!), devised a HTML email template with Customizer integration, and wrote a new API to manage how we represent emails internally and how we send them (goodbye, wp_mail!).

Gibbs has been writing plugins for the platform for the past seven years. He started with Welcome Pack, a plugin that allowed community admins to customize welcome emails to enhance the new user experience. His experience building and maintaining the now defunct Welcome Pack led him to work on improving BuddyPress’ core email handling.

“With retrospect, adding customizable emails to Welcome Pack is what killed my interest in that plugin,” Gibbs said. “It was such a lengthy, painful slog to get the customization working and nicely implemented (I picked the wrong approach), that when it was finally done, so was I!”

Gibbs’ work on this ticket makes emails in BuddyPress 2.5 much easier to edit than they ever were in his Welcome Pack plugin. The new Emails custom post type allows administrators to edit the content of the plugin’s 16 default emails directly in the admin. The email template can also be edited in the customizer at Appearance >> Emails with controls to change the header, body, and footer background colors, and text size/colors.

The new email capabilities allow BuddyPress community managers to personalize their sites’ communication without having a lot of technical knowledge. It’s a significant improvement over the generic stock emails previously sent by the plugin.

According to the project roadmap, the 2.5 milestone is now 96% complete and the official release is expected in three weeks.

by Sarah Gooding at February 11, 2016 03:28 PM under BuddyPress

February 10, 2016

Matt: Lent This Year: Buying Things

Today is Ash Wednesday and the start of Lent, when typically Catholics give something up, or try to form a new habit, for about six weeks. Many of my friends who aren’t Catholic do the same, it’s a good practice to try to go without something in your life you take for granted. It can make you reexamine assumptions, take you out of your comfort zone, or make you appreciate the thing you gave up much more when you return to it. Also it’s just a bit more fun when you do it with friends. 😀

Last few years I’ve given up:

  • 2013: Meat.
  • 2014: Smartphones. (This was hard!)
  • 2015: I meditated every day using Calm.

This year I’ve been thinking about what I take for granted, and surveyed friends for what their suggestions would be. One of the things that I’m pretty bad at is buying too many things, especially gadgets. I’m pretty good at clearing out old ones so it doesn’t get too cluttered, but I definitely have a habit of getting the latest USB gadgets on Amazon, shirts from Kit & Ace, workout stuff from Lululemon, shoes I don’t need, etc.

So the thing I’m going to give up this year is shopping or buying any material things. I’m also going to take the opportunity to try and reduce the stuff I do have in my life to things that spark joy.

by Matt at February 10, 2016 07:03 PM under Asides

WPTavern: Learn How to Test WordPress Core Patches with VVV on Mac OS


Testing patches is one way that both developers and non-developers can contribute to WordPress without writing any code. It’s a valuable service that keeps things moving along in tickets and helps patches make their way into core.

The most challenging part of testing patches is getting your testing environment set up properly. The WordPress core handbook has instructions for using Grunt to test patches, but they’re not easy to follow if you happen to be a more visual learner.

Yesterday Ryan Boren published a tutorial for testing patches with VVV on Mac OS, complete with screenshots at every step. The bulk of the instructions cover establishing a test environment with VVV, which requires you to install Vagrant, install Virtualbox, initialize Vagrant, install Git, and finally install VVV. Applying a patch and reverting it after testing is probably the easiest part of the entire process.

Boren’s tutorial is one of the clearest and easiest to follow, because it helps you visualize what success looks like at every step. If you want to add mobile testing into the mix while testing patches, check out his post on using VVV and xip.io. Boren explained how he goes through tickets with patches that change UI and adds mobile and desktop screenshots of his testing.

“These screenshots hasten UI feedback and usually reveal visual glitches on mobile that are then patched up, making our mobile experience that little bit better,” he said. “Until that blue sky someday when I can apply patches to a patch server with a tap, I’ve found VVV and xip.io to be the easiest way to do localhost testing of patches from mobile devices.”

The process of setting up a test environment is the most time-consuming aspect of testing patches, but once you have it in place, it’s easy to apply them. Have you found an easier way to test patches with support for mobile devices? Let us know in the comments.

by Sarah Gooding at February 10, 2016 12:30 PM under VVV

WPTavern: Automattic Launches Components with 5 New Starter Themes Based on Underscores


Automattic’s team of theme developers announced the release of Components today along with a suite of themes that extend the popular Underscores starter theme for specific use cases. These include a classic blog, modern blog, portfolio, magazine, and business theme. The new Components website lets theme authors download a theme that includes reusable components tailored to each theme type.


Each theme includes general layout structures and templates to support the specific type of theme. For example, when you select the ‘Portfolio’ starter theme, your download will include the following:

  • A portfolio post type, courtesy of Jetpack, added to all the necessary files
  • A grid portfolio view
  • A single column blog template
  • A sliding panel for navigation, social menu, and also widgets
  • A large featured image with full-width script

There’s not much to see once the theme is installed, because it’s just a starting point designed to save time when building layouts and templates. Automattic’s theme team used its collective knowledge of developing hundreds of themes in order to create these five starter themes with the bare basics required for presenting content via these five major theme categories.

Components was inspired by the community behind Underscores, according to Automattic theme wrangler David Kennedy. Developers using the starter theme often offered contributions that were beyond the scope of a simple starter theme.

“While maintaining and improving Underscores, we always see great pull requests from the community that we turn away because the contributions end up being too specific for a normal starter theme,” Kennedy said. “Many of those additions would have been perfect in most themes. Now, some of them have a home in a project that zeroes in on a certain kind of user with each theme it builds.”

The project’s goal is to provide a “more modular, pattern-based approach to theme development.” Even if you’re not building with Underscores, many of the theme components included in this project can be easily reused elsewhere as theme building blocks. The components library is open source and available on GitHub for anyone to fork.

by Sarah Gooding at February 10, 2016 05:19 AM under underscores

February 09, 2016

Matt: The Problem with Phone Calls

The Atlantic does an in-depth look on why it’s much less pleasant to have phone calls than it used to be. It’s true, but there are also some great alternatives that I’ve been having luck with recently. Facebook Messenger has a built-in audio (and video!) calling system that is okay. Facetime isn’t just for video, you can also make audio calls with it and they sound amazing (something I learned from Kanye, true story). Many times I’ll try a phone number in Facetime first just in case the person uses an iPhone. And finally Skype still works pretty well even if its clients are a bit heavy. If I’m able to be at a computer (all of these work on computer as well as apps), this Sennheiser USB headset sounds great, blocks background noise, and people say that I sound clear.

by Matt at February 09, 2016 11:58 PM under Asides

Post Status: Complete coverage should not be a requirement for core inclusion of WordPress REST API endpoints

The WordPress REST API is at a bit of a crossroads. There is a proposal on the table by the core team of four contributors — Ryan McCue, Rachel Baker, Daniel Bachhuber, and Joe Hoyle — to ship endpoints to WordPress core iteratively. There is a pushback on this proposal by WordPress Project Lead and co-founder Matt Mullenweg.

The API should be iterative, and should not require complete admin parity to be included, as Matt has proposed.

The state of what’s already in core, and what’s pending

The REST API infrastructure is already in core, having been included in WordPress 4.4. The infrastructure provides just that, an underlying infrastructure, to offer plugins a suite of base functionality to utilize, making the development of their own RESTful features easier.

The infrastructure allows developers to get a huge head start for creating their own REST API endpoints and functionality. The endpoints are how a third party client or developer would actually interact with the API, and the endpoints for WordPress core functionality are what are in debate.

Every piece of WordPress functionality — data that can be read, created, updated, or deleted — would ideally be available to the WordPress REST API, so that anything possible in WordPress is also possible via the API, and therefore also possible from a third party application interacting with the API.

However, creating this complete coverage is unrealistic in the current WordPress development structure, and should not be necessary for shipping initial endpoints to WordPress Core.

The proposal from the core REST API team is to begin by shipping four core WordPress objects: posts (meaning the posts table, which includes all post types), terms, comments, and users. These four core objects have been developed as endpoints, are well tested, and are ready for core. There are kinks to work out, but overall, they are an excellent starting point.

Matt’s proposal is that the API should not ship in core, with any endpoints, until complete “wp-admin coverage” is available: meaning that until all actions a user can make in the WordPress admin can be achieved via the API, then it shouldn’t go into core. He said in a meeting about the API, to firm up his proposal, that there should be, “no partial endpoints in core. let’s design a complete API, not half-do it and foist it on millions of sites.”

The primary areas not covered by the API currently are as follows: widget management and display, menu management and display, theme and plugin management, multisite management, and site options management.

So Matt would like to see each of these endpoints be developed and battle tested before any endpoints ship in core. I agree with the REST API team that the first four objects should take priority, and should go in before these other objects are ready. The remaining objects should each be feature plugins of their own, and go in over time, as they are ready, without delaying the four core objects currently under review.

Many use cases covered

Posts, terms, comments, and users endpoints make up practically all WordPress content. This means that a huge swath of use cases for the API are covered with these four objects.

Matt’s thinking that a core WordPress REST API should have all or nothing coverage is a false dichotomy. Applications like Calypso — a WordPress admin replacement based on WordPress.com’s own and separate REST API — are, I believe, the exception for usage of the REST API, not the rule. I believe most people that would take advantage of the REST API’s core inclusion are going to use parts of it only, and I believe most of what they’ll be seeking is content related, versus site management.

The WordPress admin is exhaustive: it’s pretty much anything and everything one would want to do in WordPress. Custom admins that would utilize the REST API are unlikely to completely mimic the current admin; if they were to do so, it’d be difficult to see the point of making such an application interface, versus just using the tried and true default. I’m certain some new full implementations of the admin will show up (similar to Calypso), but I don’t think it’ll be a common use case.

More likely, even custom admins would mostly be in the business of manipulating content — specifically catering content editing experiences for a specific type of website — and would be satisfied creating their own custom endpoints for other site management tasks until those endpoints are available through feature plugins or in core itself.

For tasks such as custom front-end websites that are decoupled from WordPress, the WordPress REST API is immediately useful, using the four proposed objects. As K. Adam White said, delaying the endpoints that are ready, “will effectively block a significant group of potential adopters coming from external platforms.”

The value of core inclusion, verses keeping endpoints in the plugin

Core inclusion of endpoints is a stamp of approval that the endpoints are ready for prime time. Organizations that would use the API for bespoke applications would prefer to know that the endpoints will be ready and available for the long term, and keeping endpoints out of core is a sign — intended or not — that things can change, and will prevent adoption that is important for WordPress’s growth.

Whereas, a procedure of iterative development, vertically focused by endpoint, can be a signal of readiness provided by the WordPress core team, essentially saying that those endpoints in core are stable and will maintain WordPress’s well known commitment to backward compatibility, while those endpoints in the feature plugin may be stable, but are subject to change.

Iteration has been good for WordPress

Iteration has been paramount to nearly all WordPress features, and it doesn’t make sense why it wouldn’t be a part of the REST API’s core inclusion.

In a meeting about the status of the API, Matt Mullenweg said, “I know it’s a minority opinion, but I would be pretty skeptical of merging a partial API into core, I think it would do a lot more damage than benefit.” I fail to understand what kind of damage including these endpoints would cause.

Matt has insinuated that the API as-is would be like shipping a car with no wheels, and I vehemently disagree with the analogy. I think the API is more like a Prius, and the goal is a Tesla. It’s a hybrid, with partial but important coverage, that betters the web (or the environment, for the car analogy). It’s not full coverage (like the fully electric Tesla), but it’s better than nothing (gas guzzler!). Okay, enough analogies, because honestly those don’t help that much. But the API as-is is certainly not a wheel-less car. It’s a perfectly drivable and nice car, it’s just not yet fully the car of tomorrow.

Iteration and WordPress have gone hand in hand for ages. Almost every feature I can think of in WordPress has iterated over time, from the initial release: the Customizer, WordPress media management, custom post types, menu management, and more. It’s important to ship features that work, but that doesn’t mean they have to be exactly what you envision. WordPress itself is far from perfect, yet it’s available for download. Every lead developer could tell you dozens of things they’d like to improve, but they’re perfectly fine shipping new releases without every one of those new features.

Vertically integrated API support

Let’s do a mental exercise on the difference between building horizontal and vertical support in the API. This isn’t how one would really build an API, but it’s how we’ll envision calculating support for it.

If you envision the WordPress dashboard, there are many paths you can take. Every top level admin tab is available to you: Add new post, visit the settings page, choose a theme, etc. The REST API cannot currently mimic every action you can take. I would define horizontal support as visiting the admin, identifying each potential action one step away from that first view, and creating that functionality with the REST API. You’d have a lot more endpoints, but the endpoints would be incomplete — and one layer deep.

The next step, if working horizontally, would be to take each new view you just visited, based on the previous action, and do it again. This would cover a lot more functionality. Change widget order, move menu items around, delete comments, etc. But there are yet further levels you can take each of these screens. However, say the initial screen had 12 possible events, and now each of those 12 has 12 possible events, you now have 144 events to mimic in the API, but you still have layers to go before you have complete support of any particular fully fledged task.

If you continue that process, you’ll be attacking support horizontally, and you’ll be at it for a long time.

Now, let’s think vertically. Let’s choose an end goal: like publish a blog post. Okay, now let’s go back to the admin. This time, we’re going to enable support for adding new posts with the API; that’s one action, and we’re going to ignore other possible actions that don’t have to do with adding a post.

On our next screen, we have new options, but not all of them are explicitly about publishing a post. However, many of these options are important to publishing a post: information like assigning an author (users), and putting the post into a category (terms). So we’re going to do what we need to do with each of these things that enables us to better support posting.

Okay, so we can now publish a post via the API, and we’ve also enabled baseline support for stuff that posts expect. The next step in the flow may be that someone would comment on that post. So we’re going vertically through the process. We’re providing complete coverage for these steps. And it gets more complicated than what I’ve said so far. Posts could have meta data, or be password protected, or they might be multiple post types.

Each of these creates new considerations we must account for to have complete vertical coverage of the process of publishing a post. We haven’t even touched managing site settings or other functionality that doesn’t apply to publishing a post. But as we realize the stuff that interacts with this most important task of publishing content, we begin to form a minimum viable product for our API, to know what we need to ship to fully and well support all things posts with the API. You may still take 144 steps, but at the end, you’ll have more coverage of fewer things, versus light coverage of all things.

This is what the REST API team has done with these four objects. Posts, terms, users, and comments are the content processing experience in WordPress. It’s a fully fledged API experience, without shortcuts. There are challenges of course, and room to improve, but from top to bottom the process of content creation and manipulation is part of the API.

As the REST API team have said in various channels during this debate, the non-supported endpoints are mostly isolated from the publishing experience. Supporting posts is co-dependent on supporting the author of the post, and the terms for the post. Supporting the settings screens for the website, or managing themes and plugins, or managing widget areas are not co-dependent on the post experience.

These other verticals are important, and it is everyone’s goals to create broad, horizontal support of WordPress functionality. But it should be done one vertical feature at a time, and we shouldn’t wait to ship something that is near ready for prime time until we’ve supported absolutely everything. For one, the API is useful to many people right now, but also, the API, unless the entire development strategy of WordPress changes, will never be caught up to support every WordPress feature.

Truly “complete coverage” would require API-first driven development

For the WordPress REST API to truly have “complete coverage” of WordPress features, then the API would have to be the first consideration when building a new feature. This wouldn’t be a bad thing! But it’s not the way WordPress development works right now.

Stripe is a great example. When you hear a developer talk about Stripe, the popular merchant processor, the first thing they’ll say is how good the API is. Well, that’s because Stripe is the Stripe API. No feature ships unless it started with API coverage.

Developers love working with Stripe, because anything that can be accomplished with Stripe is accomplished with the API. With WordPress, the REST API team is running to catch up with core development; core development is not centrally focused around the REST API.

And as long as core development operates outside the scope of API-first, then the API will always be running to catch up, and the smaller team surrounding API development will never maintain pace with core.

WordPress already learned this lesson with unit testing. For years, unit testing was nice to have, but not required for commit. Today, WordPress has unit testing coverage of less than 50%, even though all new commits require tests. Unit testing, though now a first class citizen to WordPress development, is still catching up.

I’m not saying whether or not WordPress should be developed API-first, but I am saying that Matt’s goal of complete coverage before shipping would just mean the API will never ship, because it will never have complete coverage with the current development strategy.

The importance of adoption, and design for the majority

It was recently pointed out that the REST API infrastructure is only used by 20 plugins. It makes it appear as if it’s not an important WordPress feature, and that sentiment is wrong.

Consider nearly any other software. I’ll use MailChimp as an example this time. Loads of people use Mailchimp. Mailchimp has a REST API, and I use it for Post Status. My implementation is not one of their official integrations, which they noted they have 845 of in their 2015 report. Mine is just me interacting with their API — only trackable by counting total API calls.

Well, Mailchimp has millions of users, and those millions of user accounts sent over 204 billion emails in 2015. A fraction of those users (I assume) are responsible for more than 29 billion calls to Mailchimp’s API, either through custom interactions (like me), or through one of the 845 official Mailchimp integrations. It really doesn’t matter that there are only 845 integrations with Mailchimp’s API; because the impact of those integrations and the developers otherwise interacting with the API had huge implications that make Mailchimp a more attractive service.

The second core philosophy of WordPress is to “design for the majority.” It says, “Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHP they are using.” And while this is true, it doesn’t mean that technical features don’t benefit the majority, even if they aren’t directly interacting with them.

The WordPress REST API is an invisible feature to most users, but it also will eventually impact nearly all users of WordPress. Like Mailchimp and Stripe, the WordPress REST API can and will impact the overall experience of using WordPress itself. Especially as third parties create gateways for interaction with millions of WordPress installs via the API, the API will be very much for the majority. But it will always be the kind of situation where a small number of integrations are responsible for a large number of interactions.

We should not base our decision making process for including the API in core on how many plugins are currently supporting the API. We should base our decision making on the potential impact developers can have developing applications with WordPress via the REST API, by utilizing the power in the API — power that can be utilized to improve publishing for everyone.

The time for the WordPress REST API is now

The time for the WordPress REST API is now. The API is not complete, but it is ready. This is step one. There are real issues to be resolved with the first four objects, but the first four objects should not sit on the sidelines, excluded from WordPress core, because “complete coverage” doesn’t yet exist.

There is a capable and willing team driving the WordPress REST API. We all owe our gratitude to Ryan McCue, Rachel Baker, Daniel Bachhuber, Joe Hoyle, and the other contributors that have worked tirelessly — many of them for many years — to make the WordPress REST API a reality.

We should not take these efforts for granted. A contributor’s time is finite, and everyone that’s worked hard on the API could have spent that time on other things. While time spent shouldn’t be our metric for including a feature in core, we should consider it now. This team has worked for a long time, all along asking for others to provide feedback, and at the 11th hour a vocal (and powerful) minority have decided to throw considerable roadblocks at their efforts.

The WordPress REST API is a good feature for WordPress to have. REST APIs are a staple of modern web applications. The endpoints proposed for core inclusion is a reasonable next step after the infrastructure that went in WordPress 4.4. Whether these first four objects are ready for 4.5, or get postponed until 4.6 isn’t a huge deal; they should be ready before they are merged. But they should not be sidelined until the fantasy of complete coverage is met.

The inclusion of the WordPress REST API should be iterative, smart, and focused. It shouldn’t be all or nothing. It should be now.

by Brian Krogsgard at February 09, 2016 09:03 PM under Developers

WPTavern: WP REST API Team Releases Version 2 Beta 12, Seeks Feedback from WordPress’ Lead Developers


The WP REST API team released version 2 beta 12 today. Daniel Bachhuber highlighted the breaking changes in the release that developers will want to digest before updating. This includes the removal of meta endpoints from the primary plugin into its own feature plugin, now available on WordPress.org.

In a comment on our coverage of the continuing discussion, WP REST API team member Joe Hoyle clarified the team’s position on the endpoints’ readiness for core:

For the record, the REST API Team support further iteration on the existing endpoints before being merged into core. That could mean waiting for the WordPress.com API team to use those endpoints in production, or gathering more usage feedback from others. I am strongly against merging anything before it’s been well-proven and well-tested.

The proposal by the team was to include the 4 content endpoints when they are ready. We had a lengthly overview as to the progress of those endpoints, more details on what we feel is left to be done can be seen at the issues queue for the 2.0 milestone.

Why these endpoints specifically? Because they are co-dependent for the most part. Shipping Posts without support for Taxonomies would not be that useful.

Hoyle also cautions that pursuing full coverage of wp-admin is a monumental task that could take several more years:

Going for development of _all_ functionality (somewhere around 8-10 total data routes) should not be underestimated. It’s taken somewhere around a year and a half to get the current 4 to where they are now, and that was with 2 years prior art from Version 1.

As someone who has been in the weeds of that implementation for a while now, I cannot over over-stress just how tricky trying to retrofit a consistent, coherent interface on 13 years of organically grown code and ideas can become. I’m looking forward to being part of the writing the implementation for the remaining (and majority) of functionality, however I don’t want to stop users and developers benefitting from what is already being built for another [several] years.

Hoyle emphasized that the team is not proposing merging the existing endpoints now, but he believes they are getting very close.

With the release of v2 beta 12, Bachhuber urged WordPress lead developers and committers to offer official feedback in hopes of building a consensus. Given the disagreements in the recent meeting, it’s clear that WordPress contributors have not been on the same page as far as what constitutes core readiness for the project.

Feedback from contributors is starting to trickle in. WordPress core committer Jeremy Felt shared his thoughts in a post on his blog today:

I’m in favor of the REST API team’s proposal to merge the endpoints for the primary objects in WordPress—posts, comments, users, terms—when they’re ready.

When the endpoints for these objects are ready, I would like to see them merged early in a release cycle.

With these primary endpoints in, front end workflows can immediately start to take advantage. This is something groups have been doing for years with custom code already. Getting these groups to use the same structure is valuable.

Core committer Weston Ruter summarized his opinion in a tweet:

The plugin is moving forward with regular betas while the discussion continues. Developers who are using the API in beta will need to continue to follow the project closely, as the latest beta makes changes to available features. 10up developer Eric Mann tweeted some of his challenges in using the API in beta:

My client installed the REST API before it included post meta. We had to build a bunch of custom work to support meta. Then the REST API updated to include meta and broke our integration. I spent a chunk of hours refactoring to compensate so we could update. Now, apparently, the REST API is pulling that meta support out and putting it in a separate plugin. Yet people still criticize me for saying I’m wary of placing too much dependency on the stability of the API.

Joe Hoyle is currently crowdsourcing stats on projects that are using the WP REST API v2 in production. Developers who have stepped up to use the API have had to be nimble in accommodating its rapid development. At this time, the WP REST API team agrees that further iteration on the existing endpoints will be necessary before merging them into core. Continued feedback from developers with projects that use the API will be critical for demonstrating that the API has been well tested.

by Sarah Gooding at February 09, 2016 08:33 PM under wp rest api

WPTavern: WordPress Theme Review Team Recommends Authors Start Keeping a Change Log

photo credit: Green Chameleonphoto credit: Green Chameleon

Last April, WordPress Theme Review Team member Jose Castaneda proposed that the team adopt a standard change log format. Theme authors are not yet required to keep a change log but the general consensus is that it’s a good practice that benefits users.

Castaneda revived the topic of change logs during the team’s most recent meeting, saying he hopes this will be the year that they can finally standardize the readme.txt file and take action on the change log-related trac tickets. This would require action on a meta trac ticket to add change logs to the WordPress.org theme listing tabs and a core ticket that would expose the change log to users in the WordPress admin.

Castaneda posted some basic recommendations as a first step towards educating theme authors on the proper format for writing a change log:

  • Listing versions in reverse-chronological order (newest on top)
  • One sub-section per version
  • Group changes made per version
  • Don’t dump commit logs (if using version control)
  • Emphasize deprecations

Even though a change log is not yet exposed in wp-admin, theme authors can still write one for users who are willing to do a bit of looking before updating. It’s especially important for things like changes to CSS selectors, the removal or addition of features, and anything that might cause child themes to break.

The theme review team is currently focused on fixing its review process, so pursuing the necessary tickets for a change log is not a pressing item on the agenda. When the team gets time to follow through on making change logs happen for WordPress.org themes, authors who already have one in place will be positioned to display them to their users.

by Sarah Gooding at February 09, 2016 05:06 PM under wordpress theme review team

February 08, 2016

WPTavern: WordPress Contributors Look for a Path Forward for the WP REST API

photo credit: Valeriy Poltorakphoto credit: Valeriy Poltorak

Over the weekend, discussion continued surrounding the direction of the WP REST API, as both Matt Mullenweg and Ryan McCue took to their WordPress blogs to clarify statements from last week’s status meeting. Differences of opinion are driving a heated debate about what constitutes a goalpost for the API’s readiness for core.

In a post titled “Chicken and Egg,” Mullenweg addressed the recent WP REST API discussion while sharing an anecdote from a book that covers history from the mid-90s hip-hop era.

I love the idea of Questlove realizing the song was missing something, and going back to the booth to keep working on it until it resonated with his target audience. A song that doesn’t stand up on its own wouldn’t be any better when bundled as part of an album. (Or Samsung would have the most popular apps on Android.) Fans hear the care and quality of each track, and they become super-fans.

Mullenweg relates it to considerations when building products for the web:

There’s this tension in everything we produce. Where’s the line to tread between 1.0 is the loneliest and a minimum viable product? Or is it about a minimum lovable product? Are we building a car with no air conditioning or a car with no wheels?

‘Pivot’ has become passé, but it’s much worse to assume that distribution will solve something core to your product that isn’t working.

Mullenweg mentioned the same car analogy during the meeting last week. In response to a commenter who asked for more clarification on how the analogy applies to the REST API, Mullenweg said the following:

If you want a good heuristic to use generally: there were decades of cars, millions of vehicles and drivers, before they had air conditioning. The core value proposition of a car is transportation, AC just helps you get there more comfortably. You didn’t need a car to get AC, you could have it in your house. AC might cause you to chose one car over another, but you probably wouldn’t walk or ride a horse if the car didn’t have AC, you’d just roll down the windows.

This begs the question, what constitutes wheels? Contributors to this discussion are divided on whether or not the existing endpoints are ready to be merged into core. The WP REST API team members, many of whom are already successfully using the API in production, believe that the endpoints are ready now. The current state of the API offers the ability to get content in and out of WordPress, opening it up for easier communication with other platforms, which many believe is the primary use case.

Mullenweg and others who joined the discussion last week are in favor of delivering something more complete, a REST API that supports everything available in wp-admin. This includes WordPress’ many site management features and would put the API several releases away from core readiness.

In a comment on our initial report, Drew Jaynes advocated what he believes to be a middle ground that provides a solid jumping-off point. This would involve resolving the missing pieces in the existing endpoints before merging them (items like password-protected posts, autosaves and post previews, and meta.)

“As I and others from the contributor/committer camp said in the chat, there can be a middle ground,” he said. “Whether that ends up looking like the four core endpoints alone, four core endpoints with some flavor, XML-RPC parity, or some measure of wp-admin parity, remains to be seen,” he said.

In a post titled “Progressive Enhancement with the WordPress REST API,” Ryan McCue outlined a full-on iterative approach that would push for distribution now and roll out more endpoints in future releases:

Progressive enhancement is our key solution to a couple of related problems: forward-compatibility with future features and versions of WordPress, and robust handling of data types in WordPress. Progressive enhancement also unblocks the REST API project and ensures there’s no need to wait until the REST API has parity with every feature of the WordPress admin.

McCue’s post goes into further detail of the REST API’s feature detection capabilities, which allow developers to easily detect support for features and build them in a forwards-compatible way while waiting for core support.

Is Distribution the Answer?

During last week’s meeting McCue said that continuing the project’s development as a feature plugin will do more harm than good. If the REST API is not allowed to ship without offering support for everything in wp-admin, the team would be forced to continue iterating on it as a feature plugin while simultaneously resolving difficult roadblocks in WordPress core. With just four major contributors operating at less than part time on the project, this requirement could stall the WP REST API indefinitely.

“We believe that the progressive enhancement approach is the best approach for continuing API development,” McCue said. “Progressive enhancement is a paradigm the REST API project ​must​ adopt, if it’s an API we want to add to (without breaking backwards compatibility) over the next 10 years.”

Mullenweg, who has led an iterative approach to development throughout WordPress’ history, is wary of latching onto distribution as the only way forward.

The larger WordPress’ usage becomes, the louder its footsteps are heard. Iterating on the REST API in core, with distribution to millions of sites, may affect the web in ways contributors cannot yet anticipate. As they say, heavy is the head that wears the crown. The ripples extend beyond WordPress sites to the outside platforms that will also consume the API.

Contributors are still discussing the nuances of iterative development in core vs. delivering a more complete API. Meanwhile, adoption is stilted by the uncertainty surrounding the project and the fact that it still carries a plugin dependency. It’s not yet clear whether WordPress contributors will dig in and push for inclusion of the endpoints against Mullenweg’s recommendation or whether they will opt to spend more time polishing the existing endpoints. If the WP REST API team is required to ensure that the API can support a wp-admin replacement, it may not land in core until the end of this year or later.

by Sarah Gooding at February 08, 2016 10:06 PM under wp rest api

February 05, 2016

WPTavern: WordPress.org Has Fewer Than 20 Plugins Using the WP REST API in Core

Plugin Recommendations Featured Imagephoto credit: when i was a birdcc

During yesterday’s pivotal WP REST API meeting, WordPress contributors discussed adoption of the API. A cursory search of the WordPress.org plugin directory shows that fewer than two dozen plugins are currently using the API scaffolding included in WordPress 4.4. For reference, here are the 20 plugins identified by Mika Epstein during the meeting, along with active installation numbers for each:

With a few notable exceptions, most of these plugins are hovering around a range of 10 – 100 active installs. These low numbers may indicate that plugin authors have not yet readily embraced building with the scaffolding that was merged into core in 4.4. However, some developers who have embraced building with the API have opted not to offer their plugins and themes for large scale distribution on WordPress.org.

“I think the plugin directory is the wrong place to look for adoption,” WordPress developer Nate Wright said at the most recent meeting. “As a plugin author myself, I have to bend over backwards to ensure compatibility with tens of thousands of weird plugins and themes. Javascript itself is highly unstable in the ecosystem because of all the terrible code out there. I’ve used the API in client projects and am currently integrating it with some customizer tools I’m building. My publicly available plugins will be the last thing I’ll introduce to the API.”

Taylor Lovett, author of Custom Contact Forms, believes that it’s important to get REST API-powered plugins into the hands of users, despite the support challenges of public distribution.

“It pushes plugin and theme developers to start working around API JavaScript conflicts now,” Lovett said. “There are many plugins that conflict with the API for a variety of reasons, one of the big ones being modifying Backbone.sync. Having plugins use it now is painful but will push people to start reporting those JS conflicts.”

Custom Contact Forms is currently the most widely-used plugin running the WP REST API with more than 70,000 installations, but the journey to using the current version has been fraught with challenges.

“There have been a number of backwards compatibility breaks with the JSON REST API project,” Lovett said. “If I had known going into it what would happen, I probably would have not used the API.

“I am still not completely comfortable with using the API because of the perceived instability of the project,” he said.”

Nevertheless, public distribution has brought Lovett considerable feedback from users which has been invaluable for his contributions to the REST API project.

“I’ve had a number of patches to the API that were discovered through Custom Contact Forms,” he said. “I’ve discovered some real edge cases while maintaining the API across more than 70K installations.”

Distributing his plugin on WordPress.org while the API went through significant changes was more challenging than Lovett anticipated, but through it the API has gained more exposure.

“The faster the API is exposed to people and people get comfortable using it, the sooner we will see some major strides in applications being built around WordPress,” he said.

by Sarah Gooding at February 05, 2016 11:06 PM under wp rest api

Matt: Chicken and Eggs

mometablues.jpegI’ve been reading Questlove’s Mo’ Meta Blues, and it’s an incredible education. The book is helping me appreciate an era of music that inspired the era that inspires me — the music that drove the Roots, J Dilla, Fugees, D’Angelo, Common, Erykah Badu, Kendrick Lamar, and so many more to create what they have.

Chronologically, I’m in a chapter covering mid-90s hip-hop, which is full of conflict. There’s a tension alluded to in the book of the musicians that made it and those that didn’t: does increased radio play make songs popular? There’s some science that suggests yes. Or is there something intrinsic to the record that puts it in that virtous loop of requests and airplay, the equivalent of usage and virality in a web product?

There’s a great ancedote in the book that I think is useful when thinking about products. All of the links are my addition, not in the original text.

There was one moment during the recording of Voodoo that really brought this home. We were recording DJ Premier’s scratches for “Devil’s Pie,” and Q-Tip had just let the room to go work on something else, so there were four of us left there: Premier, Dilla, D’Angelo, and myself. During the break, Premier asked if anyone had any new shit to play for the group, and D’Angelo went for a cassette and played a bit of a new song, and the whole room just erupted in hooting. Then Dilla put on some new Slum Village shit and it was the same thing: an explosion of excitement. Then Premier, who had started the whole thing, played an M.O.P. song and some new Gang Starr material that he was working on for The Ownerz.

I was last at bat. All I had on me was a work tape for what would eventually become “Double Trouble” on Things Fall Apart. It didn’t have finished vocals yet, didn’t have Mos Def’s verse. It was just a skeleton. I played it, and I will never forget the feeling that came over the room, including me. It wasn’t that they didn’t hoot and holler like they had for the other songs. They did. But they didn’t mean it. I know the move people resort to when they’re not quite into a song: they keep a straight stare on their face and bob their head a bit, not saying anything, not making eye contact. That’s the sign of death. That’s what they all did to me, and I felt humiliated. I was like Glenn Close in Fatal Attraction: I will not be ignored! I went back into the studio that same night and gave that song a radical, extended facelift. I refused to sleep until I had that thing up and running.

I love the idea of Questlove realizing the song was missing something, and going back to the booth to keep working on it until it resonated with his target audience. A song that doesn’t stand up on its own wouldn’t be any better when bundled as part of an album. (Or Samsung would have the most popular apps on Android.) Fans hear the care and quality of each track, and they become super-fans. The bands that break out weren’t bludgeoned into fan’s ears by radio play, they were pulled by these passionate few into a wider audience.

I love the mixtape culture that so many of today’s successful artists have come up through, and it is amplified online. Drake had three ever-improving mixtapes before his first album. It harkens to a line from PG’s startup canon (in 2009!): Better to make a few users love you than a lot ambivalent.

There’s this tension in everything we produce. Where’s the line to tread between 1.0 is the loneliest and a minimum viable product? Or is it about a minimum lovable product? Are we building a car with no air conditioning or a car with no wheels?


“Pivot” has become passé, but it’s much worse to assume that distribution will solve something core to your product that isn’t working.

by Matt at February 05, 2016 10:42 PM under Essays

Post Status: WordPress REST API Round-table — Draft podcast

Welcome to the Post Status Draft podcast, which you can find on iTunesStitcher, and via RSS for your favorite podcatcher. Post Status Draft is hosted by Joe Hoyle — the CTO of Human Made — and Brian Krogsgard.

Joe and Brian were joined by Ryan McCue, the Lead Developer of the REST API, Daniel Bachhuber, a contributing developer to the REST API, and K.Adam White, Aaron Jorbin, and Jack Lenox — each with unique experiences using the REST API. They discussed the talks from A Day of REST, but also about the impact of the new API more broadly as well.

If you’re at all interested in the REST API, this is an excellent round table to listen to.


Direct download


Photo credit: Aaron Jorbin

by Katie Richards at February 05, 2016 06:34 PM under Everyone

WPTavern: WP REST API Delayed, Contributors Facing Gridlock


The WP REST API team met yesterday in the #core-restapi Slack channel to discuss the status of the existing post, term, user, and comment endpoints. There are a few outstanding issues with these four core objects, which the team wants to tackle via a feature plugin approach instead of holding the API back from merge. These outstanding items include things like password-protected posts, autosaves and post previews, and meta handling.

“For now, we’re not going to support them, and will be working on them in a separate feature plugin instead,” WP REST API project lead Ryan McCue said. “Again, this will be an enhancement to the API in the future, and doesn’t block compatibility here.”

In September 2015, McCue and contributors outlined a merge plan for the REST API which brought the infrastructure into the 4.4 release with the endpoints on deck to follow one release later in 4.5. Contributors to the REST API believe that the project is still on track for this goal.

“Our proposal is that we ​merge the four core objects​ in the REST API with full read, create, update, delete support, with the more peripheral features to come ​when they’re ready,” McCue said.

Several WordPress contributors, including project lead Matt Mullenweg, voiced concerns about the REST API shipping without the features that have been temporarily spun out.

“I know it’s a minority opinion, but I would be pretty skeptical of merging a partial API into core,” Mullenweg said. “I think it would do a lot more damage than benefit.”

McCue contended that the team has been working towards shipping a product that can be progressively enhanced.

“The API is specifically structured around progressive enhancement, which is a key difference from many APIs,” he said. “Allowing clients to detect features and support them when they’re ready allows us huge flexibility.”

Does the WP REST API Need Full wp-admin Coverage?

Aaron Jorbin noted that while the four core object types allow for some innovative themes and content editors, they do not yet allow for full wp-admin replacements. This particular point was a deal breaker for several contributors attending the meeting.

“The cases where the current API covers today aren’t terribly interesting because they’re not really enabling something that was impossible to do before,” Mullenweg said. “It’s just a different approach to doing something that was already possible before. I don’t even think we have XML-RPC parity of feature support yet.

“I wouldn’t have included REST examples in the SoTW, or encouraged plugins to use the scaffolding, or even let the scaffolding in the last release, if I didn’t think it was the most promising thing out there right now,” he said. “But uptake definitely feels slower than I would have expected. It’s taken so long to get to this point, if we don’t pick up the pace, it could be another year or two before we get full wp-admin coverage.”

Despite the fact that the WP REST API recently had its own conference dedicated to it, most of the people who are building with it are those who are also contributors on the project. Adoption is not yet widespread, but this could be due to the fact that many developers don’t want to build on it until the core endpoints are officially merged.

“We’ve got a bit of a chicken and egg: without core adoption, potential API consumers are hesitant to take the plunge, but without adoption it won’t be tested sufficiently to be merged,” REST API contributor K. Adam White said.

“From a project point of view I’m not really excited about shipping an API that has ‘some assembly required,’ vs making the core release paired with interesting non-trivial killer apps (mobile apps, something calypso-like, big plugins using / supporting it),” Mullenweg said. “To me a complete API is one that covers everything that’s possible within wp-admin. A subset of that is a partial API.”

Multiple contributors on the REST API project, however, agreed that shipping with full admin replacement capability is unrealistic, especially after Mullenweg confirmed that it should support everything possible in the admin, including the file editor.

“We’re significantly more interested in getting read/write access to core types, so that we can interact with WP from a host of other platforms,” K. Adam White said. “I think that pushing everything off until it’s ‘Calpyso ready’ blocks myriad use cases before they can get off the ground.”

In response, Mullenweg asked why WordPress should support something in its web interface that isn’t supported through its official API. At the conclusion of the two-hour meeting he summarized his final proposal: “No partial endpoints in core. Let’s design a complete API, not half-do it and foist it on millions of sites,” he said.

This is a critical juncture for the WP REST API project. While most contributors seemed agreed on further iterating the existing endpoints and ramping up usage before merging them into core, attendees remained divided about the need to have full wp-admin coverage prior to merge.

WP REST API team members are squarely committed to iterating separately on peripheral features, but another contingent of WordPress contributors who joined the meeting yesterday are adamant about seeing a more polished API with better support for the admin. A plan forward has not yet emerged.

by Sarah Gooding at February 05, 2016 06:59 AM under wp rest api

WPTavern: Pantheon Launches Community Resource for Scaling WordPress


When people ask the question, “Can WordPress scale?” they are often pointed to some of the largest websites running on WordPress, such as Time Magazine, TechCrunch, NBC Sports, Playstation, the New York Observer, and others. But how do you get there and what does it take to deliver WordPress at scale to millions of visitors?

Yesterday Pantheon launched a new resource to answer this question with a knowledge base of best practices from experienced developers. WordPress at Scale is a community-driven project that aims to educate site owners and developers about scalable website infrastructure and optimizations that many large scale sites employ.

The site’s content is managed via a GitHub repository where anyone can contribute. Topics currently range from elastic architecture to object caching to recommended development workflows for scaling.


Pantheon Aims to Make Scalability and Performance Commonly Understood Best Practices

“We work with a lot of web agencies and dev shops, and we’ve also spent a lot of time working within the community at WordCamps over the past 18 months,” Pantheon co-founder Josh Koenig said. “It definitely seems like there’s a need for go-to resources when it comes to questions about scale. We wanted to set a serious goal for ourselves to make an impact in the WordPress ecosystem.”

While you can find scattered tutorials around the web about how to scale WordPress, this collaborative community effort is one of the first to aggregate resources into a collection. Knowledge of scalability doesn’t come easily and isn’t always shared with the community.

“Very often learnings about scalability don’t make it out of projects or companies because they can be hard to generalize (or because people think there’s proprietary value in them),” Koenig said. “Our opinion — and this is based on our experience in the Drupal project with our pre-Pantheon work on PressFlow and ​Mercury — is that there’s ​vastly more value to be had for everyone in making scalability and performance commonly understood best practices.”

In order to accomplish this goal, Pantheon set up the WordPress at Scale microsite as a community project.

“We wanted this to be a real contribution,” Koenig said. “Since we’re a platform provider, doing it ‘in house’ would mean it’s ultimately just a marketing piece.

“I’m clearly being up front about the fact that we hope this site has marketing ​value​ to us, but that value should (rightly so) be proportional to how actually useful it is to the community,” he said. “We’d never get very far if this was just a Pantheon thing.”

Weston Ruter, CTO at XWP and contributor to the WordPress at Scale site, agrees on the value of having the site set up as a community project.

“A community-driven resource like this is important because there is a lot to know, and there is a lot of experience to draw on from the community,” Ruter said. “No one agency or consultant has all of the possible tips and tricks for scaling WP, so having a collaborative resource to draw that information together is very helpful to keep it from being isolated in our respective silos.”

Although scaling varies widely based on the type of content being served and user activity on the site, many aspects of optimization are fairly straightforward and can be easily applied as needed.

“I suppose scaling WordPress is more a formula than an art,” Ruter said when asked which it resembles more. “If there is art to it, it is having an eye for designing the architecture to take into account the specifics of the site being scaled. Different sites have different techniques required for scaling. A brochure site with seldom-changing content will be cached very differently than a social network site.”

WordPress at Scale is just a starting point for what Koenig hopes will become a comprehensive resource authored by many contributors. It’s currently missing several topics that he wants to cover in more detail.

“There are a couple good issues in the queue already with specific technical topics I’d love to cover: fragment caching, and ESI,” he said. “We will definitely be getting into those and other topics with more specificity, especially as we can leverage more contributions from the community.

“Once we get the content a little more built-out, I want to create a generic presentation that anyone can use to cover this topic,” Koenig said. “Whether that’s giving a talk at a meetup, or pitching WordPress as a solution to a client, having some good quality materials will really help get the message out there.”

by Sarah Gooding at February 05, 2016 12:58 AM under scalability

February 04, 2016

Dougal Campbell: Underscores Components – Custom starter themes for faster WordPress theme development

“Components is a library of shareable, reusable patterns for WordPress themes. Instead of starting from scratch, mix and match from a collection of pre-made components to build your own custom starter theme.” Online tool from Automattic which can generate a variety of starter themes based on Underscores and Components, ready for you to customize.

Underscores Components – Custom starter themes for faster WordPress theme development

by Dougal Campbell at February 04, 2016 07:25 PM under WordPress

WPTavern: Shiny Updates Version 2 Adds Functionality for Themes and Bulk Plugin Updates


With all of the design improvements to the plugin and theme screens in recent WordPress releases, the experience of updating extensions started to feel clunky and disjointed. The Shiny Updates feature plugin was created to hide what project contributors refer to as the “The Bleak Screen of Sadness.”

WordPress users received a small taste of shiny updates when the feature was applied to plugin updates in the 4.2 release, but themes still lag behind. For example, when you update a theme, WordPress lets you know exactly how hard it is working behind the scenes to make that happen:

Downloading update from https://downloads.wordpress.org/theme/cover.1.6.4.zip…

Unpacking the update…

Installing the latest version…

Removing the old version of the theme…

Theme updated successfully.

Shiny Updates hides the ugly parts of updates in favor of making the process appear more effortless. Instead of taking the user to a new screen, updates happen in the background without the need to refresh the page.

The project is currently a feature plugin in development for WordPress core, led by Konstantin Obenland. In a recent status update Obenland said that the new version of the plugin aims to extend shiny updates to all aspects of updates, installs, and deletes for plugins and themes in WordPress.

Version 2 of the plugin currently offers the following:

  • Deleting single plugins, bulk updating, and bulk deleting plugins from the plugin page.
  • Shiny plugin installs from the plugin install screen: multiple actions can be queued up.
  • Shiny theme installs, updates, and deletes, multiple queue-able, including multisite.

Development for the Shiny Updates project is happening on GitHub where the team is collaborating on design and UX improvements. One of their goals, according to the most recent update, is to refine the user experience by “improving perceived performance and limiting confusing notifications.”

Update All the Things

WordPress’ update process is somewhat fragmented when there are multiple updates available for core, plugins, and themes on the update-core.php screen. Shiny Updates contributors are exploring a button that would “update all the things” in one pass. The dedicated issue on GitHub has 28 comments of discussion and design mockups for what an “Update All” process might look like.

In addition to adding an Update All functionality, contributors are also working on the following issues:

When asked whether Shiny Updates will be ready for inclusion in the upcoming 4.5 release, Obenland said, “Even though we’re fairly far into what we want to accomplish with v2, there are still a good number of tasks outstanding.

“I’m going to reach out to the a11y group for a review soon and have already gotten in touch with a few core committers to have the JS part reviewed,” he said. “We’re also in the process of running more user tests for the new flows. So the decision deadline next week just comes a little too early.”

At this time, WordPress 4.6 is a more likely target for including Shiny Updates in core. If you want to assist the team in getting it ready, install the feature plugin from the official directory or via the Beta Tester plugin. Testing version 2 should include both plugin and theme installation, update, and delete actions on both single and multisite installs. Testers can report any bugs to the project’s GitHub issues queue.

by Sarah Gooding at February 04, 2016 12:56 AM under shiny updates

February 03, 2016

Post Status: The first WordPress REST API conference, in review

January 28th and 29th of 2016 marked the first ever A Day of REST, a conference devoted to the WordPress REST API. It’s also, to my knowledge, the first ever conference completely about a single feature of WordPress.

Put on by the Human Made team, there were definitely risks: maybe not enough people would sign up, maybe the content would be too dense, or not dense enough for the audience that showed, maybe the API wouldn’t be in core yet, and more. Yet, none of these things happened, and the conference was a success.

I had the privilege to cover the event as the media partner, and I had an excellent time. It wasn’t a small conference, with over 220 attendees, but it was intimate, utilizing a single track setup, and had a small hack day reserved for 40 people.


It was also a bit of a risk to host the first A Day of REST in London, where it was quite accessible to the European community, but out of reach for much of the American market. Nonetheless, those of us that came from the US, Asia, and elsewhere were able to make mini-vacations of the conference, and the UK and broader European community made a great showing; the event nearly sold out.

Why does the WordPress REST API merit its own conference?

The WordPress REST API drastically changes the landscape for WordPress development. Now, WordPress can be the data store, while other technologies can (but aren’t required to, of course) take up pretty much every other aspect of the website. The front end and the back end components of a website can utilize completely custom web stacks, while the data is stored in WordPress.

The API can be used for modules within existing sites built traditionally with WordPress, or as the engine for entire external web apps. There are so many potential avenues to take WordPress with the REST API, that exploring just a few of them merits a conference like this. In fact, after having seen the conference, I feel that we just scratched the surface. That said, it was an excellent day, where I learned a lot. Here’s an overview of each speaker, and be on the lookout for videos as well, which will be hosted here on Post Status.

Introduction to the WordPress REST API

At A Day of REST, we were guided from the beginning, with an introduction to APIs within WordPress, and the role the REST API will play, by WordPress REST API Lead Developer Ryan McCue.

Ryan McCue

Ryan McCue

The Building Blocks of a REST API project

Next, Joe Hoyle — a core member of the REST API team, Human Made CTO, and my co-host on the Draft podcast — walked us through the building blocks of a REST API project.


Joe Hoyle

Unlock the Potential of the WP REST API at the Command Line

Next, Daniel Bachhuber talked about creating a more RESTful wp-cli. The wp-cli project is a powerful suite of tools, but much of the functionality is replicated with the REST API. He’s in the middle of working through utilizing the REST API for wp-cli functionality.

Daniel Bachhuber

Daniel Bachhuber

There and Back Again: A Developer’s Tale

Jack Lenox spoke about using the WordPress REST API in the context of single page application development, and WordPress theming.

Jack Lenox

Jack Lenox

Building Calypso-like Applications with the WP REST API

Nikolay Bachiyski was instrumental to the WordPress.com Calypso project, and in his talk at A Day of REST, he discussed Automattic’s thinking behind many of the technologies that were used, and some of what they learned.


Nikolay Bachiyski

Pay No Attention to that WordPress Behind Your Application

With perhaps the most fascinating topic of the day, K. Adam White discussed using WordPress in some quite strange ways, like in concert with Ghost, for instance. All of the talks are great to watch, but if you only watch one, I think this would be the one I’d choose.

K. Adam White

K. Adam White

K. Adam’s Slides

K. Adam on Twitter

K. Adam’s website

A JavaScript client for the WP REST API

Should I Use the WordPress REST API? Ask WIRED’s, “Ask a Flowchart”

Kathleen Vignos is using the WordPress REST API at WIRED, where she’s the Director of Engineering. In this talk, she walks through how they decide when and where to use the REST API. They’ve gone through this process for considering the API for Latest Posts widgets, related post fallbacks, for Apple News and Slack integrations, and more.


Kathleen Vignos

Kathleen’s Slides

Kathleen on Twitter

Kathleen’s website

The Live Coverage Platform at The New York Times

Scott Taylor — WordPress core committer and engineer at The New York Times — showed us how they use the WordPress REST API to power their Live Coverage Platform at The Times. It’s truly both WordPress and the API at scale, and he’s careful in his talk to discuss some of the issues that need to be resolved for WordPress to be the best choice for such applications.


Scott Taylor

Scott’s slides

Scott on Twitter

Scott’s website

Hack Day

Hack day

Hack day

The Hack Day was small, but productive. Around 40 people got together at the Mozilla offices and knocked out tickets, resolved longstanding issues, wrote docs, and updated the REST API website to officially deprecate version 1.x documentation.

More pictures from A Day of REST

Here are some more pictures I took of speakers, the audience, and the venue at A Day of REST. I really enjoyed this venue, which was exactly what I’d imagine an old and quaint English venue would look like.

ador-poststatus-11 ador-poststatus-2 ador-poststatus-1 ador-poststatus-3 Jenny Wong ador-poststatus-5 Ryan McCue Tom Willmot ador-poststatus-8 ador-poststatus-14 Joe Hoyle ador-poststatus-10 ador-poststatus-13 ador-poststatus-15 ador-poststatus-17 Daniel Bachhuber ador-poststatus-19 ador-poststatus-20 Jack Lenox ador-poststatus-22 ador-poststatus-12 Jack Lenox Aaron Jorbin, MC ador-poststatus-25 Nikolay Bachiyski ador-poststatus-27 ador-poststatus-28 K. Adam trolling K. Adam White Sponsors & Schedule ador-poststatus-16 Afternoon snacks Coffee Room for REST ador-poststatus-35 Kathleen Vignos Mike Little Scott Taylor ador-poststatus-39 ador-poststatus-40 Even more hack day More hack day Hack day Petya ador-poststatus-45 Mozilla space

The future of A Day of REST

Planning is already starting around what future WordPress REST API events may look like. Human Made is talking to potential partners (and in disclosure, I’m in these discussions as well) about potential events in the United States and Asia so far.

Feedback from A Day of REST was quite positive: more than 80% of attendees would definitely attend again, and nobody said they would definitely not attend again. For many, the depth of the talks and willingness for the conference to go deep on one WordPress feature was welcome, especially because this was an advanced audience of mostly developers, and not all just WordPress developers.

More than 20% of attendees consider themselves primarily JavaScript developers. I imagine the other 80% are all seeking to learn more about JavaScript, especially in context of its uses with the WordPress REST API, and considering Matt Mullenweg’s challenge during the most recent State of the Word.

I imagine we will also be seeing stronger focus on the REST API at larger WordCamps. I could imagine simultaneous developer tracks and REST API tracks. And third party events like A Day of REST can go even deeper, with workshops and smaller group teaching, versus only speaker-driven events.

I love seeing people get together and learn. A Day of REST was productive, educational, and fun. I look forward to potential future iterations of this event, and getting back to Europe for a proper vacation (this was my first trip there!). Keep an eye out on Post Status for the official videos, and a round table podcast where I talked to many of the speakers about the WordPress REST API.

by Brian Krogsgard at February 03, 2016 10:45 PM under Developers

WPTavern: A Day of REST Conference Successful, 81% Would Attend Again

photo credit: Noel Tockphoto credit: Noel Tock

Last weekend more than 200 developers gathered in London for a niche conference devoted to the WordPress REST API. A Day of REST featured speakers from around the world who are building applications with the REST API at companies like WIRED, The New York Times, Fusion, Automattic, and Bocoup.

“The conference was a fantastic proof of just how popular the REST API project is, and it was super encouraging to see everyone there to hear about it,” Ryan McCue told the Tavern. McCue, a co-lead on the WP REST API project, said he enjoyed the opportunity to connect with the many developers who are already using the API in production. He also said he was surprised by some of the the speakers’ unconventional uses of the API, including using it to supply content from WordPress to Ghost themes.

“The contributor day was wildly successful as we took a feature plugin approach to some long-standing issues,” McCue said. “We essentially split the room into six and let every team handle their tasks with fresh eyes. A huge amount of progress was made, and I’m hoping that this greater ownership of the contributions will encourage contributors to remain involved well into the future.”

McCue said three quarters of the WP REST API leadership team had the opportunity to meet in person and work through nearly all of their outstanding discussion items to get unblocked for future work.

In addition to being a boon to the REST API project, the conference was inspirational for developers who appreciated the in-depth technical focus of the event.

“I think the most exciting point for me was the realization that the potential of decoupling WordPress from its codebase is far more complete and powerful than I had previously thought,” said Adam Hollister, an engineer who attended with colleagues from Pragmatic, a UK-based development agency. “I’m looking forward to building something with WordPress data in a way that would not have been possible until now.”

Human Made Embraces Challenge of Hosting Conferences Curated for Developers


As many WordCamps are becoming more user-focused, developers are looking for events where they can expand their skills and learn from others in the industry. According to Day of REST stats from co-organizer Petya Raykovska, 41% of the 221 attendees were WordPress developers, 26% PHP developers, 21% JavaScript developers, and 12% other attendees (designers, product managers, and business owners).

“It’s more challenging to organize a niche conference than it is to organize a WordCamp,” Raykovska said. “From the start we wanted to throw a very high quality event, especially curated for developers who want to improve the level of their work. That meant a very precise speaker selection for that particular audience.”

The organization team at Human Made wanted the conference to teach and inspire at the same time. Raykovska said that balancing the schedule to achieve this goal was one of their biggest challenges.

“At the end we are incredibly proud of the lineup of speakers we had and the feedback we’ve been getting from attendees showed that people loved our speakers,” she said. According to a post-event survey, 81% of the attendees said they would definitely come back to the next event.

“We also learned something very important – WordPress developers are eager to learn and are willing to invest to get better, especially with the upcoming challenges presented by the REST API,” Raykovska said.

“They want to learn about specific JS libraries and frameworks, application development, creating APIs, server setups for decoupled WordPress and many more advanced development topics,” she said. “There is definitely a niche for high quality development conferences to help WordPress developers expand their knowledge base and skills.”

Human Made is in the early stages of planning a second Day of REST conference that will likely be hosted outside of Europe.

“We would love to continue organizing advanced development events to help the industry grow,” Raykovska said. “We’d like to organize A Day of REST in the US and in Asia. Even though it’s too early for specific dates, the processes are already in motion.”

For those unable to attend this past weekend, all the slides from the presentations are now available and videos are coming soon.

by Sarah Gooding at February 03, 2016 08:57 PM under wp rest api

February 02, 2016

Matt: Unsplash Photos


Unsplash is a collection of Creative Commons Zero licensed photos that area really amazing, and I curated a collection of ten images for them which you can check out here. The hard part was trying to pick only ten — there were so many beautiful and stunning images.

by Matt at February 02, 2016 07:17 PM under Asides

February 01, 2016

Matt: Getting a Job After Coding Bootcamp

The past 6-8 months I’ve been seeing a new type of person applying for Automattic’s engineering positions that I hadn’t seen before, and I think it’s very interesting and promising but missing one key component.

These applications usually have great cover letters and well-put-together resumes, which is a good sign that people put some thought into it and had someone spot-check it before sending it in. But where most people list prior jobs, these applications (and LinkedIn profiles) list projects. When you dig into prior jobs listed, if there are any, they’re typically in a completely unrelated field like medicine or finance, and under education they list one of these new bootcamps, like Hack Reactor or App Acedemy.

Here I’m going to offer a key 🔑piece of advice to these folks to help their applications stand out, and can 100% compensate for their lack of professional experience: contribute to open source. “Projects” done in a coding bootcamp, even when they’re spelled out in great bullet-point technical detail, don’t really tell me anything about your engineering ability. Open source contributions show me a passion for a given area, ability to work with others to have a contribution reviewed and accepted, and most importantly show actual code. Even better than one-off contributions, if you can grow into a recognized position in an open source project, that puts you ten steps ahead of applications even from folks with 20 years experience in the field, at least to an Open Source-biased company like Automattic.

Though I don’t know any of these boot camps well enough to suggest them, I love the idea in general. Even before the more formal bootcamps I’ve seen hundreds of examples of people who used free information and technology to rise to a very high level of technical contribution. In fact that’s very much my own story from the early days of WordPress. So in summary: it’s okay to learn to code through class projects, but show your value by getting involved in something bigger.

by Matt at February 01, 2016 04:00 PM under Asides

January 29, 2016

WPTavern: In Case You Missed It – Issue 2

In Case You Missed It Featured Imagephoto credit: Night Moves(license)

There’s a lot of great WordPress content published in the community but not all of it is featured on the Tavern. This post is part of a new series where I share an assortment of items related to WordPress that caught my eye but didn’t make it into a full post.

Taking Care of Each Other

Rich Robinkoff has a great post that discusses wellness in the community and encourages the WordPress community to take care of each other. While it’s great to give back to WordPress, Robinkoff reminds us that we need to invest in ourselves before reinvesting in WordPress.

Without giving back to ourselves, giving to the WordPress project would suffer. Invest in the wellness of WordPress by investing in yourself.

Robinkoff is also working on a side project called WPAmbassador.com, a site that aims to bring people together. It will promote camaraderie and wellness throughout the community. It’s not ready yet but it may launch in February.

If you didn’t get a chance to attend or watch his presentation at WordCamp US, I highly encourage you to do so. However, tissues are not included.

Rich is a great person and steward in the community. If you’re not already doing so, you should follow him on Twitter.

One of The Most Important Comments in WordPress’ History Turns 13 Years Old

On January 25th, 2003, Mike Little, Co-founder of the WordPress project, commented on a blog post where Matt Mullenweg described his blogging software dilemma. It’s his comment along with a few others that inspired the birth of WordPress by forking b2.

Mike Little's CommentMike Little’s Comment

Check out Milestones: The Story of WordPress to learn more about the significance of his comment.

Prologue Turns 8 Years Old

In January of 2008, Automattic released Prologue, a simple, innovative theme for providing status updates. The company used password-protected Prologue sites to allow employees to keep track of projects and updates.

Prologue in ActionPrologue in Action

In March of 2009, Automattic released P2, the successor to Prologue. In 2014, the company transitioned internal sites to o2, successor to P2 and open sourced its code in 2015.

Don’t Read The Comments

Anil Dash published a great post on Medium that looks at the phrase, “Don’t read the comments.”

We’ve made a habit out of telling people not to read the comments online. But what started as a cynical in-joke has become a bad habit, and an excuse for enabling abuse across the web.

It’s a phrase I’ve seen many people say on Twitter referencing comments to articles published on the Tavern. Dash goes on to say, “Preventing abuse online requires the people running a site or an app to invest time, effort and attention into protecting their community. That’s the bottom line.”

This is one of the reasons why we created a comment moderation policy and are taking a more active role this year moderating comments. However, in recent weeks, I’ve noticed some of the same people who said the phrase above are now engaging in the conversation which is helping to calm the waters.

For those thinking about disabling comments or need a reminder as to why their important, considering the following statement:

There’s a grave cost to assuming online interactivity is always awful. The burden is felt most acutely in denying opportunity to those for whom connecting to a community online may be the only way to get a foot in the door. Those underrepresented, unheard voices are the most valuable ones we lose when we throw the baby out with the bathwater and assume online comments are necessarily bad.

This Week in Core

If you want to keep a close eye on WordPress core development, there’s no better way than reading This Week in Core. Written and published by volunteers, the post highlights all of the noteworthy changes in an easy to digest format. Check out the most recent post that covers what happened in core between January 19-26.

Week in Core, Jan. 19-26 2016

Envato Hires WordPress Evangelist

Envato hired James Giroux to be its WordPress evangelist. In the post, he explains some of the responsibilities his role entails.

There are many compelling stories to tell. Envato WordPress creatives from all over the world have done some truly innovative things to enhance the experience of everyday users. I want to find and help tell those stories in the WordPress community.

If you’d like to meet Giroux in person, he’s attending PressNomics in March.

How the REST API Changes WordPress Plugin Development

Josh Pollock explains how the REST API changes WordPress plugin development.

WordPress didn’t get to 25% market share on blogs and it’s not going to get to 50% or whatever that way. The growth comes from eCommerce, publishing, membership sites, inbound marketers etc. These are all users that can benefit from being service providers.

I think that those of us who empower these users by giving them the tools needed to make their sites have to think API first. Your plugin’s interaction with the client is going to be more and more coming through the API.

How The WordPress REST API Changes WordPress Plugin Development

Is WordPress Made of Spaghetti Code?

If you’ve been around the WordPress ecosystem for any length of time, you’ve likely run into a conversation or two where someone says WordPress’ code is a mess. On the Kinsta blog, Daniel Pataki takes a hard look at what bad code is, whether or not users care, and if it’s a legitimate reason to avoid using WordPress.


In what is a traditional part of this series, I end each issue featuring a Wapuu design. For those who don’t know, Wapuu is the unofficial mascot of the WordPress project.

Wapuutah, created by Velda Christensen, represents WordCamp Salt Lake City, Utah, 2015. As you can see, Wapuutah is decked out in camping gear and ready for an extended getaway in the mountains outside of Salt Lake City. I hope Wapuutah remembered to bring some bug spray!


That’s it for issue two. If you recently discovered a cool resource or post related to WordPress, please share it with us in the comments.

by Jeff Chandler at January 29, 2016 07:58 PM under wpambassador

WPTavern: WPWeekly Episode 223 – Celebrating 8 Years of iThemes With Cory Miller

In this episode of WordPress Weekly, Marcus Couch and I are joined by Cory Miller, Founder of iThemes. Miller tells us what it’s been like to run the company for eight years. We discuss what’s changed in the WordPress ecosystem since the company’s founding in 2008.

Near the end of the interview, Miller tells us what’s next in the pipeline with Backup Buddy 7.0 and Stash Live. If you enjoy listening to WordPress history, this episode is for you.

Stories Discussed:

Early Bird Tickets for WooConf 2016 Now on Sale
First Global WordPress Contributor Drive Set For January 30-31, 2016

Plugins Picked By Marcus:

Hide Your Theme Name prevents people from detecting which theme your site is using.

Invitations for Slack allows visitors to your site or registered users to invite themselves to your Slack team.

Ninja Forms Signature Contract Add-On produces a legally enforceable and court recognized contract from a Ninja Form submission.

WPWeekly Meta:

Next Episode: Wednesday, March 3rd 9:30 P.M. Eastern

Subscribe To WPWeekly Via Itunes: Click here to subscribe

Subscribe To WPWeekly Via RSS: Click here to subscribe

Subscribe To WPWeekly Via Stitcher Radio: Click here to subscribe

Listen To Episode #223:

by Jeff Chandler at January 29, 2016 12:57 AM under wooconf

January 28, 2016

WPTavern: Thank a WordPress Plugin and Theme Author Day 2016

Today is normally Thank a Plugin Author Day which motivates users to thank plugin authors but based on discussions from last year’s event, I’ve decided to add theme authors to the mix. The purpose of the day is simple, give thanks and express gratitude to WordPress plugin and theme developers.

There are several ways to celebrate the event, such as visiting the plugin or theme author’s website. The link is usually available via the plugin or theme’s page on WordPress.org. If you’ve discovered a useful plugin, consider giving the author a monetary donation.

Another way to thank plugin and theme authors is to rate and review their work. Ratings and reviews are an easy way to send feedback directly to an author. Make sure to provide actionable feedback instead of one or two-word reviews. A side effect of rating and reviewing plugins and themes, is that it’s one of many ways to contribute back to WordPress.

Billion Thanks Featured Imagephoto credit: opensourcewaycc

The WordPress theme directory has more than 2k themes while the plugin directory has nearly 47k plugins. That’s a lot of volunteer time, effort, and code donated to the community.

Thank you to anyone who has ever published a WordPress plugin or theme whether it’s on one of the official directories or on GitHub. Without them, users wouldn’t be able to customize WordPress to make it their own.

by Jeff Chandler at January 28, 2016 06:54 PM under holiday

January 27, 2016

WPTavern: Mark Root-Wiley Publishes Free Guide for Nonprofits That Use WordPress

One of WordPress’ greatest strengths is that it’s free to download and use. This makes it an excellent choice for nonprofit organizations that have a small budget. Nonprofits that can’t afford a developer to maintain their sites may opt to run it on their own.

Managing a WordPress site requires a basic understanding of how plugins, themes, and WordPress works. Thankfully, there’s a new guide available called NonprofitWP, by Mark Root-Wiley, that tailors specifically to nonprofits that choose to manage their own sites with WordPress.

Front Page to Nonprofit WordPress GuideFront Page to Nonprofit WordPress Guide

The guide covers the following topics:

  • Things to know before you get started
  • Domains and Hosting
  • Installing WordPress
  • Choosing a Theme
  • Selecting Plugins
  • Entering and Managing Content
  • Keeping Your Site Healthy

There’s also a resources section with links to products and services that have special offers for nonprofits. Some of the products and services have an affiliate code that kicks back a certain percentage of sales to Root-Wiley.

Root-Wiley published the guide in an effort to help nonprofits make the right decisions, “A good WordPress website is easy to manage and maintain, but a bad one is time-consuming and expensive to maintain. Making smart decisions when you get started with a new WordPress site is key to avoiding headaches later,” he said.

“I’ve had a lot of clients where our first project was cleaning up after a volunteer or staff member who tried to do the site on their own. Sometimes that’s a live site and other times it’s a refresh that’s hit a wall. One time, I was the ​seventh​ developer on a project, but I was the first paid one and the one to launch the site.

“So many of the problems these projects run into are in the very early stages where they went all in with a bad theme, picked the wrong plugin, or quite commonly, didn’t think through or understand their organization’s needs and how those should translate to a website,” Root-Wiley told the Tavern.

Instead of publishing the information in an e-book, he used WordPress, “I chose to publish it as a website because I think that’s the most user-friendly format and I don’t want anything to get in the way with people accessing the information,” Root-Wiley said.

While he doesn’t plan to open source the site anytime soon, people can submit content suggestions and ideas through the site’s contact form.

by Jeff Chandler at January 27, 2016 10:23 PM under resources

WPTavern: First WordPress Meetup in Karachi Draws 125 Attendees


The WordPress community in Karachi, Pakistan held its first meetup last weekend led by Waseem Abbas. The gathering drew 125 attendees and organizers have been receiving positive reviews and feedback.

The meetup featured two sessions, one on “WordPress Security” by Ahsan Parwez and the second on “WordPress Possibilities” by Usman Khalid. I spoke with Abbas who said that organizers were surprised by the depth of WordPress knowledge among the attendees.

“We were expecting a beginner level audience,” Abbas said. “But when they started asking questions of the speakers, we were amazed. It is clear now that we should have more advanced discussions in future meetups. For the smaller beginner audience, we will be focusing on short live sessions.”

Karachi, with a population of 25 million people, is one of the largest cities in the world. Pakistan’s WordPress community is growing rapidly, as evidenced by the local meetup in Lahore that recently passed 500 attendees. Karachi is five times the size of Lahore and has the potential to be home to a much larger WordPress community.

“Pakistan is ranked 3rd on freelancer.com and most of the projects are based on WordPress,” Abbas said. “It shows how people are using WordPress to change their lives in Pakistan. Many of the big WordPress companies have employees working from Pakistan.”

Feedback from both Lahore and Karachi organizers indicates that the WordPress community in Pakistan is extensive, but 2015 and 2016 are the first years that leaders have emerged to get everyone connected.

“People are working on different WordPress projects and websites professionally but are not connected with each other,” Abbas said. “WordPress is used by hundreds of bloggers and developers, but they don’t have a platform to connect.

“After this meetup we have seen many business collaborations and idea sharing in the community,” he said. “It is a positive gesture and real motivation for us to scale the meetups in future.” The next Karachi meetup is scheduled for February 27th.

by Sarah Gooding at January 27, 2016 12:19 AM under pakistan

January 26, 2016

WPTavern: Your Chance to Give Feedback on WordPress’ Accessibility Coding Standards

The WordPress Accessibility team is seeking feedback on a draft that outlines accessibility coding standards for WordPress core. According to the draft, new features should meet the accessibility guidelines before merging into core.

All code released in WordPress must conform with the WCAG 2.0 guidelines at level AA. These basic guidelines are intended for easy reference during development, but do not cover all possible accessibility issues.

While the document focuses on core, it’s also a great reference for developers who want their themes and plugins more accessible.

Matt Mullenweg Addresses WordPress’ Accessibility

For the second year in a row, Morten Rand-Hendriksen, an advocate for improving WordPress’ accessibility, brought up the topic during the Q&A portion of the 2015 State of the Word.

Hendriksen notes that in 2014, the WordPress theme directory contained 14 themes with the accessibility-ready tag. In 2015, that number increased to 79.

Hendriksen brings up the fact that when WordPress adopts modern technologies, so does most of the web citing responsive images as an example. He asks Mullenweg if WordPress can do the same for accessibility in which the audience responds with applause. Mullenweg responds with a simple yes.

Thinking of Accessibility as Just a Checkbox

Hendriksen then asks a follow-up question, “Can you tell everyone in this room and community that when they learn JavaScript, to also add on that little accessibility part, so that we’re building everything accessible and tell the world that the web should be accessible and that’s the WordPress way?”

Mullenweg responds by agreeing the web should be accessible but says, “I’m worried about getting to a point where we think of accessibility like a checkbox. Even though there are great guidelines and things like that, I think that accessibility is a process and it’s going to be driven sometimes not by every single person, but by groups like the amazing accessibility team and most importantly by the people who need the technology, communicating, and us observing that.

“So, I do think that we have presentations on accessibility at every single WordCamp, we have the accessibility guidelines online but I think we’re a little behind on the theme reviews which is part of the reason the number hasn’t grown as much because the accessibility reviews are more difficult than a standard review, but I’m really excited about what this group has been able to do and the growing momentum it’s gained in the WordPress world.”

“I don’t think that saying I want things to be accessible moves things forward as much as the continuing education that we’re doing through every single WordCamp, the guidelines, and the group,” Mullenweg said. He also highlights the need to think of accessibility in a global sense.

“I think about the 6.99 billion people who haven’t used WordPress yet and many of those who can’t. I also think about accessibility in terms of languages and touch devices.

“These are things that as we get there, what we do right can expand to a larger audience. I encourage everyone to keep that in mind, but learn JavaScript as well,” he said.

Mullenweg’s responses reinforce the fact that accessibility remains a priority for the WordPress project. If you notice a typo or want to give feedback on the WordPress accessibility guidelines draft, please leave a comment on the post. Also, check out the Make WordPress Accessible site for information on how you can help make WordPress more accessible.

by Jeff Chandler at January 26, 2016 10:56 PM under accessibility

Matt: Marketing at Automattic

One of the areas where Automattic and its products like WordPress.com have the most room for growth is in the area of marketing. It’s also an area our competitors are spending heavily in, with Wix, Weebly, Squarespace, Web.com, and to a lesser extent EIG and Godaddy, spending over $350M this year in advertising. (Of course marketing is much more than just advertising, but their spend is still significant.) We’re hiring for a number of positions in this area to build up our team, including a CMO, a performance marketing specialist, marketing-oriented designer, and a role focused on events. If you know of anyone who would be ideal for these roles, or if that person is you, please read about Automattic on that page and follow the guidelines for the role to apply.

by Matt at January 26, 2016 08:29 PM under Asides

WPTavern: Kernl to Offer Hosted Private Plugin and Theme Updates


Jack Slingerland started hacking on WordPress in 2008, but recently his career has taken him a bit further afield from it than he would like. By day he is a Senior Software Engineer at CA Technologies in Raleigh, working in React/Redux, Node, ElasticSearch, Grails, and Groovy. But at night he is busy building Kernl, a service that provides private plugin and theme updates for WordPress.

Once a plugin has been added to the service, the updates delivered from Kernl will look exactly like updates from WordPress.org.

“Kernl’s core feature is providing private plugin and theme updates for WordPress developers. However, our differentiating features are what get me excited,” Slingerland said. “We have purchase code validation (so only authorized users can download updates) and continuous integration (CI) support.

“The CI stuff is really neat, because it allows WP developers to push their code into GitHub or BitBucket and then have it automatically packaged and deployed to their customers. CI has been traditionally hard to do on WordPress because your ‘production’ environment is often something you don’t control,” he said. “Kernl solves that problem.”

The idea for Kernl came to Slingerland after previous years trudging through client work.

“One thing that constantly nagged at me was how hard it was to get any bug fixes or feature updates out to my clients,” he said. “I often didn’t manage their sites, so getting them updates involved lots of emailing and communication overhead.

“I originally had the idea for Kernl back in 2011, but never executed on it until last year,” Slingerland said. “I was hoping that I could help other people solve the same problem I had.”

Kernl launched in private alpha in May 2015 with ~65 alpha users. In November he opened it up for public beta and the service now has approximately 100 beta users. Testers are currently putting Kernl through its paces:

  • Kernl hosts 73 plugins & 43 themes (117 total)
  • The service processed 4.07 million update checks since May
  • Kernl processes around ~2 update status checks / second
  • 14,100 updates have been downloaded from Kernl

How does Kernl compare to WP Pusher?

I asked Slingerland about how Kernl measures up to WP Pusher, which allows developers to deploy WordPress themes and plugins from GitHub and Bitbucket.

“Kernl doesn’t require your end-user to install anything besides your plugin/theme,” Slinglerland said. “If I understand WP Pusher correctly, you first install WP Pusher, then tell WP Pusher to manage updates for a given plugin/theme via it’s version control repository. But this has to happen on every end user installation and might feel complicated to non-technical users.

“Kernl works seamlessly with your plugin/theme, just like those that are installed from the WordPress.org repository. This makes installing and updating feel familiar and blend in seamlessly,” he said.

“We also have purchase code validation, which is going to be getting some love and an API after we go live. Kernl also supports versioning your plugin/theme, so intermediary commits don’t get randomly sent out to your customers.”

The Importance of Continuous Integration

One of the reasons Slingerland built Kernl is because he wants to help more WordPress developers add continuous integration to their workflows. This particular aspect of the app (the “push to build” feature) posed the biggest technical challenge but was one of the most important problems for Kernl to solve.

“There are a lot of edge-cases that I didn’t foresee, especially once I started integrating with both BitBucket and GitHub,” Slingerland said. “In these cases the beta testers were invaluable in helping ferret out bugs.

“Having a solid continuous integration and deployment workflow really changes the way you think about development,” he said. “Instead of having ‘big bang’ once a quarter feature releases, it becomes easier to iterate on your idea. Fail fast, validate your ideas/changes, and iterate again. It’s a big enabler of the Agile development methodology, and I feel that the WordPress plugin/theme community has kind of lacked that. It encourages good testing as well, which is almost required if you are deploying continuously.”

Slingerland is aiming Kernl at developers who create WordPress plugins and themes that are not hosted on WordPress.org. A handful of his beta users have even been using the service to distribute updates for their own beta testers before they publish an official release to WordPress.org.

Kernl will host any plugin or theme for free as long as it is both open source and freely available. Pricing for commercial plugins and themes will range from $5 – $25/month. The service is free to use during the beta period, which is planned to be wrapped up in mid-February.

Kernl Will Not Police Product Licensing

After further inquiry regarding Kernl’s position on the licensing of products it hosts, Slingerland states that he will not police his customers’ licensing. This means that authors of non-GPL themes and plugins would be welcome to distribute their software via his platform. Since themes and plugins are derivative works of WordPress, they are required to be licensed under the GPL.

Slingerland’s lack of willingness to police non-GPL software has the potential to make Kernl a hive for products that break WordPress’ license. The service makes it easy to distribute non-GPL software that masquerades in the admin as regular compliant plugins/themes when it comes to updates.

Distributing non-GPL software can be a deal breaker for WordPress developers who feel strongly about the GPL. The GPL protects users’ freedom to use and modify the software for any purpose, and many developers have built their businesses and reputations on upholding that freedom.

Software hosted by Kernl may or may not comply with GPL licensing, and the user may never know. This leaves the user vulnerable in a way that official updates from WordPress.org does not. Developers who don’t want to be parcel to supporting a platform that has the potential to distribute non-GPL software may want to look for an alternative.

by Sarah Gooding at January 26, 2016 06:44 PM under kernl

Follow our RSS feed: 

WordPress Planet

This is an aggregation of blogs talking about WordPress from around the world. If you think your blog should be part of this site, send an email to Matt.

Official Blog

For official WordPress development news, check out the WordPress Core Blog.


Last updated:

February 12, 2016 12:00 PM
All times are UTC.