WordPress.org

Make WordPress Core

Tagged: json-api Toggle Comment Threads | Keyboard Shortcuts

  • Daniel Bachhuber 11:17 pm on February 3, 2016 Permalink |
    Tags: , json-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!

     
  • Daniel Bachhuber 5:21 pm on January 11, 2016 Permalink |
    Tags: , json-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.

     
  • Daniel Bachhuber 7:00 pm on December 11, 2015 Permalink |
    Tags: , json-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.

     
  • Ryan McCue 9:52 am on December 7, 2015 Permalink |
    Tags: , json-api,   

    WP REST API: New Tools & OAuth Updates 

    Hi everyone! I’m here today with some special news for everyone, rather than a standard release announcement. I have three things to announce instead. 🙂

    Discovery Library for PHP

    A super cool thing that you might not know about with the API is that it’s entirely discoverable. We use a relatively simple process modelled after Atom/RSS feed discovery. All you need to do is check a site’s headers for a Link header:

    Link: <http://example.com/wp-json/>; rel="https://api.w.org/"

    This allows a tonne of possibilities, including renaming the API base, or even delegating API access to someone else. (For example, WordPress.com could use https://api.wordpress.com/{site_id}/ instead of per-site APIs.)

    However, this isn’t always the easiest process to use (even if you have an advanced degree in hypothetical topology). To simplify this, we now have a discovery library for PHP 5.3+.

    To use it, add wp-api/discovery to your Composer requirements manually or run composer require wp-api/discovery in your project directory. You can then use the WordPress\Discovery\discover() function to discover the API for a given URL. (Oh hey, namespaces!)

    The library also includes a demo that you can run using PHP’s built-in server, and we’re working on getting a public version of this up on wp-api.org so you don’t even need to install it.

    This should simplify the discovery process for everyone, and I’m hoping some wonderful folks in the community will help port this to other languages as well. (Hint hint.)

    New OAuth Server

    One of the weakest points of developing with the API right now is getting authentication working. For a long time, our OAuth server plugin has languished and fallen behind as we push forward with the API. No longer is this the case!

    Simply update to the latest master. This will also be available on WordPress.org very soon.

    This new version of the OAuth server has a bunch of changes, including:

    • Full admin UI, including application management and the ability to revoke tokens
    • Ability to delete applications or regenerate their secrets
    • Callback validation process overhaul, now supporting custom protocols
    • Overhauled internals

    In addition to this, I wanted to address one of the biggest problems with the OAuth process: documentation. The documentation for the OAuth server and process has been terrible in the past. Previously, I’d indicated to people that they should just go read the generic OAuth 1.0a documentation on the web and try with that, but as it turns out, there’s no good documentation on this. (Apologies to those of you who’ve struggled in the past.)

    Thankfully, this is now fixed, with a guide included and available on Gitbook. This is an initial version of the guide, and I imagine it’ll grow and improve further in the future.

    If there’s anything missing you’d like added or improved, file an issue on the plugin repo. (The guide’s source is also included with the plugin.)

    Demo API Client

    (pause for breath)

    Combining all these pieces, there’s now a demo API client in PHP that you can download and run to try all of this out. The demo client uses the discovery library to find your site, then connects with OAuth to display your user details. Again, you can run this locally using PHP’s built-in server, and we’re working on getting a version set up on wp-api.org too.

    Internally, this uses the wonderful OAuth 1 client library by The League of Extraordinary Packages. This repo also acts as a provider for that library, allowing you to use the library in your own code to handle OAuth.

    (Both the discovery library and the demo client are open source and MIT licensed, allowing you to use them in commercial projects should you so desire.)

    Hopefully you find these pieces useful. As always, your feedback on all of this is much appreciated; we’d also love to see discovery libraries and demo clients in other languages, if anyone wants to port them across. Thanks for being great.

     
    • jeffikus 10:41 am on December 7, 2015 Permalink | Log in to Reply

      This is awesome, the last piece I’ve been hoping would come out soon 🙂 Major kudos for this, quick question though, I see the demo API client is in PHP, any plans for a JS demo?

      • jeffikus 10:42 am on December 7, 2015 Permalink | Log in to Reply

        Oh gosh, I just re-read the last paragraph, ignore me 🙂 i’ll try get a JS version together and post it here 🙂

    • Justin Greer 1:37 pm on December 7, 2015 Permalink | Log in to Reply

      Super excited! I am looking forward to extensions like OpenID Connect and Discovery.

    • Ahmad Awais 2:19 pm on December 7, 2015 Permalink | Log in to Reply

      Awesome sauce! Shit, I wish I could take a holiday and read the source, oh wait, I can! Goes to read the source.

    • Collizo4sky 3:12 pm on December 7, 2015 Permalink | Log in to Reply

      Great job guys. Excited to see some PHP league package get some love in the WordPress community.
      Why reinvent the wheel when it isn’t broken 😀

      Keep up the good job Ryan.

    • Joseph Scott 3:17 pm on December 7, 2015 Permalink | Log in to Reply

      it’s entirely discoverable … including renaming the API base, or even delegating API access to someone else

      Historically this hasn’t worked out that well. I’d recommend shouting this super loud in every code example and article that deals with this API if you want to overcome the lazy momentum of clients assuming the URL will always be DOMAIN/wp-json/

      • Mike Nelson 5:52 pm on December 7, 2015 Permalink | Log in to Reply

        +1 to Joseph’s comment, especially if someone wants to run v1 of the API alongside v2, in which case they would need to have one of the APIs running on a different API base.

        And +1 to these advancements in general!

        • Ryan McCue 11:59 pm on December 7, 2015 Permalink | Log in to Reply

          Fingers crossed we’ll eventually have a 1.9 that has v1 endpoints on v2 infrastructure. 🙂

          • Mike Nelson 6:50 pm on December 8, 2015 Permalink | Log in to Reply

            huh ya that could be nice. I suppose it depends on how well folks start to adopt using v2. If lots of people stay on v1 then it might be nice

      • Ryan McCue 11:58 pm on December 7, 2015 Permalink | Log in to Reply

        > Historically this hasn’t worked out that well

        Agreed, though it has worked well for feed autodiscovery, so I’m optimistic. 🙂

  • Daniel Bachhuber 12:29 am on December 2, 2015 Permalink |
    Tags: , json-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.

     
  • Daniel Bachhuber 12:37 am on November 19, 2015 Permalink |
    Tags: , json-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.

     
    • Samuel Wood (Otto) 1:07 am on November 19, 2015 Permalink | Log in to Reply

      Nice Simpsons reference.

      “That’s where I saw the leprechaun. … He told me to burn things.”

    • chatmandesign 2:28 pm on November 19, 2015 Permalink | Log in to Reply

      api.w.org is not a valid domain. Was that supposed to be an abbreviation for api.wordpress.org?

      • Daniel Bachhuber 2:28 pm on November 19, 2015 Permalink | Log in to Reply

        api.w.org is not a valid domain. Was that supposed to be an abbreviation for api.wordpress.org?

        It will shortly become a valid domain.

      • Ryan McCue 12:35 am on November 20, 2015 Permalink | Log in to Reply

        It’s only a namespace, so it doesn’t need to resolve to anything in particular. 🙂 In the future though, it’ll probably redirect to the documentation.

  • Daniel Bachhuber 9:54 pm on November 12, 2015 Permalink |
    Tags: , json-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.

     
    • Rouven Hurling 10:03 pm on November 12, 2015 Permalink | Log in to Reply

      Okay, so to get the featured image one would have to use “?_embed” and then grab it like this item[‘_embedded’][‘http://v2.wp-api.org/attachment’][0]?
      And it will either be an empty object if no featured image is set or the featured image object?

    • Daniel Bachhuber 10:09 pm on November 12, 2015 Permalink | Log in to Reply

      to get the featured image one would have to use “?_embed”

      Assuming the initial request is for the Post, then ?_embed will give you embedded versions of related resources.

      grab it like this item[‘_embedded’][‘http://v2.wp-api.org/attachment’][0]?

      It’s actually directly linked as item[‘_embedded’][‘http://v2.wp-api.org/featuredmedia’]

      And it will either be an empty object if no featured image is set or the featured image object?

      The link won’t exist if there’s no featured image set.

      • Rouven Hurling 10:15 pm on November 12, 2015 Permalink | Log in to Reply

        Ah, okay.
        I was using http://demo.wp-api.org/ as reference, which isn’t updated yet.
        After updating my local version it makes more sense.

        Any plans for something like `/wp/v2/posts?_embed=featuredimage`, to only embed needed data?

        • Daniel Bachhuber 10:17 pm on November 12, 2015 Permalink | Log in to Reply

          Any plans for something like `/wp/v2/posts?_embed=featuredimage`, to only embed needed data?

          No confirmed plans, but modifying the contents of the response (fields included, embeds added, etc.) is something we’ve been discussing all along.

        • Joe Hoyle 10:25 pm on November 12, 2015 Permalink | Log in to Reply

          I actually wrote a small plugin to do exactly this: https://gist.github.com/joehoyle/12e37c293adf2bb0ea1b

          • Rouven Hurling 8:46 am on November 13, 2015 Permalink | Log in to Reply

            But your version doesn’t seem to work for Collections.
            I modified (mostly copied) it and added a second function to do the same thing for Collections.
            https://gist.github.com/rhurling/e91ddb7b25ccc297508b

            If I understand it correctly it now does basically the same thing, only earlier and for every item, disregarding whether it’s in a Collection or a single Post.

            • Daniel Bachhuber 12:32 pm on November 13, 2015 Permalink

              But your version doesn’t seem to work for Collections.

              This comment thread isn’t an appropriate venue for support. You’re welcome to join us in the #core-restapi channel in the Making WordPress Slack, or continue the conversation with Joe elsewhere.

    • Ahmad Awais 9:41 am on November 13, 2015 Permalink | Log in to Reply

      For how long will you guys support 1.** version of REST API? I have built a few fun projects with it, will update them to REST API 2.0 if the deadline of deprecating v1 is known or something.

      • Daniel Bachhuber 12:29 pm on November 13, 2015 Permalink | Log in to Reply

        For how long will you guys support 1.** version of REST API?

        We’ll be supporting 1.x for security indefinitely. There’s no new development going into the 1.x branch, however.

  • Ryan McCue 6:30 am on October 28, 2015 Permalink |
    Tags: , , json-api,   

    REST API: Welcome the Infrastructure to Core 

    Hi from the REST API team! We’re extremely excited to announce the API infrastructure has now been merged into core as of r34928 (plus a couple of fix up commits we won’t mention). Huzzah!

    Sincere thanks to every single one of the contributors, we wouldn’t be where we are today without you. It takes time and effort to produce great things, and it’s impossible to make things great without everyone helping. This has been a truly collaborative effort, and I wish I could do more than just give you props.

    (Important note: if you have a 2.0 beta already installed, you must upgrade to beta 5.)

    What’s included in 4.4?

    As mentioned in the merge proposal, the API comes in two parts: infrastructure and endpoints. In 4.4, the infrastructure is now available as part of core, while the endpoints continue to only be available in the plugin.

    You can think of the infrastructure as an “API construction kit”. WordPress 4.4 will make it possible for everyone to build RESTful APIs in a much easier fashion, which will benefit people building custom APIs for their site. The infrastructure handles the routing, argument handling, JSON serialisation/deserialisation, status codes, and all that other lovely REST stuff.

    For client authors, this doesn’t help you much right now. Hold tight, the team is working as fast as we can on the endpoints to get them ready for a future release. In the meantime, you can make sure sites you want to work with have the plugin installed, which isn’t a change from the current state.

    For plugin and theme authors, you can start building new APIs immediately using the infrastructure now in core. This can start replacing your existing custom admin-ajax endpoints or other bespoke code you already have.

    To authenticate with the API, only built-in cookie authentication is available out of the box right now. The OAuth 1 plugin will continue to work with WP 4.4 and the API plugin, as will the Basic Auth plugin for local development.

    It’s super easy to get started, and there’s even a guide available to kick-off. (Note: the WP_REST_Controller class is not included in WordPress 4.4.) This documentation will be migrated across to developer.wordpress.org soon.

    If you want to access any of the built-in data in WordPress without building it out yourself, you’ll need the endpoints as well. These will continue to be packaged in plugin form, and version 2.0 final will be released to accompany 4.4 before the end of this cycle.

    What if I’m using the API already?

    If you’re on version 2 of the API, you’ll need to update the API to beta 5 or later before updating to the latest version of core. This new version will use the new infrastructure in core if available, or fallback to a compatibility library otherwise.

    Important note: Earlier 2.0 betas (1 through 4) are incompatible with WP 4.4. Your site will fatal error if you don’t upgrade to beta 5 or later. You must upgrade to the latest API to run trunk and to run WP 4.4 when it’s released.

    If you’re on version 1 of the API, you won’t hit any fatal errors straight away, but endpoints will stop working with 4.4. We’re still planning on releasing a final version 1 release for compatibility, but now would be a great time to consider migrating forward to version 2. Apart from security releases, version 1 has ceased being actively maintained.

    Looking forward for the API

    Now that the API is past this first hurdle, it’s important to keep looking forward. Our immediate next step is to improve and polish the endpoints for phase two of our merge. There’s a lot of work still to be done here, so we’d love you to join us on GitHub.

    The infrastructure of the API will now be maintained via Trac, so new issues and patches should be sent there instead under the “REST API” component. Issues with endpoints should still be filed on GitHub. Don’t worry if you’re not sure; you can file issues on either Trac or GitHub, and they’ll be triaged into the correct place as needed. (It’s more important to make sure the issue is filed in the first place!)

    The team wants to keep pressing forward with the API and keep up our rate of progress, if not improve it even further, and we’d love your help. We still need help from content writers on our documentation, designers and developers on our authentication plugins, and developers on the endpoints. If you want to help, we can always use a hand, and we’d love to help get you started. We’re available in the #core-restapi room on Slack, and we’d love to see you at the weekly meeting at Monday 23:00 UTC 2015.

    We look forward to continuing to work on the API and getting these endpoints happening. Thanks again to everyone who got us here.

    (Then again, maybe a REST API is more of a Shelbyville idea…)

     
    • Ahmad Awais 9:20 am on October 28, 2015 Permalink | Log in to Reply

      It’s a new day 🙂 Looking forward to how REST API transforms WordPress as a platform and in turn the WWW.

    • Ahmad Awais 9:33 am on October 28, 2015 Permalink | Log in to Reply

      It’s a new day! Excited to see how REST API helps WordPress grow as an ultimate go-to platform for all the web development needs.

    • Manny Fleurmond 11:36 am on October 28, 2015 Permalink | Log in to Reply

      Are the models/collections/etc part of this or do those come later?

    • Stephane Daury (stephdau) 2:44 pm on October 28, 2015 Permalink | Log in to Reply

      Congrats on a monumental effort by the whole team.

    • Justin Sternberg 3:56 pm on October 28, 2015 Permalink | Log in to Reply

      🎉👏🍺

    • Mahesh Waghmare 3:57 pm on October 28, 2015 Permalink | Log in to Reply

      Great….!

    • karlazz 8:33 pm on October 28, 2015 Permalink | Log in to Reply

      Congratulations!

    • Jon Brown 11:25 pm on October 28, 2015 Permalink | Log in to Reply

      A whole new world awaits… thank you to the tireless devs working on this the last couple years!

    • Scott Bolinger 4:59 pm on October 29, 2015 Permalink | Log in to Reply

      Congrats guys! Is the wp-api 1.x plugin compatible with WordPress 4.4?

      • Aaron Jorbin 6:32 pm on October 29, 2015 Permalink | Log in to Reply

        As noted in the post:

        If you’re on version 1 of the API, you won’t hit any fatal errors straight away, but endpoints will stop working with 4.4. We’re still planning on releasing a final version 1 release for compatibility, but now would be a great time to consider migrating forward to version 2. Apart from security releases, version 1 has ceased being actively maintained.

    • Ian Dunn 11:02 pm on October 30, 2015 Permalink | Log in to Reply

      We’re still planning on releasing a final version 1 release for compatibility, but now would be a great time to consider migrating forward to version 2

      I’m still not clear on the upgrade path for sites running the 1.x plugin in production. I don’t really want to start running v2 on production until it’s stable, and I also don’t want to spend a lot of time upgrading my customizations until v2 is stable, in case anything changes.

      So, if I upgrade to 4.4 and the final 1.x plugin at the same time, will everything continue working? Or, do I need to wait until v2 is stable, then upgrade my customizations to work with it, and then install 4.4?

      • Joe Hoyle 1:22 am on November 14, 2015 Permalink | Log in to Reply

        The latest version of the 1.x plugin will continue to work with 4.4 – just make sure you update the plugin when you upgrade to 4.4.

        Right now, the 1.x plugin essentially overwrites the v2 infrastructure that is in core, so that does mean that you won’t be able to take advantage of the REST API infrastructure bundled in core if you are using v1. This will be resolved in a future update however.

    • suifengtec 4:25 pm on December 17, 2015 Permalink | Log in to Reply

      Good News!

  • Rachel Baker 6:05 pm on October 23, 2015 Permalink |
    Tags: json-api, ,   

    WP REST API: Version 2.0 Beta 5 

    Version 2.0 Beta 5 “¡Ay, caramba!” of the REST API is now available. Download it from the plugin repository or from GitHub.

    This is a compatibility release with WordPress 4.4 Beta 1, and is required to use the plugin alongside WordPress 4.4.

    Here’s some highlights:

    • Load api-core as a compatibility library
    • Now api-core has been merged into WordPress trunk (for 4.4) we should no longer load the infrastructure code when it’s already available. This also fixes a fatal error for users who were on trunk.

      (props @rmccue)

    • Switch to new mysql_to_rfc3339
    • (props @rmccue)

    • Double-check term taxonomy
    • (props @rmccue)

    • Load admin functions
    • This was removed from the latest beta of WordPress in the REST API infrastructure, a more long term fix is planned.

      (props @joehoyle)

    • Add compat shim for renamed rest_mysql_to_rfc3339()
    • (props @danielbachhuber)

    • Compat shim for wp_is_numeric_array()
    • (props @danielbachhuber)

    • Revert switch to register_post_type_args filter
    • (props @joehoyle)

    We have a detailed changelog as well as the full set of changes if you’re interested.

     
  • Gary Pendergast 12:45 am on September 23, 2015 Permalink
    Tags: , json-api,   

    Committer Reviews of the REST API 

    With the proposed merge of the REST API base code into Core, I’d like to try something a little bit different. The REST API is potentially going to cause one of the biggest shifts in workflow that WordPress has seen, so it’s important that all committers know how it works, and how it affects the parts of Core that they focus on.

    And so, here’s the plan. Before the REST API is merged into Core, it needs a code review from all active committers. The code being proposed for merge has been separated out into its own repo, for your viewing convenience.

    There are five areas I’d like to see covered:

    • Docs: Are the inline docs up to standard? What needs to be done before they’re ready? Official tutorials will be helpful, can they be fit into Devhub?
    • Security: Is it secure?
    • Performance: Are there any obvious performance issues in the base code? Are we encouraging plugin developers to write performant custom end points?
    • Ease of Use: Is it easy to write custom endpoints? Do we encourage quality code?
    • Forwards Compatibility: This is a little more nebulous, but can you envisage scenarios where we might need to break backwards compatibility in the future?

    Choose one or more of these focusses for your review, and tackle it from that perspective.

    You can also have a look at the proposed endpoints in the main repo, (scheduled for a later WordPress version), for inspiration on how it may interact with the areas of WordPress Core that you work on.

    Post your review as a comment here, and link to any relevant bug reports or pull requests you submit to the plugin repo.

    And finally, please have a think about how this process worked for you. I’d like this to be a model for future feature plugin merges, particularly those that touch many different areas of WordPress Core.

    PS: I’m not kidding about all active committers. I won’t hesitate to publicly shame you for holding up the REST API merge. 🙂

     
    • Ben Tremblay 2:37 am on September 23, 2015 Permalink | Log in to Reply

      For completeness?
      http://v2.wp-api.org/

    • Boone Gorges 2:57 am on September 23, 2015 Permalink | Log in to Reply

      Just spent a while reading through the api-core repository, and cross-referencing against some of the existing endpoints. This is my first time looking at the internals of the API; my previous experience is limited to writing a couple of custom endpoints for v1.

      Overall (and unsurprisingly) it seems like things have been nicely thought out. The syntax and conventions for registering endpoints seem easy to grok (they’re very WordPressy), without sacrificing flexibility and power.

      A few notes I jotted down while reading. I’ve opted not to open issues or PRs, as some of these are more questions than anything else – both for the core team and for the API team.

      • Why are we enabling JSONP by default? Is this for compatibility with browsers that don’t support CORS?
      • Is CSRF protection left to the endpoints? What will this look like without an HTML page to transport nonces?
      • I’d argue we should consider shipping WP_Rest_Controller as part of the “infrastructure” round. It’s hard to imagine building a very useful endpoint without it.
      • The API sends custom headers for deprecated functions and arguments. Should there be a corresponding header for _doing_it_wrong() notices?
      • Your first stop for fetching request data is $HTTP_RAW_POST_DATA, with a fallback to php://input. It should probably be the other way around – the global is deprecated in PHP 5.6 and removed in PHP 7.0.
      • Should error messages in the json_last_error_msg() shim be localizable?
      • Drew will probably have more to say about this, but docs formatting is inconsistent throughout, and will need a once- or twice-over.

      Thanks to the API team for their work so far!

      • Ryan McCue 6:44 am on September 23, 2015 Permalink | Log in to Reply

        Thanks for the review @boonebgorges. 🙂

        Why are we enabling JSONP by default? Is this for compatibility with browsers that don’t support CORS?

        Correct, and compatibility with servers that don’t allow sending CORS headers, or old client libraries, or etc.

        Is CSRF protection left to the endpoints? What will this look like without an HTML page to transport nonces?

        Authentication and authorisation is handled in the infrastructure. CSRF only applies to browser-based applications using cookie authentication, and you need the wp_rest nonce for that. (This is automatically output as WP_API_Settings.nonce and handled automatically when you use the JS client.)

        I’d argue we should consider shipping WP_Rest_Controller as part of the “infrastructure” round.

        The base controller is half way between infrastructure and endpoints, but it’s possible we’ll continue changing things in it, and it’s not as stable as the infrastructure proper. Realistically, it’s just a set of best practices, so it’s definitely possible to build useful endpoints without it; I have a tonne of basic endpoints written that just use straight up functions or closures, which you don’t need a controller class for.

        The API sends custom headers for deprecated functions and arguments. Should there be a corresponding header for _doing_it_wrong() notices?

        Potentially. The deprecated stuff can be trigger from request data, whereas _doing_it_wrong() is likely only triggered by plugin code, which is why we don’t handle it currently. I’d not be against adding it though.

        Your first stop for fetching request data is $HTTP_RAW_POST_DATA, with a fallback to php://input. It should probably be the other way around – the global is deprecated in PHP 5.6 and removed in PHP 7.0.

        php://input suffers from a fatal flaw: it can only be read from once. In case other code wants to use this, or we need to reuse the data ourselves, we load it into the variable ourselves. I don’t think we can change this, alas.

        Should error messages in the json_last_error_msg() shim be localizable?

        I’d argue no, for parity with the PHP built-in/extension.

        docs formatting is inconsistent throughout

        Definitely, we need a bunch of work on this.

        Thanks again!

    • Drew Jaynes 8:15 pm on September 23, 2015 Permalink | Log in to Reply

      For posterity: I’ve opened a PR for a core docs standards audit here: https://github.com/WP-API/WP-API/pull/1590

    • Aaron Jorbin 8:13 pm on September 30, 2015 Permalink | Log in to Reply

      I haven’t finished a full review, but here are some initial things:

      WP_HTTP_ResponseInterface

      Does there really need to be an WP_HTTP_ResponseInterface interface? It feels like over abstraction for the sake of abstraction.

      — WP_REST_Server —

      Many of the constants in WP_REST_Server don’t seem to serve a purpose without endpoints. I would like to see some more inline documentation around how they are expected to be used. For example, why is ACCEPT_JSON set as 128?

      serve_request feels like a very long method compared to many of the others. It seems to handle two things, serving the request, but before that, routing the request. Could this become two different methods? One that does the setting/routing and the other that does the serving?

      A couple of other small changes I would look at:

      • Add a set_default_headers method that could be called and encompass lines 248 -255. There could also be a filter on this list to easily enable other default headers being added to every request.
      • rest_ensure_response is called on the $result on both lines 321 and 337 (in the rest_post_dispatch filter). The only change between those is that if it is an error, it goes through error_to_response which returns WP_REST_Response which doesn’t need to be ensured is a response.

      Should envelope_response be public? It seems like it only is needed in once one place and sdoesn’t need to be used outside of it.

      More to come

      • Jeremy Felt 4:44 am on October 2, 2015 Permalink | Log in to Reply

        rest_ensure_response is called on the $result on both lines 321 and 337 (in the rest_post_dispatch filter). The only change between those is that if it is an error, it goes through error_to_response which returns WP_REST_Response which doesn’t need to be ensured is a response.

        This caught me up as well when reading through `WP_Rest_Server`. I’m not sure if there’s a better way to handle it, but it is tricky when reading.

      • Rachel Baker 1:01 pm on October 2, 2015 Permalink | Log in to Reply

      • Ryan McCue 6:40 am on October 7, 2015 Permalink | Log in to Reply

        Many of the constants in WP_REST_Server don’t seem to serve a purpose without endpoints.

        These constants were leftovers from way back when we had bitwise flags. I’ve killed those now. The only constants left now are RESTful verbs (`READABLE`, `CREATABLE`, `EDITABLE`, `DELETABLE` and `ALLMETHODS`).

        Should envelope_response be public? It seems like it only is needed in once one place and sdoesn’t need to be used outside of it.

        Enveloping is super useful in third-party code, and there’s no real reason to make it protected. I’d like to keep it as part of the class’ public API. 🙂

        Working on the rest of the feedback.

    • Drew Jaynes 8:15 pm on September 30, 2015 Permalink | Log in to Reply

      I noted this to Rachel separately, but good to have it mentioned here:

      The wp-api.js file should be renamed to wp-rest-api.js, and the handle changed to ‘wp-rest-api’ or ‘rest-api’. In the broader scheme of WordPress, this is another of many APIs, not the WordPress API any longer 🙂

    • Dominik Schilling (ocean90) 8:16 pm on September 30, 2015 Permalink | Log in to Reply

      WP_HTTP_ResponseInterface – Do we need it? If it gets released once there is no way to extend it without potentially breaking plugins which are using this class.

      • Rachel Baker 12:59 pm on October 2, 2015 Permalink | Log in to Reply

        I chatted with @rmccue, who first introduced WP_HTTP_ResonseInterface (or as previously named WP_JSON_ResponseInterface) on Feb 17, 2014, and he **believes** it can be removed. He has to do some testing to confirm this theory.
        If we can remove it, we will. Otherwise @rmccue will provide the reasoning behind needing to keep it.

    • Weston Ruter 10:46 pm on September 30, 2015 Permalink | Log in to Reply

    • Rachel Baker 2:10 pm on October 2, 2015 Permalink | Log in to Reply

      We have a patch up in https://core.trac.wordpress.org/ticket/33982 that can be refreshed, if committers have any desired code changes.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar