WP REST API: Versions 2.0 Beta 12.1 and 2.0 Beta 13.1

WP REST API Versions 2.0 Beta 12.1 and 2.0 Beta 13.1 are security releases to address a data privacy issue with the Users endpoint. Given certain parameters, private user data such as email addresses may be exposed to unauthenticated users.

This release was coordinated by the REST API team and the WordPress core security team. The security team is pushing automatic updates, but do not wait or rely on the automatic update process. We recommend sites or plugins that are using either 2.0 Beta 12 or 2.0 Beta 13 to update the plugin immediately. Download your respective version from WordPress.org or Github.

Thanks to James Kettle (PortSwigger Web Security) via HackerOne for reporting this issue to the team responsibly, and to David Remer (websupporter) for inadvertently fixing this issue on Github.

If you believe you have discovered a potential security vulnerability with the WP REST API, please disclose it to us privately by sending an email to security@wordpress.org. Security issues can also be reported via HackerOne.

#rest-api

WP REST API: Version 2.0 Beta 12

Happy Tuesday 🙂 The WP REST API team is proud to bring you: 2.0 Beta 12 “Canyonero”. Download it from the plugin repository or from GitHub.

Here are some highlightsbreaking changes from the changelog:

  • Removes meta endpoints from primary plugin. If your project depends on post meta endpoints, please install WP REST API Meta Endpoints. For the gory history of meta, read #1425 and linked issues. At this time, we recommend using register_rest_field() to expose meta (docs).
  • Returns original resource when deleting PTCU. Now that all resources require the force param, we don’t need to wrap delete responses with the trash state.
  • Uses roles rather than role in the Users controller. Building the REST API gives us the opportunity to standardize on roles, instead of having both roles and role.
  • Moves to consistent use of context throughout controllers. Contexts limit the data present in the response. Here’s how to think of them: embed correlates with sidebar representation, view represents the primary public view, and edit is the data expected for an editor.
  • Removes post_* query param support for GET /wp/v2/comments. The proper pattern is to use GET /wp/v2/posts to fetch the post IDs to limit the request to.
  • Introduces rest_validate_request_arg()/rest_sanitize_request_arg(). Dedicated functions means we can use them for validating / sanitizing query args too. Removes WP_REST_Controller::validate_schema_property() and WP_REST_Controller::sanitize_schema_property().

As always, we have a detailed changelog as well as the full set of changes if you’re interested.

What’s the future of the WP REST API? I’d like to leave you with this final thought:

What came first, the chicken or the egg?
I egged the chicken, and then I ate his leg

#feature-plugins, #json-api, #rest-api

Thar be a WP REST API meeting tomorrow

Curious as to when the WP REST API endpoints will land in WordPress core? Me too!

We’re meeting to discuss the State of the REST API just under 24 hours from now in #core-restapi on Slack: Thursday, February 4 at 23:00 UTC

The primary points of discussion are:

  • Existing Post, Term, User and Comment endpoints.
  • New Site, Widgets, Menus, Plugins and Themes endpoints we started on Friday.
  • REST API clients — those that exist, and those that don’t yet.
  • Happy fun authentication methods.

See you there!

#feature-plugins, #json-api, #rest-api

WP REST API: Version 2.0 Beta 11

Just days before the first conference dedicated to the REST API, we bring you: 2.0 Beta 11 “Give me a white wine spritzer!”. Download it from the plugin repository or from GitHub.

Here are some highlightsbreaking changes from the changelog:

  • Moves Post->Term relations to the Post Resource. Previously, a client would fetch a Post’s Tags with GET /wp/v2/posts/<id>/tags. In Beta 11, an array of term ids is included on the Post resource. The collection of terms for a Post can be fetched with GET /wp/v2/tags?post=<id>. The WP_REST_Posts_Terms_Controller class no longer exists.
  • Changes featured_image attribute on Posts to featured_media. While featuring other attachment types isn’t yet officially supported, this makes it easier for us to introduce the possibility in the future.
  • Uses discrete schema title for categories and tags. If you’ve used register_rest_field( 'term' ), you’ll need to change 'term' to 'tag' and/or 'category'.
  • Makes many filters dynamic based on the controller type. If you were using the rest_prepare_term filter, you’ll need to change it to rest_prepare_post_tag or rest_prepare_category. If you were using rest_post_query or rest_terms_query, you’ll need update your use to rest_page_query, etc. If you were using rest_post_trashable, rest_insert_post or rest_delete_post, they are now dynamic based on the post type slug.

As always, we have a detailed changelog as well as the full set of changes if you’re interested.

#feature-plugins, #json-api, #rest-api

WP REST API: Version 2.0 Beta 10, with security releases

For the first REST API release of 2016, we bring you: 2.0 Beta 10 “Chief Wiggum”. Because we’ve got security releases too, Ralphie.

Security Releases

On Friday, we discovered that attachments uploaded to private posts are publicly queryable through the REST API. This is a form of information disclosure because WordPress’ permissions model is such that attachments uploaded to posts should inherit the visibility of their parent post.

All previous versions of the plugin are affected. All WP REST API users are strongly encouraged to update immediately. Many prior releases has been separately patched. If you’re still using WP-API v1.x, you can update to v1.2.5. If you’re on an older 2.0 Beta for whatever reason, we’ve tagged versions 2.0 Beta 3.1, 4.1, 5.1, 6.1, 7.1, 8.1, and 9.1.

If you believe you have discovered a potential security vulnerability with the WP REST API, please disclose it to us privately by sending an email to security@wordpress.org. Security issues can also be reported via HackerOne.

Version 2.0 Beta 10

Here are some of the highlights of Beta 10:

  • Breaking changes:
    • Removes compatibility repo for WordPress 4.3. WordPress 4.4 is now the minimum supported version.
    • Changes link relation for types and taxonomies. In Beta 9, this link relation was introduced as item, which isn’t correct. The relation has been changed to https://api.w.org/items.
    • Introduces edit context for wp/v2/types and wp/v2/taxonomies. Some fields have moved into this context, which require edit_posts and manage_terms, respectively.
    • Removes post_format as a term _link for Posts. Post formats aren’t a custom taxonomy in the eyes of the REST API.
  • Consistently query for a specified set of items. Adds include param to /wp/v2/posts, /wp/v2/users, /wp/v2/<taxonomy> and /wp/v2/comments.
  • Tons of minor improvements and bug fixes. You should read the full changelog for all of them.

As always, we have a detailed changelog as well as the full set of changes if you’re interested.

#feature-plugins, #json-api, #rest-api

WP REST API: Version 2.0 Beta 9

For the last REST API release of 2015, we bring you: 2.0 Beta 9 “You Don’t Win Friends With Salad”. Download it from the plugin repository or from GitHub.

Should I use 2.0 Beta 9 in production?

This is a great question. I (Daniel) will do my best to answer from my perspective — Ryan, Rachel or Joe may have different opinions.

As many of you may already know, the v1.x branch is essentially deprecated and only maintained for security and major compatibility issues. Even its latest release, v1.2.4, still includes some annoying bugs. The v2.0 Betas introduce aton of new features, functionality, and general improvements. But, there will never be a formal v2.0 plugin release — v2.0 will be endpoint inclusion into WordPress core.

Right now, we’re doing our darned best to get the endpoints into core at the end of January 2016. Between now and then we have at least 74 issues to wade through. Beta 9 includes 32 merged pull requests.

In the interest of feeling confident about the code we’re committing to core, we are and will be making breaking changes in the Betas. Significantly, Beta 10 will remove the core directory, and will be incompatible with WordPress 4.3.

Short answer: you’re welcome to use the Betas in production if you understand the ramifications. When updating, we expect you to read through the changelog and thoroughly test each release with your project. You should probably have test coverage on any custom endpoints you’re writing. And, set aside time to properly debug any issues you uncover and submit pull requests with test coverage.

If you aren’t comfortable with aforementioned ramifications, please refrain from using the v2.0 Betas in production. We do encourage everyone to use them locally, or in staging / test environments, and look forward to your feedback.

Changelog

Here are some highlights:

  • Move tags and categories to top-level endpoints. Tags are now accessible at `/wp/v2/tags`, and categories accessible at `/wp/v2/categories`. Post terms reside at `/wp/v2/posts//tags` and `/wp/v2//categories`.
  • Return object for requests to `/wp/v2/taxonomies`. This is consistent with `/wp/v2/types` and `/wp/v2/statuses`.
  • Remove `rest_get_timezone()`. `json_get_timezone()` was only ever used in v1. This function causes fatals, and shouldn’t be used.
  • Rename `register_api_field()` to `register_rest_field()`. Introduces a `register_api_field()` function for backwards compat, which calls `_doing_it_wrong()`. However, `register_api_field()` won’t ever be committed to WordPress core, so you should update your function calls.
  • Change taxonomies’ `post_type` argument to `type`. It’s consistent with how we’re exposing post types in the API.
  • Sync infrastructure with shipped in WordPress 4.4.
    • `wp-includes/rest-api/rest-functions.php` is removed, and its functions moved into `wp-includes/rest-api.php`.
    • Send nocache headers for REST requests.
    • Fix handling of HEAD requests.
    • Mark `WP_REST_Server::get_raw_data()` as static.
    • Unabbreviate error string.
  • Change terms endpoints to use `term_id` not `tt_id`.
  • Standardize declaration of `context` param for `GET` requests across controllers. However, we’re still inconsistent in which controllers expose which params. Follow #1845 for further discussion.
  • Link types / taxonomies to their collections, and vice versa. Collections link to their type / taxonomy with the `about` relation; types / taxonomies link to their collection with the `item` relation, which is imperfect and may change in the future.

As always, we have a detailed changelog as well as the full set of changes if you’re interested.

#feature-plugins, #json-api, #rest-api

WP REST API: Version 2.0 Beta 8

Just in time for WordCamp US, we have a new REST API for you: 2.0 Beta 8 “Monorail!”. Download it from the plugin repository or from GitHub.

Here’s the changelog:

  • Prevent fatals when uploading attachment by including admin utilities. (#1756)
  • Return 201 status code when creating a term. (#1753)
  • Don’t permit requesting terms cross routes. (#1764)
  • Set fields=>id when using WP_User_Query to fix large memory usage. (#1770)
  • Fix Post _link to attached attachments. (#1777)
  • Add support for getting a post with a custom public status. (#1765)
  • Ensure post content doesn’t get double-slashed on update. (#1772)
  • Change ‘int’ to ‘integer’ for WP_REST_Controller::validate_schema_property() (#1759)

Check out the full set of changes if you’re interested.

#feature-plugins, #json-api, #rest-api

WP REST API: Version 2.0 Beta 7

Hot out of the version controls, we have a new REST API for you: 2.0 Beta 7 “Tastes Like Burning”. Download it from the plugin repository or from GitHub.

Here’s the changelog:

  • Sync infrastructure from WordPress core as of r35691.
    • Remove register_api_field() because it’s conceptually tied to WP_REST_Controller #34730
    • Update the REST API header links to use api.w.org #34303
    • Require the $namespace argument in register_rest_route() #34416
    • Include enum and description in help data #34543
    • Save preg_match iterations in WP_REST_Server #34488
    • Don’t return route URL in WP_REST_Request:get_params() #34647
  • Restore register_api_field() within the plugin. (#1748)
  • Require admin functions for use of wp_handle_upload(), fixing fatal. (#1746)
  • Properly handle requesting terms where parent=0 and 0 is a string. (#1739)
  • Prevent PHP error notice when &filter isn’t an array. (#1734)
  • Change link relations to use api.w.org. (#1726)

Check out the full set of changes if you’re interested.

#feature-plugins, #json-api, #rest-api

WP REST API: Versions 1.2.4 (Compatibility Release) and 2.0 Beta 6

First and foremost: version 1.2.4 of the REST API is now available for compatibility with the upcoming WordPress 4.4. Version 1.2.4 overrides REST API infrastructure in WordPress 4.4 core, leaving your endpoints working as you expect them to. Download it from the plugin repository or from GitHub.

Version 2.0 Beta 6

Alongside the compatibility release for version 1.2, we’re also releasing the latest beta for version 2.0: 2.0 Beta 6 “Bluella The Whale”. Download it from the plugin repository or from GitHub.

Here are some highlights:

  • Removes global inclusion of wp-admin/includes/admin.php. For a long time, the REST API loaded wp-admin/includes/admin.php to make use of specific admin utilities. Now, it only loads those admin utilities when it needs them. If your custom endpoints make use of admin utilities, you’ll need to make sure to load wp-admin/includes/admin.php before you use them.
  • Easier access to the featured image. Posts link directly to the featured image, and attachments include media_details attribute in the embed context. For image attachments, media_details includes a sizes array of image sizes, which is useful for templating.
  • Documentation clarifications throughout, including new hook docs.

As always, we have a detailed changelog as well as the full set of changes if you’re interested.

#feature-plugins, #json-api, #rest-api

Shortcake (Shortcode UI) chat summary – November 2nd, 2015

Present: @danielbachhuber, @goldenapples, @matth_eu

Logs: https://wordpress.slack.com/archives/feature-shortcode/p1446494424000273

  • We released Shortcake v0.6.0. Read through the full release notes.
  • Weekly meetings are on hold until January. Between now and then, we’ll be thinking about what we need to do to put forth a core proposal. @matth_eu might put together sketches.
  • We missed the boat on getting a Shortcake representative to the community summit, and are researching ways to helicopter @goldenapples to said community summit boat.

Next chat: sometime in January 2016

#chats, #feature-plugins, #meeting-notes, #shortcode-ui, #shortcodes, #updates