Hello everyone. Remember us? Today, I can finally announce the release of version 1.2 of the WP REST API.

A short nine months after our last release we have support for Cross-Origin Resource Sharing, full request hijacking, JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. encode/decode errors, and a swarm of bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes.

Here are the expanded highlights:

• Add handling for Cross-Origin Resource Sharing (CORS) OPTIONS requests.

  Preflighted requests (using the OPTIONS method) include the headers Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Credentials in the response, if the HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. origin is set.

  (props @rmccue, #281)

• Allow overriding full requests.

  The json_pre_dispatch filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. allows a request to be hijacked before it is dispatched. Hijacked requests can be anything a normal endpoint can return.

  (props @rmccue, #281)

• Check for JSON encoding/decoding errors.

  Returns the last error (if any) occurred during the last JSON encoding or decoding operation.

  (props @joshkadis, @rmccue, #461)

• Add filtering to the terms collection endpoint.

  Available filter arguments are based on the get_terms() function. Example: /taxonomies/category/terms?filter[number]=10 would limit the response to 10 categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. terms.

  (props @mauteri, #401, #347)

• Add handling for the role parameter when creating or updating a user.

  Allow users to be created or updated with a provided role.

  (props @pippinsplugins, #392, #335)

• Add handling for the post_id parameter when creating media. Allow passing the post_id parameter to associate a new media item with a post.

  (props @pkevan, #294)

• Handle route matching for - in taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. and terms.

  Previously the regular expression used to match taxonomy and term names did not support names with dashes.

  (props @EdHurtig, @evansobkowicz, #410)

• Handle JSONP callback matching for . in the function name.

  Previously the regular expression used to match JSONP callback functions did not support names with periods.

  (props @codonnell822, #455)

• Fix the Content-Type headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. for JSONP requests.

  Previously JSONP requests sent the incorrect application/json Content-Type header with the response. This would result in an error if strict MIME checking was enabled. The Content-Type header was corrected to application/javascript for JSONP responses.

  (props @simonlampen, #380)

• Add $context parameter to json_prepare_term filter.

  Terms responses can now be modified based on the context parameter of the request.

  (props @traversal, #316)

• Move the JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. client library into the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.

  Previously, the wp-api.js file was a separate repository. The JavaScript client has moved back into the plugin to coordinate code changes.

  (props @tlovett1, #730)

• Always return an object for media sizesThe media sizes value should always be an object even when empty.

  Previously, if a media item did not have any sizes set, an empty array was returned.

  Compatibility warning: Clients should be prepared to accept an empty object as a value for media sizes.

  (props @maxcutler, #300)

• Give top-level posts a null parent value.

  For date type consistency, post parent property should be null. Previously, parent-less posts returned 0 for parent.

  Compatibility warning: Clients should be prepared to accept null as a value for post parent.

  (props @maxcutler, #391)

• Move permission checks out of WP_JSON_Posts.

  Introduce json_check_post_permission() function to allow post object capability checks to be used outside the WP_JSON_Posts class.

  Deprecation warning: Calling WP_JSON_Posts::check_read_permission and WP_JSON_Posts::check_edit_permission is now deprecated.

  (props @rachelbaker, #486, #378)

• Split comment endpoints into separate class.

  All comment handling has moved to the WP_JSON_Comments class.

  Deprecation warning: Calling WP_JSON_Posts::get_comments, WP_JSON_Posts::get_comment, WP_JSON_Posts::delete_comment, and WP_JSON_Posts::prepare_comment is now deprecated.

  (props @whyisjake, @rmccue, @rachelbaker, #378)

• Split metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. endpoints into separate class.

  All post meta handling has moved to the new WP_JSON_Meta_Posts class.

  Deprecation warning: Calling WP_JSON_Posts::get_all_meta, WP_JSON_Posts::get_meta, WP_JSON_Posts::update_meta, WP_JSON_Posts::add_meta, WP_JSON_Posts::delete_meta, WP_JSON_Posts::prepare_meta, and WP_JSON_Posts::is_valid_meta_data is now deprecated.

  (props @rmccue, @rachelbaker, #358, #474)

• Rename internal create methods.

  Deprecation warning: Calling WP_JSON_Posts::new_post, WP_JSON_CustomPostType::new_post and WP_JSON_Posts::new_post is now deprecated.

  (props @rachelbaker, @rmccue, #374, #377, #376)

• Fix discrepancies in edit and create posts documentation examples.

  Corrected the edit and create posts code examples in the Getting Started section. The new post example was updated to include the required content_raw parameter. The new and edit posts examples were updated to use a correct date parameter.

  (props @rachelbaker, #305)

• Update the cookie authentication documentation examples.

  With 1.1 the localized JavaScript object for wp-api.js changed to WP_API_Settings. This updates the Authentication section documentation nonce example to use the updated object name.

  (props @rachelbaker, #321)

• Add flexibility and multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site support to unit tests.

  Tests can be run from any WordPress install, and are not limited to only as a plugin installed within a WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ develop checkout. Unit tests are now run against a multisite installation.

  (props @danielbachhuber, #397)

As always, we’ve got a full list of all the changes and a longer changelog.

Here’s who contributed to this release:

$ git shortlog 1.1.1...1.2 --summary
    1  Chris O'Donnell
    12  Daniel Bachhuber
     1  David Hayes
     4  DrewAPicture
     7  Eddie Hurtig
     2  JDGrimes
     1  Japh
     5  Josh Kadis
     1  Josh Pollock
     1  Justin Sternberg
     2  K.Adam White
     1  Marko Heijnen
     2  Max Cutler
     2  Mike Auteri
     1  Milan Dinić
     1  NikV
     3  Paul Kevan
     2  Pippin Williamson
    86  Rachel Baker
    73  Ryan McCue
     7  Sarah Gooding
     1  Simon Lampen
     2  Taylor Lovett
     1  Travis Hensgen
     1  Wayne K. Walrath
     1  ironpaperweight
     1  kalenjohnson
     1  kellbot
     1  paul de wouters

Release Plan

1.2 will be the last major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. on the 1.x branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of the plugin. We’ve been working hard over the past four months, with the aim of releasing a betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. for version 2.0 next month.

For existing code written for version 1.x we will issue a final 1.x release as a compatibility shim to seamlessly connect existing code to version 2.

#json-api, #rest-api