WordPress.org

Make WordPress Core

Updates from Ryan McCue Toggle Comment Threads | Keyboard Shortcuts

  • Ryan McCue 9:23 pm on April 6, 2016 Permalink |
    Tags: , ,   

    REST API: Slashed Data in WordPress 4.4 and 4.5 

    Hi everyone. The REST API team recently discovered a bug with parameter parsing in the API infrastructure, part of WordPress 4.4. For those of you using the API infrastructure, you need to be aware of a bug fix we’re making with the API.

    The Problem

    The REST API has several types of parameters that it mixes together. These come from several sources including the request body as either JSON or URL-encoded form data ($_POST), query parameters ($_GET), the API route, and internally-set defaults. Unfortunately, due to an oversight on our behalf, these parameters can be inconsistently formatted.

    In WordPress, the superglobal request variables ($_POST and $_GET) are “slashed”; effectively, turning magic quotes on for everyone. This was originally built into PHP as a feature to help guard against SQL injection, but was later removed. Due to compatibility concerns, WP cannot change this behaviour for the superglobals. This only applies to the PHP superglobals, not to other sources of input like a JSON body or parameters in the URL. It additionally does not apply to form data on PUT or DELETE requests.

    Internally, some low-level WordPress functions expect slashed data. These functions internally call wp_unslash() on the data you pass in. This means input data from the superglobals can be passed in directly, but other data needs to be wrapped with a call to wp_slash().

    When the REST API gathers the data sources, it accidentally mixes slashed and unslashed sources. This results in inconsistent behaviour of parameters based on their source. For example, data passed as a JSON body is unslashed, whereas data passed via form data in the body is slashed (for POST requests).

    For example, the following two pieces of data are equivalent in the REST API:

    
    // JSON body:
    {"title": "Foo"}
    
    // Form-data ($_POST)
    title=Foo
    
    // Both result in:
    $request->get_param('title') === 'Foo';
    

    However, if the data contains slashes itself, this will be inconsistently passed to the callback:

    
    // JSON body:
    {"title": "Foo\Bar"}
    
    // Results in:
    $request->get_param('title') === 'Foo\Bar';
    
    // Form-data ($_POST) (%3D = "\")
    title=Foo%3DBar
    
    // Results in:
    $request->get_param('title') === 'Foo\\Bar';
    

    This means that callbacks need to understand where parameters come from in order to consistently handle them internally. Specifically:

    • Data passed in the query string ($_GET, $request->get_query_params()) is slashed
    • Data passed in the body as form-encoded ($_POST, $request->get_body_params()) is slashed for POST requests, and unslashed for PUT and DELETE requests.
    • Data passed in the body as JSON-encoded ($request->get_json_params()) is unslashed.
    • Data passed in the URL ($request->get_url_params()) is unslashed.
    • Data passed as a default ($request->get_default_params()) is unslashed.

    In addition, parameters set internally via $request->set_param() are unslashed. Unit and integration tests for API endpoints typically use these directly, so the majority of tested code (such as the WP REST API plugin) assumes parameters are unslashed.

    See the related Trac Ticket #36419 for more information.

    The Solution for WordPress 4.4 and 4.5

    We are regarding inconsistently-slashed data as a major bug, and are changing the API infrastructure to ensure unslashed data. This will ensure that data is consistent regardless of the source. Callbacks will now receive unslashed data only, and can rely on this regardless of the original data source or request method.

    If you are using functions that expect slashed data in your callback, you will need to slash your data before passing into these functions. Commonly used functions that expect slashed data are wp_insert_post, wp_update_post, update_post_meta, wp_insert_term, wp_insert_user, along with others. Before passing data into these functions, you must call wp_slash() on your data.

    The fix for this issue, will be included in the WordPress 4.5 release candidates and final release. Due to the severity of the bug, we are also backporting the fix to the next minor WordPress 4.4 update. This also ensures you can update your plugins can act consistently across all versions of the REST API.

    We understand that this may inadvertently break some plugins that are expecting slashed data. Right now, it’s not possible to consistently ensure that callbacks receive slashed data, so it is likely that these plugins will already break in some conditions.

    tl;dr: if you’re using wp_insert_* or *_post_meta in your REST API callback, you need to ensure you are calling wp_slash() on data you are passing in, regardless of source.

    We apologize for this bug existing in the first place. Slashed data is a problem that has plagued WordPress for a long time, and we’re not immune to getting caught by the issue ourselves.

     
    • Mike Schinkel 7:16 am on April 7, 2016 Permalink | Log in to Reply

      We apologize for this bug existing in the first place. Slashed data is a problem that has plagued WordPress for a long time, and weโ€™re not immune to getting caught by the issue ourselves.

      Given that this issue created such a major bug, wouldn’t it be a good time to take backward compatible action to slowing start eliminating this as an issue?

      • Mike Schinkel 7:35 am on April 7, 2016 Permalink | Log in to Reply

        In case of interest in addressing this moving forward:

      • Ryan McCue 3:40 am on April 8, 2016 Permalink | Log in to Reply

        As it happens, this is part of my Secret Master Plan for Unslashing, and part of why I wanted to ensure we fixed this right now.

        My Secret Master Plan:

        • Take the generic parts of WP_REST_Request and make a new WP_HTTP_Request object
        • Ensure the Request object has unslashed data
        • Pass the Request around liberally to replace the superglobals (discussed somewhat in #36292)
        • Finally introduce internals that take unslashed data, and turn the existing functions into wrapper functions.
    • NateWr 7:54 am on April 7, 2016 Permalink | Log in to Reply

      Is this change in the latest WP 4.5 RC or do we need to get the latest commits to test our apps?

      • Marius (Clorith) 12:56 pm on April 7, 2016 Permalink | Log in to Reply

        It is not available in RC-1, that’s out at this time, as it was pushed in last evening/earlier today (depending on your time zones), the goal is to get RC-2 out some time this week, and it will include this change.

        If you are running trunk you’ll have access to it at this time, alternatively you can manually apply the patch to your own install if you wish to start testing it right away (the patch from #36419)

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

    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.

  • Ryan McCue 12:35 am on December 15, 2015 Permalink  

    WP REST API: OAuth Plugin Security Update 

    Hi everyone. This is a quick update on the OAuth 1.0a Server plugin, available on GitHub.

    Versions of the OAuth plugin prior to this commit contain a security issue during the authorization flow, regarding signature and nonce checks. Due to the OAuth architecture, it is highly unlikely this can be used to compromise a site or client application; however due to an abundance of caution, we recommend all users update to 0.2.1 immediately. (Pull the latest changes from master.)

    Thanks to @bradyvercher for responsible disclosure of this issue via HackerOne.

     
    • AITpro 12:54 am on December 15, 2015 Permalink | Log in to Reply

      Wow! HackerOne is awesome! What an absolutely brilliant idea. I will definitely be signing up.

  • Ryan McCue 9:52 am on December 7, 2015 Permalink
    Tags: , ,   

    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. ๐Ÿ™‚

  • Ryan McCue 1:27 am on November 18, 2015 Permalink
    Tags:   

    WordPress Importer Redux 

    Hi, I’m Ryan McCue. You may remember me from such projects as the REST API.

    I’m here today to talk about something a bit different: the WordPress Importer. The WordPress Importer is key to a tonne of different workflows, and is one of the most used plugins on the repo.

    Unfortunately, the Importer is also a bit unloved. After getting immensely frustrated at the Importer, I figured it was probably time we throw some attention at it. I’ve been working on fixing this with a new and improved Importer!

    If you’re interested in checking out this new version of the Importer, grab it from GitHub. It’s still some way from release, but the vast majority of functionality is already in place. The plan is to eventually replace the existing Importer with this new version.

    The key to these Importer improvements is rewriting the core processing, taking experience with the current Importer and building to fix those specific problems. This means fixing and improving a whole raft of problems:

    • Way less memory usage: Testing shows memory usage to import a 41MB WXR file is down from 132MB to 19MB (less than half the actual file size!). This means no more splitting files just to get them to import!
    • Faster parser: By using a streaming XML parser, we process data as we go, which is much more scalable than the current approach. Content can begin being imported as soon as the file is read, rather than waiting for pre-processing.
    • Resumable parsing: By storing more in the database instead of variables, we can quit and resume imports on-the-go.
    • Partial imports: Rethinking the deduplication approach allows better partial imports, such as when you’re updating a production site from staging.
    • Better CLI: Treating the CLI as a first-class citizen means a better experience for those doing imports on a daily basis, and better code quality and reusability.

    Curious as to how all of this is done? Read on!

    (More …)

     
    • pavot 1:36 am on November 18, 2015 Permalink | Log in to Reply

      I can’t express how happy I am about this progress!
      Thank you very much.

    • Jon Brown 1:54 am on November 18, 2015 Permalink | Log in to Reply

      Ditto. This is awesome. Having spent a lot of hours last weekend trying to debug a massive wp.com WXR/XML export (split in over 20 parts and failing on files 14-16)… this is so timely. Looking forward to testing it.

      Curious if the pull parser works with a folder full of xml files the way the WP importer did? Since as I said above, what .com dumped was a couple dozen xml files and I don’t have a convenient way to glue them back together.

      Huge thank you for attending to a long neglected corner of WordPress!

      • Ryan McCue 1:56 am on November 18, 2015 Permalink | Log in to Reply

        Curious if the pull parser works with a folder full of xml files the way the WP importer did?

        You should be able to work with split files by just importing them one after another. (You should also be able to import them in any order, theoretically.) This is something I haven’t put a lot of testing into yet though, so give it a shot and let me know!

        In the future, hopefully we’ll never need to split files again. ๐Ÿ™‚

      • Brent Toderash 6:05 am on November 19, 2015 Permalink | Log in to Reply

        If you’re up for an adventure, on the command line you could do something like

        cat $(ls *.xml -t) > complete.xml

        to stitch the files back together in date order, then try importing the whole thing at once ๐Ÿ™‚

    • Sakin Shrestha 2:12 am on November 18, 2015 Permalink | Log in to Reply

      Wow this is awesome… Thanks a lot ๐Ÿ™‚

    • nicholas_io 2:13 am on November 18, 2015 Permalink | Log in to Reply

      This is Awesome! The WordPress importer as it currently stands is far from being good. I’ll be happy testing it out

    • Mike 2:20 am on November 18, 2015 Permalink | Log in to Reply

      Great stuff Ryan. Really nice performance improvements. I’ve often ran into memory limits during import.

      As an aside, has there been discussion around offline import, most specifically around media items? Such a possibility would allow for sites to be exported wholly together with all of their content items and either kept for archive or imported more easily. Such a site could have been mocked up on an unreachable development server.

      • Ryan McCue 2:24 am on November 18, 2015 Permalink | Log in to Reply

        Thanks Mike!

        We have an issue filed for that one. Deferring the actual images getting imported will get a few gains: offline imports, parallel downloads, or static content imports (i.e. image files in a zip).

        You can pass 'fetch_attachments' => false (also the default internally, but not in the CLI) into the importer class in __construct for this already. ๐Ÿ™‚

    • Ryan Markel 2:25 am on November 18, 2015 Permalink | Log in to Reply

      Hey, Ryan.

      This is other Ryan. ๐Ÿ™‚ We’ve been dealing with super-large imports on WordPress.com VIP for some time now and I’ve been dealing with them for a year-plus. I’d love to chat with you at some point about the kinds of things we have run into in these large imports and in other things that are edgier-case like site merges and other things that the import currently can struggle with.

      Some of what we are doing on WordPress.com is almost certainly not practical for movement to core, but we can probably provide some valuable insight on larger imports and problems that are encountered there.

      • Ryan McCue 2:49 am on November 18, 2015 Permalink | Log in to Reply

        Hey other Ryan! Let’s chat; one of the big use cases that lead to me rewriting this was huge VIP-level imports, so it’s definitely something I’m conscious of. I’d love to have your and VIP’s feedback ๐Ÿ™‚

    • Ipstenu (Mika Epstein) 2:43 am on November 18, 2015 Permalink | Log in to Reply

      This will be a game changer for the many people who want to export from wordpress.com and import to self-hosted where they either can’t afford or aren’t able to use the migration package.

      You, sir, deserve all the pizza bites.

    • Matthew Eppelsheimer 3:15 am on November 18, 2015 Permalink | Log in to Reply

      This is so, so, great Ryan!

      Looking forward to testing this and seeing if our pet bugs in the 0.6 importer to fix “someday” still exist. I’ll bet notโ€ฆ

    • JakePT 3:38 am on November 18, 2015 Permalink | Log in to Reply

      My biggest frustration is the inability to import Posts only and import images at the same time. Images only come across if the entire site is exported. This is very annoying when trying to transfer a client’s blog between sites without bringing across menus and random plugin post types. I can understand the challenge since they’re only img tags and not necessarily attached to the post, but it’s definitely my biggest hangup with the importer.

    • bishless 4:59 am on November 18, 2015 Permalink | Log in to Reply

      This is great news! Thanks for your work, Ryan!

    • jeffmcneill 5:43 am on November 18, 2015 Permalink | Log in to Reply

      I’ve run into a ton of problems with importing, usually a memory or parsing issue. I’ve had to eject a lot of content from several site migrations because of this. That you are working on this critical tool for WordPress means you should be applauded, and lauded. Thank you!

    • DeBAAT 6:26 am on November 18, 2015 Permalink | Log in to Reply

      Reading the responses, you’ve definitely hit a soft spot!
      Thanks already for picking this challenge.

      I myself did have some issues with the importer lately as I was migrating some content from dev to prod.
      And this actually had to do with the GUID, so please take real good care to using this.
      I mean, a post developed on site x.dev typically has x.dev in the guid. When I try to import it into x.com, I would like to have an option whether or not to ‘translate’ the GUID from x.dev to x.com.

      The same goes for the GUID of an image. In some cases, the image may have been uploaded already in the x.com site before. So how do you discriminate between the two images?
      Hope you’ll get it working nicely.

      Reading your article, I thought you mentioned something about changing the exporter as well. I’m not sure however, so are there any plans to work on the exporter as well?

      • Ryan McCue 6:47 am on November 18, 2015 Permalink | Log in to Reply

        The main thing with the GUID is that it shouldn’t ever change. The new importer actually uses it more, so if you change the GUIDs, later imports will reimport the same data again. That said, @westonruter‘s pull request would let you write complex logic to map this back and forth, and I do know it’s a common use case. Happy to discuss further on a GH issue ๐Ÿ™‚

        Specifically on images, there’s a flag in the options in the new importer called update_attachment_guids – the old importer always changes the GUID to the new filename, but this rewrite avoids that by default, as it makes deduplication on future imports impossible. (The reason the old importer did this is because originally the GUID contained the filename, so that’s occasionally used by older code to find the image URL.)

        There’s no real plans to change the exporter right now, but if it turns out we can improve import efficiency by changing data in exports (i.e. avoid post-processing by being careful about the element order), we’ll likely do that.

        Thanks for the feedback!

    • Ahmad Awais 6:38 am on November 18, 2015 Permalink | Log in to Reply

      I’ve had my fair share of WTF Momentsโ„ข with WordPress importer. So, believe me when I say this, I am glad someone is finally working on improving that. It’s a great news. Going to test it this weekend.

    • Sam Hotchkiss 6:51 am on November 18, 2015 Permalink | Log in to Reply

      You’re amazing, Ryan, well done.

    • Per Soderlind 6:53 am on November 18, 2015 Permalink | Log in to Reply

      Excellent Ryan, can’t wait to test it ๐Ÿ™‚

    • Dreb Bits 7:30 am on November 18, 2015 Permalink | Log in to Reply

      Truly amazing! Will find time this weekend to test this baby! And thanks a lot initiating the movement to improve the WordPress importer ๐Ÿ™‚

    • Ajay 7:52 am on November 18, 2015 Permalink | Log in to Reply

      This is awesome news. It’s been a long time coming. Are you planning to update the Exporter as well?

      • Ryan McCue 7:54 am on November 18, 2015 Permalink | Log in to Reply

        No major plans there yet, but if there’s improvements to be made there, I’ll be sure to take a look. ๐Ÿ™‚

    • Morten Rand-Hendriksen 8:00 am on November 18, 2015 Permalink | Log in to Reply

      Thank you Ryan. This is a sorely needed upgrade.

    • connectr 8:22 am on November 18, 2015 Permalink | Log in to Reply

      Ooh, goodie! It always baffled me why such an important tool received so little love. The GSoC project looked hopeful, but then not much came from it. Super duper happy it’s back on the radar ๐Ÿ™‚

    • Mario Peshev 8:37 am on November 18, 2015 Permalink | Log in to Reply

      Thanks for the great work Ryan – given the state of the original Importer for years now, that’s incredible news.

    • Omaar Osmaan 8:38 am on November 18, 2015 Permalink | Log in to Reply

      So excited about this- ๐Ÿ˜€

    • dimitris33 9:42 am on November 18, 2015 Permalink | Log in to Reply

      Great news Thanks!

    • capuderg 10:10 am on November 18, 2015 Permalink | Log in to Reply

      Great!!! So excited! Thanks Ryan for working on this!

    • Tran Ngoc Tuan Anh 10:36 am on November 18, 2015 Permalink | Log in to Reply

      This is a great news.

      I’m wondering about media import. Some themes use licenced images and don’t want to import, they usually are replaced by dummy image as a placeholder. Can we do that (maybe with a filter) with this new importer?

      Also, would it help in importing theme mods?

      • Ryan McCue 10:39 am on November 18, 2015 Permalink | Log in to Reply

        You can filter `wxr_importer.pre_process.post`, which gets passed the full post data, and go ahead and change anything in there. ๐Ÿ™‚

        I’m not sure what the current state of theme mods is in the export data, so I can’t speak to that, but file an issue and I can take a look. ๐Ÿ™‚

    • Primoz Cigler 10:42 am on November 18, 2015 Permalink | Log in to Reply

      Wow, incredible! Just awesome Ryan. It is clear from responses here that this was a huge pain for many people.

      Something came to my mind when I was reading this, I am not sure if it will be relevant, but still worth mentioning: would it be possible to utilize the REST API and switch to JSON instead? I believe it would make for much cleaner approach, as I was always struggling with any XML files, while JSON is so human-readable? I believe the import/export would be possible without the XML file at all, only import WP calling the export WP over the JSON calls.

      I would love to hear the feedback on my thinking and if that is something that should be considered in the future when migrating content over the web, as it sounds much leaner approach ๐Ÿ™‚

      • Ryan McCue 10:48 am on November 18, 2015 Permalink | Log in to Reply

        As the lead developer of the API, I’m conscious of this. ๐Ÿ˜‰

        There’s a number of reasons it’s better to stick with WXR/XML right now:

        • PHP has a streaming XML parser built-in, but it doesn’t have a streaming JSON parser out of the box. This means any streaming parsing would need to take place in userland (i.e. a library), which I suspect would cause performance to be worse.
        • WXR is compatible with RSS, which means the export format can be imported by a lot of other tools, not just WP. Switching to our own format might have benefits to us, but it would likely harm the wider ecosystem.
        • XML isn’t really a problem most of the time. It’s not the greatest format ever invented, but it’s reasonably readable, and there’s tonnes of tooling around it.

        With that said, if somebody wanted to try it, it’d be interesting to see at the least. ๐Ÿ™‚ The XML parsing in this new version of the importer is contained in a few small methods, so you could probably swap that out for JSON reasonably easily.

        • Primoz Cigler 10:52 am on November 18, 2015 Permalink | Log in to Reply

          Gotcha, thank you for your swift reply!

          I don’t promise anything, but I might actually try to implement the REST API way. I will give you heads-up if I do.

    • sonjanyc 11:23 am on November 18, 2015 Permalink | Log in to Reply

      This is amazing, Ryan!! You will make so many people so very happy with this, me included!! ๐Ÿ™‚

    • Alvaro Gois dos Santos 11:28 am on November 18, 2015 Permalink | Log in to Reply

      Wow. Awesome @rmccue, thanks!

      Let’s try that importerโ€ฆ

    • Damian 12:55 pm on November 18, 2015 Permalink | Log in to Reply

      Thanks Ryan, this is problem we all faced at some point. My concern is the exporter now. It will be also updated ? Currently how the exporter work is primitive. Eg: You can’t export featured images if you just export posts, you need to export the whole content.

      Or if you want to export just taxonomies becuase you have lots of them and you want to duplicate them in a new site.

      Thanks again!

      • Ryan McCue 1:35 pm on November 18, 2015 Permalink | Log in to Reply

        Right now, I don’t have any plans to work on the exporter (unless there’s performance gains to be had for the importer there), however there’s a few tickets already on that: #27048 and #17379 are the two most relevant here I think.

        At the end of the day, these things just need someone to sit down and spend some time on them. ๐Ÿ™‚

    • Rich Tabor 1:32 pm on November 18, 2015 Permalink | Log in to Reply

      Really glad this is happening!

    • Josh Eaton 2:57 pm on November 18, 2015 Permalink | Log in to Reply

      Wait, so you’re saying I no longer need 8GB of RAM in my local VM just to import a WXR file? ๐ŸŽ‰

    • Steven Gliebe 3:21 pm on November 18, 2015 Permalink | Log in to Reply

      This is music to my hears. Thank you for working on this!

    • Ben Doherty (Oomph, Inc) 5:33 pm on November 18, 2015 Permalink | Log in to Reply

      This is great, I’m very excited to see this development. I wonder if parallelization is also something that’s been considered, as PHP is just SLOW when walking through large files, and I found that parallelization can greatly improve overall import times, especially when munging XML files. My quick elevator pitch is that the importer spins off M processes, 1..N, each of which imports every M+Nth post from the file in parallel, and then the post-cleanup operation (translating URLs, IDs, etc) runs when all of the processes have completed.

      • Ryan McCue 11:55 am on November 19, 2015 Permalink | Log in to Reply

        Parallelisation is definitely something in my mind, but given the complex way that the object cache and database interact in concurrent requests (i.e. concurrent saves break basically everything in WP), not something I’ve put a huge amount of time into. ๐Ÿ™‚

        I’d love to see someone have a go at it though! The new importer should let you build this as a plugin on top reasonably easily, so if you want to try it… ๐Ÿ˜‰

    • pathartl 6:12 pm on November 18, 2015 Permalink | Log in to Reply

      A much needed update. I opened up #30887 a while ago when I first noticed the GUID issue, in case you wanted another ticket to close :). Great work as always.

    • Shmoo 2:26 am on November 19, 2015 Permalink | Log in to Reply

      Ryan should get a WordPress company sports car for doing this! ๐Ÿš— ๐Ÿ’จ vroom vroom..

      Can’t wait to test this.. Did you the WP Importer yesterday -10MB file #drama

    • lepardman 9:00 am on November 19, 2015 Permalink | Log in to Reply

      Awesome! Just a thought: it would be nice to have the ability to remap post types (maybe even taxonomies?) on import.

      Example: yesterday I was trying to import posts from an old site to a new one I’m working on. The site was so old that the developers used posts as a way to store the clients products and their actual news posts were just added as text to a huge list in the editor on a page. Some years after, a new developer added a new post type called news since post were “taken”. So I figured that I at least could do an export of the lastest news and the products. Then import them and switch post types, news as post and the products (old post type post) into a new post type called products. But that wasn’t possible, I just got and error that the post type news didn’t exist and the import failed.

      TL;DR: I couldn’t remap posts on import to other (nowadays more correct) post types. A nice way would be to be able to assign them to post type(s) just as you can change author (I guess a bulk option would be needed). I’m unsure if this would be possible but I’m throwing out the idea and then let’s hear what you guys say.

      (I guess I could do a search and replace in the xml files or create the correspondent post type temporarily, import and then do a search and replace in db but it would be so much nicer to have this built in)

      Thank you!

    • chzumbrunnen 3:14 pm on November 19, 2015 Permalink | Log in to Reply

      Wow, Ryan, that sounds great. When I understand you right my biggest question is already somehow fixed.
      Normally for an import the old site hast to be still reachable to get the images. Now with the new importer it should be possible to import images manually. But I’d like to go one step further and be able to enter the path to the images folder from where the images should be imported.

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

        The tooling around this stuff will need some time to develop and mature, but I’d also love to have that eventually ๐Ÿ™‚ Right now, should be technically possible, but just a pain to do so.

    • DoodleDogCody 3:56 pm on November 19, 2015 Permalink | Log in to Reply

      In regards to Media. I have noticed that with the current importer media items are not imported unless we select export all from the exporter. This seems a little odd to me. Media items should be imported if they exists in a post, page, or whatever post type that we export as media items are not thought of as a seperate psot type to most people. I know that’s how they are stored in the database but If I am building a new site for a client and need to export and import only their posts on the current site. I want to click export post and choose the date range of all. Then when I import I expect the images to import as well.

    • Ella Iseulde Van Dorpe 5:23 pm on November 19, 2015 Permalink | Log in to Reply

      โค๏ธ

    • Samuel Wood (Otto) 12:33 am on November 20, 2015 Permalink | Log in to Reply

      Awesome. I’m gonna steal your XML code. ๐Ÿ™‚

    • Michael Ecklund 8:02 pm on November 20, 2015 Permalink | Log in to Reply

      Thank you for taking the time to update the importer. It’s been begging for attention for quite some time.

    • RobbyMcCullough 7:42 pm on November 25, 2015 Permalink | Log in to Reply

      This is great news. Thanks, Ryan. Really excited to hear about this project.

    • Caleb Evans 1:06 am on November 29, 2015 Permalink | Log in to Reply

      Hey, @rmccueโ€”very happy to hear that the Importer is getting some much-needed love. Do you have any plans to get the Importer merged into Core, or will it remain a separate plugin? I find it somewhat counterintuitive that WordPress can export its own content out of the box, but cannot import that exported content without a separate plugin. It’s not too big of a dealโ€”just one less plugin to install for new installationsโ€”but it’s certainly something that would be nice to have, and it seems like the sensible thing to do.

    • pipdig 7:04 pm on November 29, 2015 Permalink | Log in to Reply

      Ryan, you have been added to my Christmas card list!

    • Caleb Evans 4:23 am on November 30, 2015 Permalink | Log in to Reply

      Hi, @rmccue. This all looks great, and it has me very excited. Out of curiosity, do you have any plans on trying to get this merged into Core? I find it strange that WordPress can export its own content, yet it cannot import that same exported content without a plugin. Thoughts?

      • Ryan McCue 4:27 am on November 30, 2015 Permalink | Log in to Reply

        No plans right now to integrate this into core. I think it makes more sense as a plugin personally. The export being built-in is fundamentally about your data being portable and free to access, whereas the importer doesn’t really affect data portability or freedom. Plus, having it as a plugin means we can improve it faster ๐Ÿ™‚

        (That said, others may disagree, so might be something to discuss further!)

    • Tevya 7:19 pm on January 13, 2016 Permalink | Log in to Reply

      So what’s the status on this currently? Is it ready for general use? We’ve been having the old importer fail to bring over images and media, even though the box is checked. Hoping this can save us.

    • helmar 6:34 am on February 13, 2016 Permalink | Log in to Reply

      Sounds super promising. Hope to read more about this soon, even have something to work with. If financial support is needed, I’m in.

    • birdrockdesigns 9:39 am on March 9, 2016 Permalink | Log in to Reply

      I’m really, really hoping you will be successful with the repo.

  • Ryan McCue 6:30 am on October 28, 2015 Permalink
    Tags: , , ,   

    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!

  • Ryan McCue 1:03 am on September 21, 2015 Permalink
    Tags: , , , ,   

    WP REST API: Merge Proposal 

    Hello everyone! This is the post you’ve all been waiting for. ๐Ÿ™‚

    We on the REST API team (myself, @rachelbaker, @joehoyle, @danielbachhuber, and newest member and core committer @pento) would like to propose merging the REST API into WordPress core. We’ve been working a while on this, and think it’s now ready to get your feedback.

    This is our first iteration of the proposal, and we’re actively looking for feedback. If you have thoughts on the project, or on this proposal, let us know! Only with your feedback can we make progress. ๐Ÿ™‚

    What is the REST API?

    The REST API is a nice and easy way to get at your data in WordPress externally, whether that’s from JavaScript in a theme or plugin, mobile and desktop applications, or importing and exporting data. The API offers up all core data types (posts, terms comments, and users), plus support for meta and revisions; we’ve got plans to eventually have access to everything the admin and frontend have access to.

    The REST API differs from existing WordPress APIs in that it is explicitly designed from the ground up for modern mobile and browser usage, using the lightweight and widely-supported JSON data serialization format with a modern REST interface. Both of these are already familiar to most developers: JSON is a subset of JavaScript intended purely as a data interchange format, and REST is a set of best practices around HTTP. Both are supported natively by almost every programming language and platform.

    Why do we need a new API?

    WordPress already has external APIs: XML-RPC, designed for desktop clients; Atom and RSS feeds, designed for post syndication; and the venerable admin-ajax, designed for Ajax requests in the admin and frontend. These APIs all serve different purposes, but often have a great deal of overlap. In addition, these have all been stretched beyond their original intentions: XML-RPC now contains site management tools, RSS has been extended into the WXR export format, and admin-ajax is the catch-all of any sort of browser-server communication in plugins and themes.

    The REST API builds upon the heritage of these APIs to provide better support today for using these, as well as laying the groundwork for expanded use in the future.

    XML-RPC is the closest analogue to the REST API in terms of usage and capabilities. Originally designed back in 1998 to allow desktop clients to create and edit posts on blogs, WordPress has extended this with both other specifications (such as MetaWeblog) and with its own proprietary additions. Fundamentally, XML-RPC is built around Remote Procedure Calls (RPC), essentially a way of calling a function externally. It then uses XML to serialize the data for passing back and forth.

    Unfortunately, XML serialization can be problematic at times. XML has lots of power, but support for custom entities and DOCTYPEs can cause parsing problems and security attacks, including billion laughs, and XXE exploits. (Currently, WordPress has to disable parts of the XML parser and apply regular expression replacements to be able to parse these safely.) XML is also very verbose, and represents data in a way which doesn’t map easily to programmatic data structures. JSON on the other hand is both concise and well-represented in memory, as it’s based on JavaScript’s native syntax.

    The admin-ajax API is also very commonly used in WordPress, albeit typically only by plugins and themes. This is a very lightweight API that essentially acts as a mini-router. Typical usage of this API uses JSON, since it’s a browser-based API, but all usage is completely custom. A lot of the usage of this involves retrieving or updating posts on-the-fly, but due to its nature as simply a framework, these are done in completely different ways. This doesn’t lead itself to extensibility, and requires a lot of duplication every time developers want to get data in or out. We don’t want to replace all of admin-ajax though, since some use cases don’t map exactly: UI-related interactions or things like the Heartbeat API are great examples of this.

    The REST API can help to supplant these uses. Our aim is to eventually replace the XML-RPC API completely, to act as a secondary import/export format, and to replace most (but not all) uses of admin-ajax. The REST API offers an easier to use interface than the existing solutions.

    Why this project?

    We’ve been working on this project ever since the first WordPress Contributor Summit back in 2012. Since then, we’ve had lots of feedback from core developers, the community at large, and further beyond in the form of client developers. We believe that the REST API has an immense amount of experience behind it, and plenty of viewpoints have contributed to the project’s direction.

    The API has seen great usage in the community, from various mobile apps to large news sites. This usage has helped to battle-test and prove out the API. In the process, we’ve found plenty of bugs, and some security issues. Thanks to this feedback, the API is incredibly stable and secure. (The most recent security bugs we fixed were relatively minor bugs.)

    We also designed the API from the ground-up to be part of core, following a core-like mentality to our processes. The API is intended to be both a great feature and a base to build off in plugins. We undertook a significant refactoring and partial rewrite in version 2 to make this extensibility even better. This open process also means that most of the design decisions are documented publicly as we’ve engaged stakeholders to gauge feedback.

    We believe these pieces combined make this a fantastic feature for WordPress core, and we hope you all agree. ๐Ÿ™‚

    What’s the plan?

    The plan we’re aiming for is a two part merge of the API. For the first stage, the infrastructure code would be merged into wp-includes and made available for plugins and themes. This is an internal API only, but offers an “API construction kit” for developers to use. For the second stage, the endpoints would be merged, and the API would be enabled for sites by default.

    This plan splits the API into two parts, infrastructure and endpoints:

    • Stage One: Infrastructure: The infrastructure is the code responsible for routing requests and handling the “meta” layer of the API, including JSON serialisation/deserialisation, linking, embedding, and REST best practices. This adds a simplified routing layer outside of WP’s rewrites, allowing non-query-var rewrites easily, acting as a base for building APIs inside WordPress.
    • Stage Two: Endpoints: These are where much of the complexity of the API lies, as they’re responsible for mapping data from the external JSON format to the internal data structures, and vice versa. The “business” logic of integrating with WordPress is almost entirely contained within the endpoints. These are the more complex part of the API, as they require using deep APIs in WordPress, and handling security and privacy concerns.

    With this plan, we would aim to have the infrastructure merged in 4.4, and the endpoints merged one release later in 4.5.

    The slow nature of this plan allows a longer review time on the API for core committers. It also gives extra time for reviewing the endpoints, since they would be delayed one release.

    Merging the infrastructure now would allow third-party code to begin using the API to build upon it, including migrating from existing custom code. It would also help to increase developer confidence in the API (as it represents a commitment by the project towards a REST API).

    In this plan, the first stage would not include any of the base controllers (such as the posts controller). This may limit the utility of the infrastructure for plugins and themes, however as the endpoints would be merged a cycle later, it’s expected that this wouldn’t have a huge impact.

    The infrastructure of the API is approximately 2700 lines of code (roughly a third of the API codebase), and the endpoints make up the remaining 5500 lines of code.

    What would happen after merge?

    After merging the REST API into core, we’d spend approximately two weeks partying and celebrating. ๐Ÿ™‚

    Once we’re done with the parties, one major question would be how we manage the API in the future. The existing management and contribution process via GitHub has been extremely successful, as we’ve had 61 people’s pull requests merged into the API. Contribution via GitHub is especially useful for the API, as it’s a heavily developer-focussed project, and is aimed at external (non-WordPress) developers. On the other hand, all other contribution to WordPress is done via SVN and Trac, so integrating with this process is important for existing developers, as well as core’s general processes. We need to ensure the API is an integral part of core, not a separate project.

    Given the team’s experience with GitHub as well as Trac, we can bring the best of both worlds by helping integrate the two. This would also improve contribution for WordPress as a whole, and benefit the whole community. This will be especially important as we encourage more contributions from the wider community (client authors, for example). We think we can make good progress here, and we’d love to try and help improve the process. ๐Ÿ™‚

    In addition to the project management, there are still further API projects we need to tackle. Authentication is the most important of these, as a huge focus on OAuth and similar would be needed to make the API more useful for external clients. Currently, we haven’t had enough time to spend on this as well as managing the API project, however the API is now reaching a finalised stage, so this should be able to improve quickly. Centralised authentication is a huge part of this, as the regular OAuth registration process is cumbersome for a distributed system like WordPress.

    Important note: We don’t believe authentication is required for the API merge, and we treat it as a separate project. The authentication is a completely separate system to the API itself. This is something we’d give more time to in the future, but we want to focus on shipping the API for now.

    Let’s go!

    This is our merge plan for the API, however it’s not finalised. If you’ve got comments, thoughts, suggestions, opinions, or words of encouragement, let us know. We’d love to know what you think. Thank you all, you’re wonderful, and stay golden.

     
    • Ahmad Awais 3:13 am on September 21, 2015 Permalink | Log in to Reply

      “After merging the REST API into core, weโ€™d spend approximately two weeks partying and celebrating.” ๐ŸŽ‰โœจ๐Ÿ’ฅ Just like that ๐Ÿ™‚ Hoping for REST API to get merged as soon as possible.

    • Jon Brown 3:37 am on September 21, 2015 Permalink | Log in to Reply

      One the one hand this can’t happen too soon or too fast… on the other hand I understand the slow and staged approach.

      I’ve never seen it happen but would it be feasible to merge it into core and flag it as “beta” for a release? I know that wouldn’t be “normal” but then this big of a merge hasn’t happened in a long while and I’m just wondering if something like that was considered?

      The GitHub issue is a big one and I’m glad you touched on it, but I’m entirely unclear what you’re actually proposing here going forward? Are API devs going to continue to have a way to contribute via GitHub post merge?

      • Ryan McCue 3:51 am on September 21, 2015 Permalink | Log in to Reply

        Iโ€™ve never seen it happen but would it be feasible to merge it into core and flag it as โ€œbetaโ€ for a release?

        I believe the Heartbeat API was handled this way, but I can’t speak as to whether it’d be feasible here; that’s something for the core team to consider. ๐Ÿ™‚

        Are API devs going to continue to have a way to contribute via GitHub post merge?

        The plan would be that the API will become an integral part of core, and that contributing to the API would be just like contributing to WordPress. However, we’d like to help people contribute to WP via GitHub, which would allow contributions to the API (or any other part of core) via GitHub. ๐Ÿ™‚

        • borekb 7:02 am on September 21, 2015 Permalink | Log in to Reply

          > However, weโ€™d like to help people contribute to WP via GitHub, which would allow contributions to the API (or any other part of core) via GitHub. ๐Ÿ™‚

          Yes yes yes! That would be a nice by-product of the API project ๐Ÿ™‚

      • Gary Pendergast 3:56 am on September 21, 2015 Permalink | Log in to Reply

        The GitHub issue is a big one and Iโ€™m glad you touched on it, but Iโ€™m entirely unclear what youโ€™re actually proposing here going forward? Are API devs going to continue to have a way to contribute via GitHub post merge?

        To add to @rmccue‘s comments – the REST API team already have a well established workflow in GitHub. We’d like to experiment with combining their workflow with an (as yet undecided) method for syncing Pull Requests with Trac tickets.

        By experimenting with a small part of WordPress, we can hopefully create a model that could be expanded to work for the entire WordPress project.

    • kstover 3:47 am on September 21, 2015 Permalink | Log in to Reply

      +1

      We’re currently re-writing the moderately successful Ninja Forms plugin using primarily Backbone, and this would be amazing for our plugin. As you say in the proposal, we currently have to stretch admin-ajax.php to the limit.

      Hoping this happens!

    • kdpuvvadi 3:59 am on September 21, 2015 Permalink | Log in to Reply

      what happens to the releases on github, what pull requests and issues? will you handle those?

      • Ryan McCue 4:56 am on September 21, 2015 Permalink | Log in to Reply

        See comments above on how we want to handle GitHub integration. The existing issues on our tracker will either be migrated over, or closed out.

    • Ionel Roiban 4:31 am on September 21, 2015 Permalink | Log in to Reply

      Ggreat news. Where is the API documented?

    • markkaplun 5:08 am on September 21, 2015 Permalink | Log in to Reply

      +0.5 for inclusion, but the only reason is that is serves as a wrapper to Alax API which can speed up AJAX related development.

      OTOH I am still trying to find what does the RST API does that a seasoned developer can’t easily do by himself with the AJAX API.. It is not a replacement to XML-RPC as XML-RPC is a standard adopted by all major platforms and therefor do not required 3rd party (lts say flickr) an extra effort to support different platforms (another more popular usage is trackbacks). With the REST API, it is a wordpress specific thing and to be used by a 3rd party an extra development will be required.

      So the question is why do we need a 4rd way to do computer to computer communication, what is the use case that make the REST aPI shine, something that either impossible or is just so much better then doing it with other protocols? Right now caching of AJAX requests is the only thing I can come up with and that is the reason for the “include but the feature is a meh” above.

      • Ryan McCue 5:59 am on September 21, 2015 Permalink | Log in to Reply

        I am still trying to find what does the RST API does that a seasoned developer canโ€™t easily do by himself with the AJAX API.

        The REST API is a much simpler API for interacting with, and doesn’t have a lot of the problems that XML-RPC does (although it has problems of its own). It’s typically much easier and faster to work with on almost every platform, and it’s a bunch less data that needs to be sent over the wire, which is especially important for mobile applications.

        The XML-RPC we have currently is actually significantly custom to WordPress: XML-RPC is just a standard for an over-the-wire API (similar to REST). The actual APIs for blogging are Blogger, MetaWeblog, Movable Type, and WordPress. (Plus the pingback API.) MetaWeblog is the only actually standard API, but offers very limited utility, which is why the others exist.

        That said, XML-RPC is going nowhere in the short term. It’s still very useful due to compatibility, although I wouldn’t recommend creating a new client using it, due to the complexity.

        a seasoned developer canโ€™t easily do by himself

        Just to note: there are plenty of female developers, so “themselves” would be a better pronoun to use. ๐Ÿ™‚

        • markkaplun 4:33 pm on September 21, 2015 Permalink | Log in to Reply

          I think you avoided the main question of use case in which the API shines. The problem with not having a use case is that without one it is impossible to compare if an full REST API is better then some other APIs, or maybe the main benefits can be achieved by some wrapper around the Ajax and rewrite APIs without the added bloat and increasing the attack surface.

          For example a simple use case is a scrolling news feed which refreshes every 10 minutes.With what I see in the API for each new post I will have to do 2 request, one getting the post and another getting the featured image. If I will code it by myself it will do it in one request. The difference between 1 and 2 requests can be the difference between shared hosting and VPS.
          Another variation of the same problem is that AFAICT post meta is not retturned as part of the post request,why is that?

          The point is that the API is huge and every piece of it should be justified IMHO before added to core. 90% (made up the number by myself!) of wordpress sites are not going to use this functionality in any way, at least not before the IOS and android apps will be changed to use it, so why should this bloat be added to core?

          as for male/female thing I can go into how ridiculous it is to expect people that english is not their mother tongue to use english correctly and be aware to all the small cultural assumption behind each word, but I am not PC Principal (people who do not watch south park should be ashamed of themselves)

          • Pete Nelson 6:32 pm on September 21, 2015 Permalink | Log in to Reply

            Using the rest_prepare_post filter, you can add featured image details to each post, thus preventing a round-trip to the server on the front-end. Could also be used for post meta.

            Here’s a link to the relevant slide from a talk I did at WordCamp DFW on extending the REST API: https://docs.google.com/presentation/d/1o4gJnEcq1vbDUsjZu_zRfh8D7crxzU45gTCquZOFODw/edit?pli=1#slide=id.ga423abea2_1_61

            • markkaplun 5:54 am on September 22, 2015 Permalink

              But this requires me to write a plugin that has to be installed server side, and them my JS is not compatible to other wordpress sites, so except for saving some coding what is the difference from now?

              I think your comment helped me to understand my own position. I fully on board with using the core code of the plugin in core in order to make it easier to deploy json based REST API, but I don’t think that the current endpoints are fully baked, it seems like they return too much internal information which no one should know about except for the admin (like list of post types) but also not sure that they give enough information for the most common use cases.

          • Matthew Eppelsheimer 11:42 pm on September 21, 2015 Permalink | Log in to Reply

            I think the key point here is that nearly anything developers can do with XML-RPC or admin-ajax APIs, they can do more easily with the JSON REST API. So it shines across the board, for many use cases.

            The iOS and Android apps can’t start to use this until it is in core. Core itself, and default themes, will also likely use the API in the future. So someday, most and perhaps even all WordPress installations will eventually use the API.

            • markkaplun 6:14 am on September 22, 2015 Permalink

              IOS and android apps will keep using XML-RPC as long as there will be sites that use WP versions 4.3 and below, which is years in the future, and even then why would they rewrite the code for no actual benefit? There is nothing wrong with XML-RPC except for being old and XML note being hype anymore.

              I am not even sure that there is a parity in capabilities of both protocols right now (doesn’t seem like there is an end point for options).

            • Ryan McCue 1:12 am on September 23, 2015 Permalink

              IOS and android apps will keep using XML-RPC as long as there will be sites that use WP versions 4.3 and below

              The iOS and Android apps only currently support 3.6 and 3.5 respectively, so they do have the ability to move faster. In addition, you can progressively support the API, with an XML-RPC fallback if you want.

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

            One of the key benefits of the API is that it can remove the need to write anything at all on the server. In addition, data’s provided in a standard way across the wire, making it much easier for plugins to extend. Right now, custom bespoke APIs are unlikely to work across the board with plugins, or even with the edge cases in core. (For example, handling password protected posts is super painful right now.)

            With what I see in the API for each new post I will have to do 2 request, one getting the post and another getting the featured image.

            For the specific example here, try adding ?_embed to your request, and you’ll get back the linked resources as well. http://v2.wp-api.org/extending/linking/ has more detail on that.

            Another variation of the same problem is that AFAICT post meta is not retturned as part of the post request,why is that?

            Answered below; see https://github.com/WP-API/WP-API/issues/1425 for why the current situation is what it is, and what our plans are for improving it.

            The point is that the API is huge and every piece of it should be justified IMHO before added to core. 90% (made up the number by myself!) of wordpress sites are not going to use this functionality

            We can almost immediately begin removing custom Ajax handlers in the admin, such as the code that handles trashing comments. wp-admin/includes/ajax-actions.php might be able to disappear entirely (fingers crossed), and that single file is ~3000 lines just by itself.

            If we can replace all of this code with well-tested code, I think it’s already worth it.

      • Ipstenu (Mika Epstein) 1:32 pm on September 22, 2015 Permalink | Log in to Reply

        The xmlrpc approach is heavily targeted by ddos and brute force attacks, which makes it rather undesireable. From a host standpoint, we hate it ๐Ÿ™‚

        https://blog.sucuri.net/2014/07/new-brute-force-attacks-exploiting-xmlrpc-in-wordpress.html Just as an example.

        While not all the issues go away with this, enough do that I welcome our new restful overlords.

    • Daniel Homer 7:03 am on September 21, 2015 Permalink | Log in to Reply

      This is fantastic news, thanks to everyone involved! A standardised API in core will simplify a lot of JS logic in plugins and will pave the way for more advanced web apps on top of WordPress.

      ๐ŸŽ‰

    • borekb 7:05 am on September 21, 2015 Permalink | Log in to Reply

      What will be the story for plugins that opt to use the API but also need to support 4.3 and below? Will there be a compat plugin for 4.3 and below? Or is that up to the plugin author to deal with that and for example ship parts of the API for older WP versions?

      • Ryan McCue 7:07 am on September 21, 2015 Permalink | Log in to Reply

        The plan is to turn the existing plugin into one that progressively enhances your WP install. It’ll include the infrastructure for sites that don’t have it, but will use core’s otherwise. Once the endpoints are merged, it’ll disable itself. ๐Ÿ™‚

        I’d expect that we’ll aim to support this at least until the next major release after the endpoints are merged.

        • borekb 7:11 am on September 21, 2015 Permalink | Log in to Reply

          Cool, thanks for the answer.

        • xavivars 5:45 pm on September 23, 2015 Permalink | Log in to Reply

          That’s the answer I was dreaming!!! We’re working on a project right now where we’re building a site that would benefit a lot from having a powerfull rest-api like the one you guys have built, but my concern was that there was no way to fully use it until it was integrated.

          Seriously, you guys are awesome ๐Ÿ™‚

      • Ipstenu (Mika Epstein) 1:43 pm on September 21, 2015 Permalink | Log in to Reply

        Keep in mind what the ‘compatible up to’ and ‘requires’ version actually means in plugins. If you say your plugin requires 4.4, then no one on 4.3 gets updates. In theory you could back port your 4.3 compat tags (say your version 2.5 is sans API while 2.6 is with the new API), and just update 2.5.1 and 2.6.1 for each user base.

    • Hugh Lashbrooke 8:25 am on September 21, 2015 Permalink | Log in to Reply

      > This adds a simplified routing layer outside of WPโ€™s rewrites, allowing non-query-var rewrites easily.

      I never even thought of that as a possibility with this API and I think that excites me more than anything else about this project. It couldn’t be in core sooner ๐Ÿ™‚

    • Erlend Sogge Heggen 10:28 am on September 21, 2015 Permalink | Log in to Reply

      First and foremost: CONGRATS! Major props to everyone involved.

      Just one question: What about all these overlapping technologies (XML-RPC, the admin-ajax etc.) that you mention. Is there a deprecation plan in place for the parts that the REST API will cover?

      • Ryan McCue 1:30 pm on September 21, 2015 Permalink | Log in to Reply

        There’s no deprecation plan for them, as they’re not complete replacements. We’ll see what happens in time though; if usage of another API were to drop significantly in favour of the REST API, maybe we could look at it in the future.

    • James DiGioia 12:11 pm on September 21, 2015 Permalink | Log in to Reply

      Very exciting! One question: Will the Backbone client be merged as part of the endpoints, the infrastructure, or as a separate step entirely?

      • Ryan McCue 1:30 pm on September 21, 2015 Permalink | Log in to Reply

        The Backbone client is linked to the endpoints, so it’d be merged with them if at all; we’ll discuss whether it should be as we get closer to merging them ๐Ÿ™‚

    • Omaar Osmaan 12:14 pm on September 21, 2015 Permalink | Log in to Reply

      ๐Ÿ˜€

    • Marcus 12:21 pm on September 21, 2015 Permalink | Log in to Reply

      I’m bummed that I haven’t had the chance yet to play with the API yet and give constructive feedback, so words of encouragement is all I can offer. I’ve been following this project closely and can’t wait for this to happen ๐Ÿ™‚ this has so much potential for WP as a whole.

      Well done to the whole JSON API team, thanks for all your efforts. Go for it!

    • Daniele Mte90 Scasciafratte 12:43 pm on September 21, 2015 Permalink | Log in to Reply

      I’m in this state http://memecrunch.com/meme/3MCTZ/excited-picard/image.jpg?w=510&c=1
      Also today I’ve written a little article about to expand that api the post type with custom fields http://www.mte90.net/en/2015/09/extend-the-wordpress-rest-api-of-a-post-type-by-custom-fields/

    • Per Soderlind 4:42 pm on September 21, 2015 Permalink | Log in to Reply

      +1 ๐Ÿ™‚

    • mojaray2k 5:20 pm on September 21, 2015 Permalink | Log in to Reply

      I am so thrilled that this is happening. As a developer I am curious on how OAuth is going to be implimented. Right now it is very difficult to implement without some third party service. Or maybe I am not understanding how to implement it the WordPress way.

    • Aaron Jorbin 5:32 pm on September 21, 2015 Permalink | Log in to Reply

      Thanks for putting this together. A couple of questions that I have:

      1) What would happen to v1 of the API upon merge? Would a new version of it be released that relied upon the routing in core? Would it continue to function by itself? Would it break?

      2) Based on your statement ” On the other hand, all other contribution to WordPress is done via SVN” are you aware that there are git mirrors that all non-committers can use? ๐Ÿ˜€

      3) Is two weeks sufficient amount of time for ๐ŸŽ‰?

      4) Has there been any discussion about marking any of the new classes or methods in the classes as final upon introduction?

      • Ryan McCue 11:13 pm on September 21, 2015 Permalink | Log in to Reply

        What would happen to v1 of the API upon merge?

        Our original plan was to have v1 become a shell that wraps the infrastructure in core to provide compatibility, and I suspect we’ll still do this. We’re yet to get the specifics of it down. ๐Ÿ™‚

        are you aware that there are git mirrors that all non-committers can use?

        Using git vs managing contributions via GitHub is a different kettle of fish. Right now, I already use git for making patches, but the flow for contributing those changes back is a bit cumbersome. We can do better ๐Ÿ™‚

        Is two weeks sufficient amount of time for ๐ŸŽ‰?

        Maybe not, but real life commitments get in the way of any prolonged ๐ŸŽ‰ing. ๐Ÿ˜ฌ

        Has there been any discussion about marking any of the new classes or methods in the classes as final upon introduction?

        Our intention is to keep them all extensible for now, and they’re all designed for reuse. As for forwards-compatibility though, we’ll consider this as we “finalise” (๐Ÿ˜) the classes for merging.

    • karlazz 8:17 pm on September 21, 2015 Permalink | Log in to Reply

      Hello,

      I used the API briefly and then rejected it for a few reasons:
      1) the Oauth1 is hard to use and not well supported with examples or libraries, why not use Oauth2 like everyone else?
      2) It was awkward to get at post meta information. I used a plugin.
      3) the requests returned too much information and my programs died with a memory fault. Due to the nature of my plans for the application, this was not acceptable so I wrote simpler more specific tools that did not return mountains of unnecessary fields and require my users to increase their PHP memory limit.

      1) There is a lack of community code available for using Oauth1, and the API authors didn’t provide any guidance for setting it up, just some information thrown over the shoulder as it were. Even the endpoints were hard to find in their literature, and not quite the same as the ones described as “standard”. I hope that will be improved, or that you will switch to Oauth2, like the rest of the world. Security is a very important aspect of this project and people need to be able to use the locks. It would be great to provide a description of how to set up and use curl calls to access the API security. Salesforce does a good job of this, as does Box.com.

      2) Couldn’t access postmeta information via the API unless Oauth1 is implemented. Why? Used work around.

      3) It would be great if I could designate which fields I need to have returned using POST data and json. Box.com does this, as do others. This would save on memory when returning large numbers of records. Maybe you have this already and I missed it?

      Thanks. Good luck. This is a great idea but I chose not to use it and would not recommend it for the above reasons.

      • Ryan McCue 11:19 pm on September 21, 2015 Permalink | Log in to Reply

        the Oauth1 is hard to use and not well supported with examples or libraries, why not use Oauth2 like everyone else?

        I totally agree, OAuth 1 is a pain. However, the reason that OAuth 2 is much nicer is that it relies on SSL to handle much of the message authentication. We can’t require SSL for WordPress core code, so OAuth 2 is unfortunately a non-starter there.

        The OAuth Working Group has been making slow progress towards removing this requirement, and we’ve been following that. If anything changes there, we’ll consider changing it.

        Couldnโ€™t access postmeta information via the API unless Oauth1 is implemented. Why? Used work around.

        Working with postmeta requires a great deal of care, due to privacy and security concerns. As it turns out, there are lots of people who use the Custom Fields box to save private notes directly to post meta, so we cannot just expose all meta without considering.

        We’re looking at relaxing the restrictions here in the future: https://github.com/WP-API/WP-API/issues/1425

        It would be great if I could designate which fields I need to have returned using POST data and json.

        This is something that most people don’t need, and which also has the ability to play havoc with server-side caches. This is easily doable in a plugin however, and we’d love to see someone take up the work there.

        See https://github.com/WP-API/WP-API/issues/572 for more details.

        • pathartl 3:52 pm on September 24, 2015 Permalink | Log in to Reply

          Just showing my support for keeping post meta behind Oauth. At first I was skeptical, but it’s very easy to hook into the data via the `json_prepare_post` filter and add any data you want to the JSON response.

    • John Teague 8:26 pm on September 21, 2015 Permalink | Log in to Reply

      I can’t tell you how happy I am and how thankful I am to the entire REST API team. I have lobbied for the inclusion into core, and I know this will make WP stronger and better for the future. Kudos all around @ryan,@rachelbaker, contributors all. ๐Ÿ™Œ

    • Greg Ichneumon Brown 9:53 pm on September 21, 2015 Permalink | Log in to Reply

      The v2 docs mention 3 types of authentication: cookie auth, oath1, and basic auth. You mention though that Authentication is a separate project.

      Are some of these (all?) going to be part of the merge and when are they available (stage 2?). I assume many of the endpoints are not useful without some level of authentication (though I guess there are many GET endpoints that could work without auth).

      • Ryan McCue 11:20 pm on September 21, 2015 Permalink | Log in to Reply

        Cookie authentication is built-in to WordPress, so that’ll be there out of the box. Basic authentication is only intended as a development tool, so the intention is to never include this with WordPress. OAuth 1 is something we’ll consider in the future, either when merging the endpoints, or shortly afterwards.

    • Michael Beil 10:18 pm on September 21, 2015 Permalink | Log in to Reply

      This is such momentous news @ryan and @rachelbaker!

    • simonrcodrington 12:27 am on September 22, 2015 Permalink | Log in to Reply

      I’m all for the integration of the REST API into WordPress core. My concern is if this will produce any strange side effects that could affect my sites (I know this supports multiple types of security such as oAuth but it’s always on my mind)

      It’s been tested for a while but I still think a cautious approach to this would be better (with starting integration later at WP 4.5 and then moving from there). It’s one of the biggest introductions to core in a while so I’m happy with a slower pace ๐Ÿ™‚

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

        With this first phase, there won’t be any read or write capabilities added, only internal APIs. A future version will start integrating those as part of the second phase.

        We’ve also been working on this for ~2 years, and in the meantime we’ve fixed a few security bugs (mostly minor), so we’ve already had lots of eyes over the code. ๐Ÿ™‚

    • Zach Russell 6:01 pm on September 22, 2015 Permalink | Log in to Reply

      I scanned through the comments and don’t think I found an answer there. I’m working on an app right now that uses the WP API. Will I have to make any changes to my code once the WP API is merged with core?

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

        The plan is that the current v2 will become the core version with minimal changes. If you build off v2 now, you may need to change your code slightly, but changes will almost certainly be minor.

    • Praveen Chauhan 9:38 am on September 23, 2015 Permalink | Log in to Reply

      Great news !!! Congrats to the REST API team.

      Have few questions:

      1) How will REST API specific support queries/updates be handled?
      For a plugin, there can be many support queries, and there is a dedicated forum. So if some one has queries specifically related to the REST API, will you continue to use the REST API plugin’s forum or have you planned to shutdown that forum or plugin listing?
      More importantly, how will updates for the fixes be handled? I mean, if some one has issues specific to the REST API functionality which requires some fixes, will the users need to wait for the new release of WordPress or do you have an alternative plan for this?

      2) What will be the impact on WordPress’ performance?
      As a plugin, the functionality is optional for users. But after merging it into the core, its modules will be loaded along with WordPress. So what would be its impact on site load, performance etc?

    • pathartl 4:12 pm on September 24, 2015 Permalink | Log in to Reply

      +1 in full support. A question and comment:

      1. What will happen with the plugin (both v1 and v2) when it is activated on an install that has the API in core? We’ve written some read-only things for v1 and I’m concerned about having a major refactor later on down the road. No doubt it will eventually happen, but the concern lies in the first couple phases of integration.

      I’m glad the core committers will have to look at every aspect. I found the documentation lacking in places. Well not necessarily lacking, but not as well documented as most things in the codex. This is a big merge that is totally developer focused and should be hashed out really well.

      Thanks for the hard work! This is much needed

    • suifengtec 5:08 pm on October 9, 2015 Permalink | Log in to Reply

      It’s cool for the future of WordPress !

    • snstarosciak 1:21 pm on October 21, 2015 Permalink | Log in to Reply

      Nice! So here’s my question. How will this impact current sites using the WP API v2? Assuming building something like this into core will make API-creation plugins unecessary, I’m guessing that the “final” functionality will be available in 4.5 that is similar to how the WP API v2 works?

      Thankyou!

    • mmaumio 9:01 pm on November 5, 2015 Permalink | Log in to Reply

      That’s Awesome. It’ll surely save us from creating our API or using a third party plugin.
      +1 for this.

    • WP Plugin Dev dot com 12:41 pm on November 20, 2015 Permalink | Log in to Reply

      Two important questions arise:
      What is public in the API after the merge?
      Can I tell WordPress to don’t provide the API functionallity?

  • Ryan McCue 7:29 am on August 14, 2015 Permalink
    Tags: , , , ,   

    WP REST API: Versions 1.2.3 (Security Release) and 2.0 Beta 4 

    First and foremost: version 1.2.3 of the REST API is now available. Download it from the plugin repository or from GitHub. This is a security release affecting sites running version 1.2 or a 2.0 beta releases.

    Security Release

    Recently, we were alerted to a potential XSS vulnerability introduced in version 1.2 of the API related to the JSONP support. This vulnerability also existed in version 2.0. Thanks to Alex Concha (@xknown) for reporting this issue to the team responsibly.

    This release was coordinated by the REST API team and the WordPress core security team. The security team is pushing automatic updates for version 1.2.3, but do not wait or rely on the automatic update process. We recommend sites or plugins that are using either v1.2.x or 2.0 beta releases update the plugin immediately.

    If you’d prefer not to upgrade, you can instead disable JSONP support through a filter. For version 1:

    add_filter( 'json_jsonp_enabled', '__return_false' );

    To disable JSONP on version 2:

    add_filter( 'rest_jsonp_enabled', '__return_false' );

    If you have a question about the security release, you can find the team in #core-restapi on WordPress.org Slack, or you can privately message @rachelbaker, @rmccue, @danielbachhuber, or @joehoyle.

    Version 2.0 Beta 4

    Alongside the security release for version 1.2, we’re also releasing the latest beta for version 2.0: 2.0 Beta 4 “See My Vest”. You can download this from the plugin repository or from GitHub.

    This beta release includes the security fix from version 1.2.3, so we recommend everyone running a version 2 beta update immediately to fix the issue.

    As well as the security release, this beta also includes a bunch of other changes. Here’s some highlights:

    • Show public user information through the user controller.

      In WordPress as of r32683 (scheduled for 4.3), WP_User_Query now has support for getting users with published posts. To match current behaviour in WordPress themes and feeds, we now expose this public user information. This includes the avatar, description, user ID, custom URL, display name, and URL, for users who have published at least one post on the site. This information is available to all clients; other fields and data for all users are still only available when authenticated.

    • Send schema in OPTIONS requests and index.

      Rather than using separate /schema endpoints, the schema for items is now available through an OPTIONS request to the route. This means that full documentation is now available for endpoints through an OPTIONS request; this includes available methods, what data you can pass to the endpoint, and the data you’ll get back.

      โš ๏ธ This breaks backwards compatibility for clients relying on schemas being at their own routes. These clients should instead send OPTIONS requests.

    • Update JavaScript API for version 2.

      Our fantastic JavaScript API from version 1 is now available for version 2, refreshed with the latest and greatest changes. Thanks to Taylor Lovett (@tlovett1), K. Adam White (@kadamwhite) and Nathan Rice (@nathanrice).

    • Embed links inside items in a collection.

      Previously when fetching a collection of items, you only received the items themselves. No longer! You can now request a collection with embeds enabled (try /wp/v2/posts?_embed).

    • Move /posts WP_Query vars back to filter param.

      In version 1, we had internal WP_Query vars available via filter (e.g. filter[s]=search+term). For our first betas of version 2, we tried something different and exposed these directly on the endpoint. The experiment has now concluded; we didn’t like this that much, so filter is back.

      โš ๏ธ This breaks backwards compatibility for users using WP Query vars. Simply change your x=y parameter to filter[x]=y.

    • Respect rest_base for taxonomies.

      โš ๏ธ This breaks backwards compatibility by changing the /wp/v2/posts/{id}/terms/post_tag endpoint to /wp/v2/posts/{id}/tag.

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

    (Note that while this version 2 beta breaks backwards compatibility, the 1.2.3 security release does not break compatibility with the 1.2 branch.)

    This release had 11 contributors, and we’d like to thank each and every one of them:

    $ git shortlog 2.0-beta3...2.0-beta4 --summary
         1   Daniel Bachhuber
        11   Daniel Jalkut
         1   Fredrik Forsmo
         1   Jared Cobb
         3   Jay Dolan
        26   Joe Hoyle
        10   Josh Pollock
        25   Rachel Baker
        50   Ryan McCue
        24   Stephen Edgar
         8   Taylor Lovett
    

    Thank you again to all of our beta testers, and thanks to everyone who let us know how you’re using the API. We’re taking note of all of your feedback, and you might see some further changes related to that in coming releases.

     
    • Ahmad Awais 8:18 am on August 14, 2015 Permalink | Log in to Reply

      Hey, Ryan!
      Did you change the folder name or main file name in WP REST API 1.2.3 since I am using 1.2.2 and I didn’t get any update notification, which is weird.

      • Ryan McCue 10:10 pm on August 14, 2015 Permalink | Log in to Reply

        The patch in 1.2.3 is minimal and didn’t change the filename. If you’re using the API from GitHub, your folder might accidentally be called WP-API, whereas it should be json-rest-api to match the repo.

    • CotswoldPhoto 9:40 am on August 14, 2015 Permalink | Log in to Reply

      Great work team REST API. I really hope that this makes it into core for 4.4.

    • Rachel Baker 12:56 pm on August 14, 2015 Permalink | Log in to Reply

      Oh, please won’t you see my vest! ๐ŸŽถ

  • Ryan McCue 12:06 am on July 23, 2015 Permalink
    Tags: ,   

    REST API: Who’s Using This Thing? 

    Hi everyone!

    This is a break from your regularly scheduled release posts. We’re looking to gather some feedback on the lead up to merging into core, to assess what your thoughts are on the API. Whether you’ve used the API or not, we’d love to hear your thoughts.

    Here’s a bunch of questions to start you off:

    • What are you doing with the API?
    • What would you like to do with it? (How can we make it better for you? What can’t you do right now that you need?)
    • What improvements would you like to see? (What sucks?)
    • Is the API important to you?
    • Anything else you’d like to tell us?

    We really want to make sure this API fits your needs. Without your support, the API really means nothing, so we want to make sure we get this basically perfect first. We’d love to hear feedback from everyone using this, from JS-only developers coming to WP for the first time, through WordPress plugin and theme developers, all the way through to PHP developers not involved with WordPress.

    If your comment is too long to fit here, or you’d like to wax lyrical about the API, feel free to comment on your own blog and cross-post a link across to here.

    If you can’t comment publicly due to disclosure, you can leave a message for me personally at me at ryanmccue.info. Please specify if you will allow me to share your private feedback with the WP REST API project and core team, or if you’d prefer to keep it completely private between the two of us.

    Help us make this the best feature to ever land in WordPress. ๐Ÿ™‚

     
    • nicholosophy 12:17 am on July 23, 2015 Permalink | Log in to Reply

      I’m not currently using the API. I do think the API is important to the future of WordPress.

      There are many systems that I interact with at $dayjob that have an API, and it allows me to create custom solutions to control these systems in ways that the developers wouldn’t have imagined, or did and didn’t want to support. I can use an API to work with our SaaS professional services automation (PSA) software to make changes not possible via the provided UI and that would require db access otherwise. I can use it to extract data out to create scheduled notifications or reports and trigger actions where there isn’t native functionality for that.

      We have a WordPress intranet and to be fair I wouldn’t NEED the API for that as I can access the installation and its database. However an API could be used to schedule a data grab to produce a report showing who accessed stuff for the day, or who updated what. This can be done in other ways with plugins, but if the site is locked off or hosted as SaaS then that isn’t always possible.

      It also allows WordPress to become the core of SaaS solutions with purposes way outside those envisioned for a standard WordPress install. The ability to add onto the API means that a full SaaS with API could be built based on the core WP-API codebase.

      WordPress would survive without an API in core. With an API in core, WordPress will only grow and flourish more, and that can’t be a negative.

    • sethshoultes 12:20 am on July 23, 2015 Permalink | Log in to Reply

      Event Espresso 4 REST API Add-on is built on top of the API:
      http://eventespresso.com/2015/07/event-espresso-4-rest-api-add-on-available/

      • Mike Nelson 4:25 am on July 23, 2015 Permalink | Log in to Reply

        More details on that, specifically addressing Ryan’s questions:

        What are you doing with the API?

        We’ve extended it for our event registration plugin, so that events (custom post types), venues (custom post types), datetimes-of-events, tickets-for-events, registrations, payments, etc are accessible via the API (some public data, some for logged-in users only).

        API Client application things that we and our community want to build: an event calendar that uses event data from the API; javascript code snippets that can show upcoming events on other, non-wp sites (example code snippets); mobile apps for event admins to check registrants at the door, etc.

        What would you like to do with it?
        We’ve had requests for PUSHING API data to remote servers whenever specific events happen in our system (eg, when a post or event is published, send its json data to a specified URL). I think this could be a nice future feature, but not essential right now.

        What improvements would you like to see?
        Some system for accessing wp options seems important no? If not complete access, at least a simplified way for the api to be extended to grant access to wp options designed by the developer. For example it would be nice if could just do

        apply_filter( 'wp_rest_api_exposed_options', 'my_callback_for_options_i_want_exposed');
        function my_callback_for_options_i_want_exposed( $option_names) {
        return array_merge( $option_names, array( 'my_plugins_option_1', 'my_plugins_option_2');
        }

        Or something simple like that. I understand right now wp options CAN be exposed (we’re exposing one or two for READ-only right now) by registering custom endpoints etc; but some simplified method would be friendly.

        Is the API important to you?
        Fairly. We’ve put in enough effort to make our plugins’ data READABLE, but aren’t moving ahead with making our data WRITEABLE until we see some more demand for it in our community

        Anything else you’d like to tell us
        Extending the API was easy thanks to documentation and uncomplicated code, thanks!
        We’d love some feedback on our extension of the WP API if you’re ever in the mood.

    • @modemlooper 12:26 am on July 23, 2015 Permalink | Log in to Reply

      http://reactorapps.io

      We use the api to create apps that digest the api themselves. So meta!

    • Ryan McCue 12:27 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      We’re (Human Made) building a bunch of client sites using the API. These are built because either users want the WP admin, but want something more flexible for the frontend; or because we want to add superpowers to the frontend we’re building out.

      I’m personally working on two projects using the API. The first of these is a client project. The client wants to use a Node-powered frontend, but have the familiar WordPress admin and flexibility available to them. They also need a fair amount of custom work for the stuff specific to their site, which is provided through custom fields and endpoints in the API.

      The second project is a theme powered entirely via the API. Internally, it uses the API along with some crazy backend rendering, which allows sharing templates between the frontend and backend. This theme is intended as a communication tool, so it’s very complex and interactable compared to a normal theme. It uses the core endpoints mainly, but also adds extra fields to the data returned for presentational data like CSS classes.

      What would you like to do with it?

      Basically everything I need to do is already covered. Some of the presentational data that’s required needs to be added manually, but this also doesn’t make sense to expose to all clients, so it makes sense that it’s not exposed through the API automatically. (I’m also biased, in that if I need something, I can commit it to the plugin ๐Ÿ™‚ )

      What improvements would you like to see?

      One of the things I’d like to see is WP permalink-to-route mapping, to allow taking an arbitrary link and working out the data for that link. This should be possible, and I’m exploring ways of doing that. It’s not something the API needs drastically, but would be a nice feature in the future.

      Is the API important to you?

      The API is the single part of WordPress I care most about, but again, I’m biased. ๐Ÿ™‚

      Anything else youโ€™d like to tell us?

      My fellow development is so dang awesome. Truly, you are all the best. Thanks to all of our contributors, with special thanks to Joe Hoyle and Daniel Bachhuber for your work on the latest releases.

      Extra-special mention to my partner-in-crime, Rachel Baker. Without you, I’d have thrown in the towel a long time ago. Thank you, thank you, thank you.

      • Matthew Haines-Young 9:33 am on July 23, 2015 Permalink | Log in to Reply

        I’m working with Ryan on a client project, and the API has really allowed us to separate out our responsibilities. We can more easily work along side each other and front end devs don’t have to touch WordPress theme files so they can just focus on building a great site.

      • Ken Newman 7:24 pm on July 23, 2015 Permalink | Log in to Reply

        Those projects sound awesome, let us know if any open-source code or tutorials come out of those projects!

    • David Bisset 12:36 am on July 23, 2015 Permalink | Log in to Reply

      The REST API would make some fundamental positive improvements to the WordPress project if you look at it long-term. The API represents a greater amount of possibilities for both users and developers – especially in the age of mobile. By promising to include it in core, you’ll be giving a big mental “green light” to many more developers to jump on the train.

      So much hard work, planning, and testing has been done (with more to be done in the future of course). Let’s allow this to transform over 24% of the web.

    • Nick Haskins 12:36 am on July 23, 2015 Permalink | Log in to Reply

      Short and sweet.

      I’m using the REST API it in a premium plugin called Lasso (name soon to change) https://lasso.is , which allows the user to view all posts from the front-end of the site, as well as in a free plugin called WP Live Search (https://wordpress.org/plugins/wp-search-live/) which uses the REST API to perform site searches.

      I’m apprehensive about diving full force into it for fear that it may not actually be included in WordPress core. Until the REST API is fully merged, I won’t be spending any more time with it.

    • Pete Nelson 12:42 am on July 23, 2015 Permalink | Log in to Reply

      I’ve been working on a logging plugin for the REST API (https://wordpress.org/plugins/wp-rest-api-log/), have some rewrites I’m working on before I feel like it’s done, but want to say thank you for making it so extensible.

    • Aleksandar Perisic 12:57 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      • some android native app that pull down json and images from WP,
      • angularJS as frontend (still messing around but i like it for online apps)

      What would you like to do with it? (How can we make it better for you? What canโ€™t you do right now that you need?)

      • Remove some parts from json output

      What improvements would you like to see? (What sucks?)

      • Documentation look like half way done… maybe its just me..
      • Need alot of examples
      • More functions (easier output cleaning)
      • Maybe more control in backend ?

      Is the API important to you?

      • Yeah

      Anything else youโ€™d like to tell us?

      • API API makes WP people HAPPY! and give us, one day, best offline/online auto sync and you guys can go to heaven
    • Josh Pollock 1:41 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      I write about it quite a bit for Torque Magazine. I’ve also written an add-on for SearchWP (https://github.com/CalderaWP/searchwp-api-route) and an add-on for WordPress SEO by Yoast (https://github.com/CalderaWP/seo-rest-api-fields). I’ve posted a bunch of other stuff on my Github as well, can’t keep track of it all.

      On my company CalderaWP’s site (https://calderawp.com/), we run custom endpoints (combining data from various post types and EDD functions) that we use to power the “featured plugins” feeds in our plugins’ admins. In the plugins themselves we have the template for rendering the response. (source: https://github.com/CalderaWP/calderawp-api/tree/wordpress)

      I’ve consulted with several non-WordPress developers who are building apps that use WordPress as their backend and needed advice or a little customization.

      I’m also a contributor to Lasso and helped with the one part that does use the REST API: https://github.com/AesopInteractive/lasso/blob/master/public/assets/js/source/all-posts.js The rest (pun?) uses a custom API for AJAX handling, that works and is efficient but is not “the WordPress” way.

      What would you like to do with it?

      It’s a pretty awesome and complete — for the front-end. I think that options handling, while a huge ball of worms would be great.

      Most of all, I’d like to tell potential users and potential users this was The WordPress REST API, without adding a bunch of confusing clarifications.

      Anything else youโ€™d like to tell us?
      Can we all take a minute to thank Ryan, Rachel, Joe and Daniel, for putting so much work into making something that is so awesome? Also, thank you to their employers for enabling them.

      Seriously folks, read the v2 source code, this is good stuff that we could be proud to have in core.

    • darrinb 3:45 am on July 23, 2015 Permalink | Log in to Reply

      I LOVE the API. I’ve used it on 2 client projects so far and both have been great successes. With the more recent project, my client–a large industrial real estate firm–manages their properties via an internal proprietary .NET app. Their public-facing site is powered by WP. We’re utilizing the API to sync property data (in real time) between their internal app and their site so their real estate listings will always be current.

    • saisasank 6:53 am on July 23, 2015 Permalink | Log in to Reply

      I am already using the API for building mobile apps. The other use cases that I intend to utilize are enabling users to connect their WP sites to my web app. So I have read/write access to their website. Forexample, if they want to do a SEO analysis of their website, I would want a list of their posts with the word count etc. Instead of installing a plugin they can just connect their website to my app using the API.

    • kdpuvvadi 7:46 am on July 23, 2015 Permalink | Log in to Reply

      I have used it while making a mobile app for client local news websites, it full filled my needs but why REST API as a some other optional feature in a plugin like jetpack not in the core. May be responsive designs and all may work for mobile and future is mobile, responsive designs are neither new nor better suit for all needs, for me designing entire mobile Is suitable but it is pain the ass to start over I’ve been using rest APIs from jetpack for mobile sites and I do not think it’ll full fill all needs. And I tried using WP REST APIs project and setting up those is really messy and I’ve never used after that. I’m not making a point here but may be a little.

    • NateWr 8:03 am on July 23, 2015 Permalink | Log in to Reply

      *What are you doing with the API?*
      1. I built a small SaaS app for child care providers in the UK. The app runs alongside a WordPress install that also runs my client’s eCommerce site for digital and physical products. By leveraging robust existing platforms (WordPress, Easy Digital Downloads, MemberPress) as well as the REST API and its associated tools (client lib for Backbone.js), I was able to build a quality, mobile-first at a fraction of the cost. Otherwise, a project like this simply wouldn’t have been within her budget.

      2. The Public Knowledge Project builds open source software that helps tens of thousands of academic societies, many from developing countries, publish their research on an Open Access model. Their software is a standalone product, but their website runs on WordPress.

      As part of the next generation of the software, I’ve built a plugin repository system for their WordPress site. People submit plugins for the software and we approve/reject them. Then thousands of sites around the world, which are not running WordPress, will ping our site via the REST API to find and install plugins for their site. It’s a mini wordpress.org/plugins/ setup.

      The new version is scheduled for release around the new year. And we highly value the REST API going into core, primarily for the peace of mind that comes from knowing it will get much wider exposure to security and stability tests.

      https://pkp.sfu.ca/

      If WP democratizes publishing, we’re democratizing academic publishing, fighting against a massive cash grab from major publishers, as they have begun to charge huge and unsustainable article processing fees for Open Access publishing (academic publishers have some of the highest profit margins of any industry).

      *What would you like to do with it? (How can we make it better for you? What canโ€™t you do right now that you need?)*
      Put it in core, so that as a plugin developer I can make use of it in my products. I built the most popular Restaurant Reservations plugin in the .org repo, and I am eager to add a robust capacity/table management component for it using the REST API and a jQuery/Underscore/Backbone stack.

      *What improvements would you like to see? (What sucks?)*
      (ahem) https://github.com/WP-API/WP-API/issues/660 ๐Ÿ™‚

      *Is the API important to you?*
      Yes. As my skills improve with frontend technologies the relevance and utility of WordPress’s PHP-based templating system is waning. It’s still handy to have around, and it won’t be going away in the product space. But nearly every interesting personal project I dream up these days requires less and less of a WP frontend.

      *Anything else youโ€™d like to tell us?*
      Thanks to everyone pushing this forward. I really don’t want to have to go learn Laravel. ๐Ÿ˜‰

    • divydovy 8:14 am on July 23, 2015 Permalink | Log in to Reply

      Thanks Ryan.

      _What are you doing with the API?_

      Our biggest project with it is this: https://www.joininuk.org/widget/ – an embeddable JS widget.

      _What would you like to do with it? (How can we make it better for you? What canโ€™t you do right now that you need?)_

      So much we’d like to do, haven’t hit any limits except finding clients that have requirements to use it.

      _What improvements would you like to see? (What sucks?)_

      Nothing so far

      _Is the API important to you?_

      Yes, very.

      _Anything else youโ€™d like to tell us?_

      You’re doing a fabulous job.

    • Benjamin Lupu 8:29 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      I have use it in some of my projects (media sites) but mainly experimenting with it.

      I am also part of the team developing WP-AppKit, a plugin to create mobile apps connected to WordPress. At the moment, we use our own JSON API. The only reason is because we wait for it to be part of the core..

      Anything else youโ€™d like to tell us?
      The WP API is a cornerstone of the future of WordPress. WordPress has grown because of its user friendliness, ease of access, extendability… It is and it will remain a major asset. But at the same time, WordPress has struggled to step in the enterprise world. It struggles to connect with other major technical groups. Yes it happens more and more but too often it almost sneaks in enterprises and agencies. We want the non-WordPress world to interact with our favorite tool and the WP API is key to that. Yes it can be done with the API as a plugin but it would send a bad message out there. The API in core is the way to ensure a standard way that interact with WordPress. It is also a huge asset to make the best mobile and SaaS backend in the world! As we have democratized publishing, we will use the WP API to ease the pain of creating mobile apps (with the help of other wonderful open source technologies such as Cordova) and SaaS products. I can imagine numerous use cases for it. All WordPress developers around me are experimenting with the WP API. And beyond them, more and more non-WordPress developers are experimenting with the WP API. This is the first time I feel that we are maybe at the dawn of connecting with outside technical islands.

      So, please don’t let this happening, it would be a very sad day for WordPress: the WP API has to be in core.

      I’d like to thank the team behind it. It’s a huge achievement. I am also wondering what kind of message to the community it could be to finally close the core door after this amount of dedication (?).

    • Van Patten Media 11:31 am on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      For a client site, in production, we’re using the API (v1.x) to power infinite scroll. We’ve also extended it to support accessing specific sets of custom post type data to power a special section of the site that displays content using special editorial-organised collections of posts.

      I also extended v2.x for a personal project to essentially power an iOS app, with extensions for registration, creating/responding to ‘questions’ (via posts and comments), and a payment endpoint with Stripe. Built a custom JSON web token auth method as well.

      What improvements would you like to see? (What sucks?)

      It’s something that I’m sure will change once the API moves closer to core, but the documentation is kinda weak, particularly in the “here’s how to accomplish Thing X” tutorial scenario. Reading the code is obviously great, and helps a lot, but there is a lot of power buried in the plugin that isn’t really explained anywhere yet.

      Is the API important to you?

      Very! It saved a ton of dev time.

      Anything else youโ€™d like to tell us?

      Keep it up!

    • Per Soderlind 1:16 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      We’re using WordPress and the REST API as an backend for an iOS application. The iOS app is an “what to do when shit happen” app for the Norwegian Ministry of Petroleum and Energy.

      What would you like to do with it?

      We’re working on several other projects that uses the REST API

      What improvements would you like to see?

      Nothing so far (access to options would be nice)

      Is the API important to you?

      Yes

    • ndh01 1:21 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      Iโ€™m currently building a few iOS apps that connect to my site https://focusedonfit.com The apps use the API to pull CPTs with tons of meta, BuddyPress info, and custom DB tables. I hope to have these launched by the end of the year and beta in the next few months. I had fantastic help getting my API customization developed by Daniel Bachhuber and Rachel Bakerโ€” they were a pleasure to work with! I also used the API to create my app Simply Smoothies https://itunes.apple.com/us/app/simply-smoothies-smoothie/id975605998?mt=8&uo=6&at=1001l3mn&ct=wp Although Iโ€™m not using the API in the compiled app, I used it to seed my initial database of 130+ ingredients with full nutritional information (pulled from https://focusedonfit.com) that make up the app. It saved me a ton of time ๐Ÿ™‚

      What improvements would you like to see? (What sucks?)

      Like most projects that are in development, the documentation needs improvement. I would also like to see some docs written on how to migrate from 1.x to 2.x. Iโ€™m currently on v1.x.

      Is the API important to you?

      Very important as it has jumpstarted my backend development and laid the groundwork for future features and connectivity.

      Anything else youโ€™d like to tell us?

      Thanks for all your hard work!

      • Paul Gibbs 1:42 pm on July 23, 2015 Permalink | Log in to Reply

        If you wrote any sufficiently generic BuddyPress WP-API stuff, I’d love to see it?

        • ndh01 2:17 am on July 24, 2015 Permalink | Log in to Reply

          Hey Paul, I don’t have anything generic. It has been written specifically for the site. Currently simple BP stuff like read/write user fields. The site currently uses friends/profiles/activity components, but I don’t plan on adding that to app in the first version.

    • Preetinder 1:46 pm on July 23, 2015 Permalink | Log in to Reply

      Hi Ryan,

      Thank you for asking these questions ๐Ÿ™‚

      It will be great if this can be included in Core with some improvements and more/new features. Following are my comments on your queries.

      What are you doing with the API?

      We are using it for exposing data / posts to our Android App and it works great (with some changes in the plugin code). We are using Taxonomy, Custom post types, several custom fields and then exposing all this data for consuming into Android App.

      What would you like to do with it? (How can we make it better for you? What canโ€™t you do right now that you need?)

      We plan to use it on most WordPress applications (business directories, event sites, yellow pages type sites) we build. Also please see the response to next question.

      What improvements would you like to see? (What sucks?)

      We had to make some changes into plugin files for exposing custom fields. Also as WP query doesn’t allow query on custom meta key / values, we changed that bit as well to get it to work.

      I suggest that we give users some interface where they can select which custom post types / fields they would like to be available via API. Also options for on which custom fields they would like to query and then these can be included in the code.

      Is the API important to you?

      Yes, It is very important and holds great promise with some improvements suggested above.

      Anything else youโ€™d like to tell us?

      We are very pleased with the outcome and are planning to build another website and App using same procedure.

      Our team is also working on a session on using REST API for next wordcamp happening in Pune.

      Thanks,
      Preetinder

    • jrvandijk 2:43 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      I’m running the API behind a mobile app implementation. The mobile app is built using Titanium which uses Backbone.js as its way of syncing. The connection the the WordPress API is a breeze!

      What would you like to do with it? (How can we make it better for you? What canโ€™t you do right now that you need?)
      In my situation, WordPress as just a storage, it’s feature complete. In regards to authorisation, support for oAuth2 would be welcome. A plugin with a dependency onto http://oauth2.thephpleague.com would be awesome.

      What improvements would you like to see? (What sucks?)
      The only improvement that can be made, is to make it part of the core! ๐Ÿ™‚

      Is the API important to you?
      Yes it absolutely is. Working with API’s is more easy for me then working with WordPress in general. WordPress is a specific product, whereas API’s have become more & more standardised. Thank you for your hard work!

    • Jason Coleman 4:15 pm on July 23, 2015 Permalink | Log in to Reply

      > What are you doing with the API?

      Not much yet.

      > What would you like to do with it?

      I’m really waiting for the API to be “blessed” and incorporated into WP core. Once that is done, we plan to add custom methods to Paid Memberships Pro using the API. We already have a few for the XMLRPC API, but we will add even more to control as much as possible in the PMPro data via API.

      The reason we are waiting for this to be in core is because maintaining a plugin of this size against WP Core, all of the gateways, and all of the third party integrations is already a daunting task. When gateways and thirdparty tools update THEIR APIs, we need to update our code. If in the future, the standards on building/using APIs in WordPress were to change, then we would have to change to support that and would have wasted a lot of development time on the API version that wasn’t used. Worse yet, other developers building on top of PMPro will potentially have to update how they do things.

      I’m also co-author of the book Building Web Apps with WordPress. APIs are obviously a big part of application development and we plan to expand on what we cover in the upcoming revision 2. It would be really great to be able to say “this is the one standard for building and using APIs on top of WordPress” instead of something weaker.

      > Is the API important to you?

      Yes.

    • laur3ntv 4:33 pm on July 23, 2015 Permalink | Log in to Reply

      Hi Ryan,

      I definitely think the API should be included to core.

      What are you doing with the API?
      >> Nothing for now but we have plans ๐Ÿ™‚

      What would you like to do with it? (How can we make it better for you? What canโ€™t you do right now that you need?)
      >> We plan to use the API in order to create SAAS like services relying on WordPress.

      What improvements would you like to see? (What sucks?)
      >> I am not the CTO so I could not say ^^

      Is the API important to you?
      >> We think it is the future of WordPress because it opens WordPress to SAAS, to mobile apps etc.

      Anything else youโ€™d like to tell us?
      >> Thanks to all the developers who have worked on it. Keep it up!

    • Roy Sivan 5:00 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      I build web (single page) applications powered by AngularJS and other JS frameworks. One example site is CodeCavalry.com. I have a few WordPress plugins that utilize the API as it makes custom endpoints for functionality. I also use the API at my full-time job where we use it for a number of things.

      What would you like to do with it? (How can we make it better for you? What canโ€™t you do right now that you need?)
      It does everything I need – VERY easy to extend, VERY easy to learn and work with. Especially when using in a JS environment.

      Is the API important to you?
      VERY important. I’ve been using it since it was in GSoC. Could not have built

      Anything else youโ€™d like to tell us?
      Keep up the good work!

    • dryanpress 6:35 pm on July 23, 2015 Permalink | Log in to Reply

      > What are you doing with the API?

      Nothing at present.

      > What would you like to do with it?

      Terrific other than access to Settings API for plugins.

      > Is the API important to you?

      Absolutely. Particularly important to the news industry which has notoriously slow sites and needs easier methods to selectively query content as users flow through a session. That’s presumably a contributing reason a number of major publishers (not all) use some form of REST API if they’re using WordPress (Mashable, Wired, Quartz, etc).

      > Anything else youโ€™d like to tell us?

      The REST API…

      • Enables more dynamic, powerful and human interactions with our content and our data. Sites that use it have implemented exciting patterns that aren’t as simple or resource-light in PHP.
      • Opens WordPress to a wider community of developers working on both Core and Plugins.
      • Helps diversify WordPress for longevity.
      • Can only improve the kind of features written for WordPress client mobile apps.
      • Opens door for more mobile apps powered by WordPress.
      • Shines increased value on BuddyPress, maybe.
      • Increases speed, decreases channel interference (reloading requires reorienting), empowers developers and will excite lay users with an improved experiences they’ll have difficulty quantifying but they will “feel.”

      WP.com got a REST API in 2012, clearly it was needed and is still around. Strange conversation to have in 2015 frankly. Even if WP.com/Jetpack adoption was low(?), that would be no reason to reject similar functionality for Core which is naturally a different user base.

      Disappointing talented developers doing good work with the API are being spooked.

    • Jonathan Brinley 6:39 pm on July 23, 2015 Permalink | Log in to Reply

      At Modern Tribe, weโ€™re starting to build some sites that use the REST API to power both Handlebars and full page React templates in our themes. For example, weโ€™ll have a post type loop (letโ€™s say a listing of Publications) to which weโ€™ll add optional filters for taxonomy terms, P2P relationships, etc. Screenshot: https://cloudup.com/coGx9enyOhp The initial page render includes the search and filter fields. The posts come from ajax requests to the REST API, and update when filter selections change.

      Some particular challenges weโ€™ve faced:

      1. Querying on multiple terms from multiple taxonomies. We worked around this by setting up our own query var and building the supporting queries.

      2. Related post data. P2P relationships are integral to many of our content types, and we need to display information about the related posts as part of the main post type loop. Rather than making separate requests, we include the related post objects as properties of the main post objects in the response.

      3. Access control. Some posts (and even some specific meta fields) have access restrictions (e.g., you have to be logged into view it, or have a certain role, etc.). We have to make sure that these restrictions carry over to the JSON response, as well, giving one response to the public and another to authenticated users.

      4. Caching. Building up the JSON responses with related post data, access control for certain fields, etc., can be slow and requires a lot of queries. We were able to speed this up substantially by caching the post objects (complete with all of their meta and related post data) in a new database table (with separate caches maintained for each access role). This leads to the question of cache invalidation, which we solved with another table of invalidation triggers. When a post in this latter table is updated, it triggers an invalidation of the cache in the former table to ensure that all of our related post data remains fresh.

      Additional challenges weโ€™re still working out:

      1. Multisite usage. Weโ€™re just now starting to experiment with the API with multisite installations. Seems to have some quirks that weโ€™re working to identify and mitigate. Would also be interested in experimenting with the API to perform queries that span multiple sites.

      2. Theme Customizer and Admin UI. The WP Core team is thinking of powering the whole Admin UI with the WP REST API or some variation of it. That would open the door to making the Admin UI and the Theme Customizer โ€œmodernโ€ web-application like environments. The UX gap between the Theme Customizer as it is and the Admin side is already apparent: that will likely widen in the future. Think of a React (or whatever is โ€œa la modeโ€ at the moment) powered panel builder or Admin UI.

      3. The Events Calendar. As we build solutions for client sites, weโ€™re also thinking about how we can start adding support for the REST API into our open source plugins. Weโ€™re in the early stages of determining how that integration might work, both for reading and authoring events.

      4. Tailoring the API Response. It would be nice to have a method to remove unused data from the response, if possible.

    • Ken Newman 7:23 pm on July 23, 2015 Permalink | Log in to Reply

      Hi, I’ve used the API to build a very simple Angular App that was basically a portfolio of galleries. It was extremely simple to do (as it was read only).

      My coworker is building a Meteor.js subsite to a WordPress powered main site, and authentication could certainly be easier (no command-line support on our server configuration for example) and tutorials are sparse (tho I do understand that this is because of the newness of the project).

      What I’d like to do is exactly what Ryan McCue is doing in his two project examples. ๐Ÿ˜‰

      In my second job, our workflow is incredibly dependent on this API going forward, as just about everything we’ve been planning to do takes advantage of the API…

      Also want to say, Great Job Rachel, Ryan, Daniel, and Joe and everyone else! You are awesome beyond belief!

    • Ashworth Creative 7:27 pm on July 23, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      Powering interactive calendars and timelines; allowing downloadable software to consume and update highly customized data that is stored in and managed by WordPress as purely a CMS; transmitting data across domains so that dedicated mobile sites could pull content from main sites, preventing redundancy.

      What would you like to do with it? (How can we make it better for you? What canโ€™t you do right now that you need?)
      The biggest issue right now is that the REST API isn’t included in core. If we build plugins or a theme that needs to consume data asynchronously, we’d either have to bundle the api and have to maintain it in our repositories as a dependency, or have clients install and maintain it on their own.

      What improvements would you like to see? (What sucks?)
      Some form of caching each call along an endpoint. We worked around this on the server level by having Varnish cache everything for an indefinite period, with invalidation occurring via PURGE requests made any time the data was updated. This obviously wouldn’t work on shared hosts.

      Improved user authentication would be nice, especially with regards to caching. The endpoints we needed to cache didn’t require authentication, so we have no workaround for that.

      Is the API important to you?
      Yes, very much so.

      Anything else youโ€™d like to tell us?
      You’re all amazing.

    • Luc Princen 10:47 pm on July 23, 2015 Permalink | Log in to Reply

      We’ve created a Backbone app running medical caretakers can create and edit a profile, so users can search, based on there location. It pulls in data to create a interactive google map. After a click, you end up on a caretaker-profile.

      The fields related to a profile are generated by Advanced Custom Fields, which we also fetch using the API, to build the frontend and edit-screens. Admins can therefor change and update the fields on a profile-page as they wish.

      Editting a profile page is also completely done in javascript. Including inline validation and auto-saving on input-blur. We’ve gotten so much questions about where the save-button was that we finally put up a notice; ” Everything will be saved automatically. Dont’ worry ๐Ÿ™‚ “

    • Lara Littlefield 1:52 am on July 24, 2015 Permalink | Log in to Reply

      What are you doing with the API?

      We’re using it at http://simmerwp.com to help build our own developer APIs, but also help others make cookbooks into mobile apps that they can easily sell, or monetize with app purchases.

      I also wrote about the API and its far-reaching implications for the democratization of a lot of great types of software entrepreneurship, especially in the long term. http://laralittlefield.pub/24-percent-internet-scale-wp-api/

      I love the WP API and was first inspired by it during Scott Taylor’s WordCamp Maine keynote! ๐ŸŽ‰

      Is the API important to you?
      It’s incredibly important, since we’re really focused on building native apps for mobile and the future of the Internet of Things in the kitchen ๐Ÿด

      Anything else youโ€™d like to tell us?
      It’s incredible to be able to witness the incorporation of the WP API into core in such a multi-layered community like this. Thank you so much to the project leads and volunteers, this is awesome open source stuff. Your dedication is truly appreciated. Thank you for being able to do what you do during your jobs during the “day” while also dedicating so much time to the future WordPress.

      • Lara Littlefield 3:08 pm on July 26, 2015 Permalink | Log in to Reply

        I want to also add that we’re going to put WordPress in every kitchen in the world as part of the future Internet of Things. We can only do that with the WP API.

        As the number of user interfaces in every human’s life continues to grow, we’re going to be there to make sure that in the kitchen they are open source, standardized, and follow a lot of the core philosophies of WordPress (80/20, lean, etc…)

        This is all coming together in a blog post that will be published this week. I’ll update this post when it’s released โ˜บ๏ธ

      • Lara Littlefield 2:27 pm on July 28, 2015 Permalink | Log in to Reply

        Hi again! I just published a blog post on the future of the Internet of Things, open source, and the WP API as a way to express the many ways in which it will be used. This post focuses on the kitchen, but as you can surmise, the benefits will spread to cars, and many other uses for the home, too.

        http://laralittlefield.pub/wordpress-iot-kitchen/ ๐Ÿด

    • Michael Beil 3:56 am on July 24, 2015 Permalink | Log in to Reply

      We are using it in Lasso and Nick Haskins is running the API on WP Live Search.

      I’ve also been working with Roy Sivan on a plugin that could be using the REST API in the future.

      Josh Pollock has some great work that he has introduced to me regarding the REST API as well.

      Needless to say, I would love for the REST API to be included in core, as was the expected outcome of all the work being done over the past few years. I think the overall market share for WordPress can be increased with the introduction of this REST API.

      Thank you to Ryan, Rachel, Daniel, Joe, and the rest of the team for all of your hard work.

    • Martin Sotirov 6:47 am on July 24, 2015 Permalink | Log in to Reply

      I am gonna be building a client project with the API in the coming month. It’s gonna be a mostly static portfolio site with dynamic SPA-like content loading. Still haven’t decided on whether to use Backbone or React for the front end. I’m going to run some tests first to see which fits better in my desired approach โ€” I want to have server side rendering by PHP for SEO purposes and to still use many of the WP templating functions, especially in the header and footer parts.

    • Dave Navarro, Jr. 2:48 pm on July 24, 2015 Permalink | Log in to Reply

      Item #1 – I built an Advertising Management platform using Custom Post Types and the REST API. It allows our sales people to sell ads for our web sites and manage them all from a single central web site. I have a companion plugin that runs on the individual web sites and pulls the ad data using the REST API.

      Item #2 – I manage numerous News web sites for radio stations. When ever a reporter posts a story on their web site, the post is copied to a central web site using the REST API. It then becomes available via a TinyMCE button to insert stories from the central web site. Kind of a mini-newswire between all of our sister news stations around the country. Both content and attachments are copied.

      Item #3 – I’m building a user management system between all of our web sites. Again, using a central web site you can set permissions/roles for each user and that info is copied to all of the child sites. When a user changes their password on any site, it will be updated across all of the sites and we can disable a user’s access to all sites from the central site.

    • Daniel Milner 3:08 pm on July 24, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      I used it recently to power an entire mobile app. Custom Post Types, Pages, Menus, etc are all pulled in to the app to make it completely dynamic.

      What would you like to do with it?
      Additional methods to authenticate with the API would be nice. Like API Keys or something, for times when you want an end user to write data (populate a CPT for example), without the user having an account on the website.

    • jeroensmeets 5:51 pm on July 24, 2015 Permalink | Log in to Reply

      Hi Ryan,

      Great to see the attention the API is getting. I have been using it on several occasions, mostly for client projects.

      Two main types of projects:
      1) copying post data to another site — for the Dutch foundation that organizes the Open Monument Weekend I built a plug-in for cities to copy their list of participating monuments and activities to their own site (for one city, that is). It uses WordPress ids to control if a post is new or updated from last year, and can build an archive per year.
      2) enabling search in a custom built search page or app. For these types of data access I find the current API code too slow, and I tend to replace this with e.g. Elastic Search.

      My main concern for the API at the moment is speed and caching, esp. when getting data from it. Much slower than the site itself and extra steps are needed for production.

      Debugging can be trying at times, so some attention to this would be helpful.

      I seem to remember I found myself in need of extra filtering options during the building of my last project. As I’m on holiday right now, I’d have to check when I return home.

      Found this post through the wptavern article, and will subscribe to this blog. Thanks! The API is already really useful and I hope to see it grow to core soon.

    • Ahmad Awais 12:32 am on July 25, 2015 Permalink | Log in to Reply

      I’ll keep it short.

      What are you doing with the API?
      Right now I am playing around with it, learning it by reading the source and about a few weeks shy of working out a module. E.g. here is an example here is a jQuery way of fetching posts and building a simple CMS agnostic Widget (http://codepen.io/ahmadawais/pen/aORdVV)

      What would you like to do with it? (How can we make it better for you? What canโ€™t you do right now that you need?)
      Well, right now with two versions in place there is a bit of a mess around what to do what not to do. oAuth needs a lot of improvement and there is definitely pretty little documentation.

      What improvements would you like to see? (What sucks?)
      First of all there should be SOPs so that we could start thinking of doing stuff on a commercial scale. Then there is documentation.

      Is the API important to you?
      Yes, it really is! It should be included in the core as soon as possible. We all can agree on the advantages it can bring to WP community. If it is not in the core, it ain’t an API. To help build commercial apps/plugins with it, we need it to be in the core.

      Anything else youโ€™d like to tell us?
      I’d like to thank Ryan, Rachel, Daniel and Joe and everyone else involved in this project for making it possible. I think WordPress API is the first step towards THE NEXT WordPress.

    • LumberHack 6:53 pm on July 25, 2015 Permalink | Log in to Reply

      Here is my 2 cents.

      I’m usually a fence sitter but this discussion was too important for me to keep quiet. The API is really important and useful if you ask me. I build mobile apps and without this I cant imagine the extra work I’d need to put in to get the same functionality working.

      As a developer / power user of WordPress I think this is invaluable and a move in the right direction. I can see WP integrating nicely and playing well with a lot of the other platforms out there. It should be included in the core soon.

      What improvements would you like to see?

      Cache
      OAuth improvements.
      Docs
      Perfomance improvements

    • Luis Rodrigues 1:41 am on July 27, 2015 Permalink | Log in to Reply

      We’re using the WP REST API on a number of client projects, where we have it powering native mobile apps, live search features and even a (sometimes offline) slideshow application for videowalls.

      We’ve also created B3, a Backbone.Marionette-based starter theme that uses the WP REST API. It’s still using v1, but we’ll be transitioning to v2 now that it’s stable. Github: https://github.com/B3ST/B3. Demo: http://demo.beebeebee.be.

      There’s a handful of features we needed for B3, like menus, widgets, access to (a limited set of) options, as well as permalink settings, but that didn’t stop us: we simply added support for those via a plugin. And so, because the API is so easy to extend, I would probably set aside new functionality to focus on security and performance for a while.

      I think this API is really important for the future of WordPress. Leveraging JS on the frontend is just one of its most obvious applications, and certainly the way forward, but there’s immense power waiting to be tapped if you’re integrating with different platforms in the enterprise or on the internet at large.

      Kudos to the team! Looking forward to seeing the API in the core!

    • Matt 1:25 pm on July 28, 2015 Permalink | Log in to Reply

      I’m using the Rest API to build a completely Angular driven front end where WordPress is used for cms and admin. The biggest thing that’s missing is better support for Posts to Posts, but that is also a WordPress issue.

      This api is very important and is the only reason this app is being developed on WordPress.

      Thanks team!

    • Doug Smith 3:53 pm on July 28, 2015 Permalink | Log in to Reply

      We’re using the API to integrate a custom Rails app with our users and data in WordPress, bbPress, and WooCommerce. Some of the big benefits are single sign on and one page account management for everything.

      As others have mentioned, I’m also wishing for oAuth2.

      A big thank you to everyone working on the API project! It is making possible many things that I’ve wanted to do for a long time.

    • aaronsmulktis 1:49 am on July 29, 2015 Permalink | Log in to Reply

      I’m using it to build a node webapp editorial media site for GaloreMag.com. I’m also going to use it to pull profiles & posts from custom taxonomy/endpoints/routes thru the WP-API for the separate social media talent agency KittenAgency.com

    • amando96 7:31 am on July 29, 2015 Permalink | Log in to Reply

      I’m currently using it to power my personal website, as it currently is an angular SPA, but I want to integrate wordpress for the backend, this API makes it possible. I’m also using it at work for some things I can’t disclose fully ๐Ÿ™‚

    • borekb 9:00 am on July 30, 2015 Permalink | Log in to Reply

      We’re utilizing the API as a “server-side” to our React-based admin screens in VersionPress v2. We’re not using the default endpoints and have built a couple of custom ones that map to a functionality in our UI.

      What we like about the API is that it is (or will be) a standard for client-server communication in WordPress, and it also solves things like authentication for us.

      What we don’t like is that it is still not official / stable yet ๐Ÿ™‚ Just kidding, I know you guys are doing what you can and this is an amazing effort for the future of WordPress.

      BTW, the API *needs* to be in the core for one simple reason: WordPress has no dependency management between plugins. We need to be very “creative” at the moment if we want to depend on the REST API, and we don’t like that.

    • Tanner Moushey 10:40 pm on July 30, 2015 Permalink | Log in to Reply

      I’m just created a study builder for a new SaaS I’m launching and am using the WP API with Backbone.js to handle the functionality (I have a demo video posted at https://studychur.ch).

      I love the concept of the WP API and think it is essential to anyone building an app or SaaS with WordPress. +1 for including it in core!

    • Ella Iseulde Van Dorpe 11:25 pm on August 6, 2015 Permalink | Log in to Reply

      I can’t wait to see the API in core. I’ve played with it a while ago and used it to make a custom admin.

      Problems I’ve faced:

      • Shortcodes. Even when converted, they usually don’t contain all the information necessary to render the content (scripts). This will be an issue for any theme that wants to use the API.
      • Auto-p. It’s not possible to get raw *HTML* content from the API. Saving content in a paragraph-less format will be the developer’s responsibility.
      • Gary Pendergast 12:11 am on August 21, 2015 Permalink | Log in to Reply

        Shortcodes are a tricky problem. The WP.com has partially solved it with the /shortcodes/render endpoint, but that’s used for creating wpView-like embeds, it doesn’t really help for full posts.

        Can you clarify what you mean about auto-p? The posts API responds to either the “view” or “edit” context, which should give you auto-peed or un-auto-peed content, respectively. Is there another format you need?

    • Stew Dellow 2:30 pm on August 28, 2015 Permalink | Log in to Reply

      What are you doing with the API?
      I’m building an idea that I wanted to use WordPress for because I love it and there is bunch of stuff that WordPress can do way better than I could build. I also wanted to use WordPress custom post types and meta data (albeit with some additional data stored in a separate mySQL table). That said I’m not interested in using the WordPress theme system. I am building my own SPA frontend using Backbone / React etc and therefore pulling in the data via the REST API.

      Additionally my plan is to build an iOS app to compliment the web app, which would also pull the data from the API.

      I’ve also got another 3 ideas I want to run with after this that will incorporate a similar structure.

      What improvements would you like to see?

      • I need the ability for non-admins to allow creation of meta data. I’m currently having to workaround this with an Ajax call to a PHP file to perform this operation. I raised a GitHub issue on this here: https://github.com/WP-API/WP-API/issues/1423
      • Would like the ability to update user meta from the API too.

      Is the API important to you?
      Yes. Very. I think it’s one of the major things that sets WordPress apart from it’s competitors and is the correct path for the evolution of CMS’s.

    • jbthechamp 2:30 am on September 4, 2015 Permalink | Log in to Reply

      I believe that the rest api could become the next ios and android market however the limits need to be lifted. Think outside of the WordPress box and think about the amazing rest api(s) that google has developed and if the wp rest api could become core and allow for either server or client side implementation outside of the WordPress realm, then the sky is the limit. The “mashups” as I like to call them would be endless, and simple! Not complex and take weeks to develop. It could cut production time down to almost no time at all if it would just move outside of the WordPress box! Instead of having to implement node or backbone, or nix packages to run your json code, the wp rest api could do it all. Plugins, themes, mysql db replication and high availability would be super easy. I will tell you this, PHP is hard, one wrong move and novices will destroy their work over something a more experienced user could fix in a few minutes. The rest api needs to become the tasks that novices to advanced developers attempt to implement via php and honestly needs to become the “backbone” of wordpress. No pun intended :=). [signature with URLs removed]

  • Ryan McCue 5:05 am on April 29, 2015 Permalink
    Tags: ,   

    WP REST API: Version 2.0 Beta 1 

    Hi there, we’re the REST API team. You may remember us from such releases as Version 1.1 “Hammock Hut” and Version 1.2 “S-M-R-T”. Today, we’re excited to announce the first beta release of version 2 of the REST API: 2.0 Beta 1 “Ralph Wiggum”. Go and grab it from GitHub right now, we’ll wait.

    Over the past 9 months, we’ve been reworking some of the important internals of the REST API to improve extensibility for site developers, and usability for both plugin developers and client developers. We’ve codified some of our important internal conventions, added plenty of new tools for you to play with and simplify your development, and reworked some of the less fantastic parts of the API. We think these changes will make the API a whole lot better for everyone, and we’re excited to start getting your feedback on these changes.

    One of the things that you’ll notice immediately when using version 2 is just how much hasn’t changed. There’s a lot of things that we’ve changed under the hood, but the fundamentals of the API haven’t changed up too much. Version 2 is a direct continuation of version 1, so most of the API will be instantly familiar to you if you’ve used version 1 before. We have a primer on the important changes since version 1, including a guide on migrating existing endpoints across to version 2.

    Here’s some super important notes on version 2, before you get started:

    • No Backwards Compatibility: Version 2 is not backwards compatible with version 1. We have plans to ensure that a version 1 compatibility layer exists, but we’ve leaving that until the API has settled down fully before creating that. However, porting endpoints is easy if you want to give it a go.
    • No Forwards Compatibility: Beta 1 is also not guaranteed to be forwards compatible with future betas. Although this is a beta release, it’s still likely that parts of the REST API will change. However, at this point, the core infrastructure of the API is unlikely to change in a breaking manner, so internal plugin APIs are pretty solid. We reserve the right to break these in future though, so keep that in mind when updating.
    • Development Only: Due to the lack of forwards and backwards compatibility, we strongly recommend you do not run the beta in production environments. While it is possible to run it (both security and privacy have solid, thorough handling), any updates will likely break your site.
    • Run Concurrently: You can easily run both version 1 and 2 side-by-side, since the prefixes for all functions and filters have changed. This will require changing the URL for version 2 however, which can be done with the following filter:
      add_filter( 'rest_url_prefix', function () { return 'wp-rest'; } );

    With all this said, we’d love you to test the plugin as soon as possible. We’re looking for feedback on every part of the API, especially the changes since version 1. If there’s anything that has made it easier or harder since version 1, let us know. We’re continuing to improve the API every day, and now is the time to let us know what’s important to you. (P.S. Did I mention we have an issue tracker?)

    We’re excited for this new stage of the API, and we hope you are too.

     
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