WordPress.org

Make WordPress Core

Tagged: json-api Toggle Comment Threads | Keyboard Shortcuts

  • Ryan McCue 4:39 am on April 4, 2016 Permalink |
    Tags: json-api,   

    WP REST API: 2.0 Beta 13 & Roadmap 

    Hi folks! I’m here with another exciting update from the API team.

    Beta 13

    First off, we’re excited to announce 2.0 Beta 13 “yoink.adios\losers” is now available. Grab it from the plugins repo or GitHub while it’s hot. Here’s some of the key updates:

    • BREAKING CHANGE: Fix Content-Disposition header parsing. This technically breaks backwards compatibility to correctly match the header specification. (#2239)

    • BREAKING CHANGE: Use compact links for embedded responses if they are available. We now use CURIEs for sites on 4.5+, which look like wp:term (but canonicalise to the full URI relation). (#2412)

    • Updated JS client to the latest version. (#2403)

    There’s lots more changes in this release; check out the release notes or the commits for this release.

    Roadmap

    We’ve been thinking about how to tackle the API in the coming future. We want to do the most we can to ensure you can build sites with confidence.

    Along these lines, we’re going to release a 2.0 final version in the coming months. This will be a completely stable release with guaranteed backwards compatibility for the foreseeable future. This backwards compatibility ensures that your sites can remain up-to-date with minimal maintenance or issues with upgrading.

    We originally held the software in beta for a long period to ensure that breaking changes could be rolled in if deemed necessary to move the project forward. However, the majority of these breaks occurred at the start of the 2.0 lifecycle, and the API is mostly stable at this point. Keeping the ability to break compatibility benefits only us, whereas moving to a stable release benefits everyone.

    Moving forward, version 2.0 of the WP REST API will follow a normal project release cycle. We will have minor releases in the 2.x series as new features are added, and bugfix releases in the 2.0.x series.

    As for the core merge itself, we are not submitting a merge proposal of the core endpoints for WordPress 4.6. We believe endpoints for the main WordPress objects (posts, users, comments, terms, and taxonomies) are not enough to garner the support needed for the proposal to be accepted. Our hope is that with a stable version 2.0 release, we will attract our community members that have been waiting for the endpoints to be available in core, and submit a merge proposal for the WordPress 4.7 release cycle.

    In addition to attracting more developers within our community, we are also looking to get more contributors involved with the project. As noted in previous discussions, the four of us on the API team can’t keep pace with WordPress itself without help. We’re looking to get WordPress core component maintainers involved in their relevant components, as well as new developers from outside the project. Moving forward, the API team sees our role as advisory over the API itself, with the API treated as an integral part of the component rather than maintained by a separate team. We’re also going to continue to work on our feature plugins (metadata, site/multisite, menus/widgets, and authentication) in parallel, and are looking for help on these as well. (There’s also more news regarding authentication coming very soon.)

    If you’d like to get involved with the API, please let us know. You can comment here, ping us on Slack in the #core-restapi room, or via GitHub issues. We’re looking at spending significant time onboarding new users, so if you’d like to get involved, now’s the time! Our weekly meeting is at Monday 23:00 UTC

    Thanks for catching up with us, and have a wonderful day.

    With love,

    Ryan, Rachel, Daniel, and Joe

     
    • adamf321 4:19 pm on April 4, 2016 Permalink | Log in to Reply

      Hey guys,
      Firstly thanks for all the great work you’ve been producing on the API! I’m the CTO of a digital agency and we’re working on a new infrastructure which relies heavily on it. I would like for us to be involved in some part in the ongoing development of the API – so please keep me up to date with the onboarding process and I will ask who in our team is interested. We have dev and design resources. To give you an early heads-up, this month is pretty hectic, but from next month I think we can make some time to get started.

      Cheers,
      Adam

    • Mike Nelson 4:40 pm on April 4, 2016 Permalink | Log in to Reply

      +1 to 2.0 stable. If we really really really want to make breaking changes in the future it can always be on a 3.0 version. For now it’s nice having something stable.

      And I’m at least interested in helping out with the basic auth plugin

    • nathangraham 10:25 pm on April 14, 2016 Permalink | Log in to Reply

      We rely heavily on the REST API as well so thanks for all of your work. I’m happy to contribute as well.

  • Daniel Bachhuber 4:50 pm on February 9, 2016 Permalink
    Tags: , json-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

     
    • Joshua David Nelson 7:38 pm on February 9, 2016 Permalink | Log in to Reply

      I feel compelled to end debate of the chicken and egg. The answer is egg. The egg came first, from which a chicken would be born as a mutated version of the chicken’s previous ancestor. That’s how evolution works. Speaking of which, it’s great to be tracking the evolution of the REST API – thanks for the update and hard work!

  • 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 12:00 am on January 26, 2016 Permalink
    Tags: , json-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.

     
  • 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.

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