This year’s WordCamp Milwaukee featured an array of impressive speakers who discussed trending topics on WordPress business and development. The speakers even included a presentation on Joomla and how to use other PHP frameworks to overcome the limitations of WordPress.
A few weeks ago, I wrote about what you can expect in WordPress 4.0, but at WordCamp Milwaukee last weekend I actually got a glimpse into what the future of WordPress has to offer. Presentations by Andrew Nacin, one of the lead developers of WordPress, as well as the lead developers of the REST API project, Ryan McCue of Human Made and Rachel Baker of 10up, detailed some very exciting new capabilities of WordPress that the next few WordPress releases will unlock. Not all of the work is done, but the structure is in place.
Nacin’s presentation was planned to provide an update on WordPress development. Instead he told the crowd that his only update was that “WordPress 4.0 is gonna be awesome,” and so he moved on to a talk he called “registering metadata at the dawn of external API.” Similarly, a presentation by McCue and Baker showed how these new changes—which will take place over the next several iterations of WordPress—will take WordPress to an entirely different level and greatly expand its powers.
More Power, More Integrations, and a Bigger Tent
What was clear from these two presentations and an after-party discussion, was that this isn’t just about making WordPress more powerful and giving WordPress developers better tools to work with. These changes are going to make it easier for WordPress to interact with other platforms, content management systems, and even other programming languages.
This means that it will be easier to involve non-WordPress developers in WordPress projects. That’s huge news for anyone who has ever struggled to find talented and available WordPress developers. It also means that it will be easier than ever to choose the best tools for every project.
Nacin pointed out that WordPress has grown to the point where not everyone can keep track of the whole project. But, reorganizing trac around components and developing features as plugins allows people to really focus on what they’re good at and what is important to them. According to Nacin, the best projects to jump on are the REST API project and the Metadata project, lead by Scott Kingsley Clark of 10up and The Pods Framework. Nacin detailed why these two projects are so important, which provided an excellent follow up to the talk about REST API.
REST API: WordPress’s New JSON Rest API
McCue and Baker indicated that JSON was selected to base the API on because of its human readability, “JSON is supported by basically everything.” In addition to being a widely adopted standard, it maps well to most programming languages.
WordPress’ new REST API is not a replacement for existing tools such as XML-RPC, which will remain in core. Instead is should be seen as an enhancement for existing tools and as a new tool itself. McCue pointed out that roughly 40% of the WordPress iOS app is for reading XML-RPC and that XML-RPC, and is “a standard, but it’s basically dead at this point.” This is a major hurdle for developing native mobile apps that use WordPress for content management. Having REST API in core will make this type of development easier.
REST API is also not a replacement for the WordPress.com JSON API—which McCue called great and easy to use but not an ideal solution for everyone. This is because it requires the plugin JetPack, and cannot be used offline. Also, many users will not want to pass all of their data through WordPress.com’s servers.
According to Baker, the most exciting part of having this API in WordPress is that it will enable us to “break content completely free from WordPress.” For example, REST API can be used to show content in a mobile app, or a site with a non-WordPress CMS or even written in non-PHP. Inside WordPress, the API can be used to power backbone or angular themes and plugins, and load data into the browser without page loads for form validation and for front-end content editing.
While the project is unfinished, it is fairly mature and the plugin it currently lives in is totally usable and will not break backwards-compatibility moving forward. Currently REST API can read, create, edit, and delete most WordPress content types and do almost everything WP_Query can. On GitHub they have docs, API console, oAuth, and dev authentication tools. In addition, they have clients for JavaScript, PHP, and WP-CLI.
But REST API can’t do everything yet. For example, you can’t create custom post types or taxonomies via the API, however you can manipulate them once they exist. Eventually REST API will add support for changing plugins, themes, and interacting with the customizer. For now they plan on staying more focused on content interaction, but in the future more control over WordPress via API can be expected.
WordPress Metadata at the Dawn of External API
Nacin’s presentation focused on some of the frequently overlooked capabilities of how metadata works in WordPress. Much of what he discussed has been in place for several versions, but is becoming important now that the new API is in play. The main functionality Nacin discussed is register_meta(), which allows developers to add what he called meta capabilities for the metadata.
By registering a meta key before saving any post metadata with that key, developers can have more control over how it can and cannot be used. This function mirrors how other functions, such as register_setting(), work. It allows developers to add a sanitization callback.
This is huge for many reasons. For example, with a sanitization callback, you only need to handle sanitization in one place, and you can pass user-inputted data including $POST data directly to update_post_meta(), which would otherwise be incredibly dangerous.
More importantly, since the sanitization callback is not run at the API level, you can use return_false() as your callback to prevent users from directly manipulating this metadata, but still be able to manipulate it via the API.
In addition, it means you can check user capabilities on a more abstracted level. For example, traditionally we’ve only been able to test user capabilities based on what capabilities the user’s assign role offers. With this technique we can check, still using capabilities API, on a per post level.
Nacin indicated that in the future he’d like to see full REST API support for metadata manipulation. Right now it can’t happen, as there are no meta field types. As a result, the API doesn’t know if it is looking at a date-picker field or a serialized array of data. Creating meta field types is a major focus of the metadata project. Having field types would enable a form builder. In addition, it would allow for the creation of a meta box helper class in core. This class would act like the Widget helper class and “make metaboxes suck a little less.”
WordPress Is Changing and Staying the Same
Beyond giving existing developers new tools, these exciting new changes are going to help us bring new developers into the WordPress world, with a much easier on-boarding process. This is almost as important as the possibilities the changes open up to developers already working in the WordPress community. The more high-quality developers that we bring into our ecosystem, the stronger the ecosystem will be.
With all of these huge changes coming, it’s important to remember that one thing isn’t changing: WordPress’s commitment to backwards-compatibility. All the features you’re using now are not going anywhere. If you want to keep using WordPress the same way as you always have, you can. These new capabilities will simply be added to the set of tools available to us as WordPress developers.
No Comments