11 Feb 2016
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.
11 Feb 2016 3:28pm GMT
10 Feb 2016
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:
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.
10 Feb 2016 7:03pm GMT
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.
10 Feb 2016 12:30pm GMT
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.
10 Feb 2016 5:19am GMT
09 Feb 2016
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.
09 Feb 2016 11:58pm GMT
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.
09 Feb 2016 9:03pm GMT
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.
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.
Right about now seems like a good time to get official feedback on WP REST API from @wordpress's lead developers and committers. Just sayin'
- Daniel Bachhuber (@danielbachhuber) February 9, 2016
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:
@danielbachhuber I'm for iterative inclusion of REST API endpoints, advising clients to make use of feature detection.
- Weston Ruter ⚡ (@westonruter) February 9, 2016
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.
09 Feb 2016 8:33pm GMT
photo 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.
09 Feb 2016 5:06pm GMT
08 Feb 2016
photo 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.
@Krogsgard No one is against iteration. It's: iterate in plugin with low stakes, or iterate in core, shipping to tens of millions of sites?
- Matt Mullenweg (@photomatt) February 8, 2016
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.
08 Feb 2016 10:06pm GMT
05 Feb 2016
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:
- ACF to REST API - 200+
- ACF to WP-API - 1,000+
- ACF to WP REST API - 300+
- Custom Contact Forms - 70,000+
- Dashboard Directory Size - 100+
- Invitations for Slack - less than 10
- JWT Authentication for WP REST API - 100+
- oEmbed API - no longer available as of 2/5/2016
- Prayers - less than 10
- WP REST API - 9,000+
- REST JSON - less than 10
- REST Routes - less than 10
- SearchWP API - 20+
- Maps by Storelocator Plus - 10,000+
- Tabulate - 100+
- WP API Categories + Tags - 10+
- WP API Menus - 700+
- WP REST API Log - 100+
- WP REST API Sidebars - less than 10
- WPRestApiExtensions - less than 10
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.
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.
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.
05 Feb 2016 11:06pm GMT
I'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.
05 Feb 2016 10:42pm GMT
Welcome to the Post Status Draft podcast, which you can find on iTunes, Stitcher, 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.
Photo credit: Aaron Jorbin
05 Feb 2016 6:34pm GMT
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.
05 Feb 2016 6:59am GMT
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.
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."
05 Feb 2016 12:58am GMT
04 Feb 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.
04 Feb 2016 7:25pm GMT
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:
- Development for bulk plugin action notifications
- Design for updating themes from the theme card (on top of from details modal)
- Another round of user tests to get more feedback on the new flows
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.
04 Feb 2016 12:56am GMT