WordPress.org

Make WordPress Core

Updates from Ryan McCue Toggle Comment Threads | Keyboard Shortcuts

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

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

     
  • Ryan McCue 1:02 pm on July 26, 2014 Permalink
    Tags:   

    JSON REST API: Version 1.1.1 (Security Release) 

    I’d like to announce the availability of version 1.1.1 of the JSON REST API. This is a security release for a minor security issue, however we recommend all users running 1.1 upgrade as soon as possible.

    This release only affects users running WP API on a domain with other (non-WordPress) software running. Using the JSONP support built-in to the API, it is possible to serve up arbitrary Flash SWF files from the API, allowing these Flash files to bypass browser cross-origin domain policies. While WordPress includes built-in CSRF protection, other software running on the same domain may not include similar protections.

    As a workaround, JSONP support can be disabled on your site with:

    add_filter( 'json_jsonp_enabled', '__return_false' );

    Thanks to @iandunn for reporting this issue to the team responsibly.

    We’d also like to announce that WP-API is now available on HackerOne. We invite security researchers and developers to report any potential security issues to us via HackerOne, allowing us to triage and fix issues privately, and also award bounties for valid security reports.

     
    • Leo Baiano 2:07 pm on July 26, 2014 Permalink | Log in to Reply

      Congratulations, very good this work. Começcando am exploring this plugin and am having good results, then I will be more intimate and who knows the code can not work: D

  • Ryan McCue 2:01 am on June 23, 2014 Permalink
    Tags:   

    JSON REST API: Version 1.1 

    I’m happy to announce the availability of version 1.1 of the JSON REST API.

    This release is a bit of a smaller, more focussed release as we work on increasing test coverage and squashing bugs. Here’s the juicy details:

    • Add new routes for taxonomies and terms.

      Taxonomies and terms have now been moved from the /posts/types/<type>
      namespace to global routes: /taxonomies, /taxonomies/<tax>,
      /taxonomies/<tax>/terms and /taxonomies/<tax>/terms/<term>

      Test coverage for taxonomy endpoints has also been increased to 100%.

      Deprecation warning: The /posts/types/<type>/taxonomies endpoint (and
      sub-endpoints with the same prefix) have been deprecated in favour of the new
      endpoints. These deprecated endpoints will now return a
      X-WP-DeprecatedFunction header indicating that the endpoint should not be
      used for new development, but will continue to work in the future.

      (props @kadamwhite, @rachelbaker, @rmccue, #198, #211)

    • Allow customizing the API resources prefix

      The API base (typically wp-json/) can now be customized to a different
      prefix using the json_url_prefix filter. Note that rewrites will need to be
      flushed manually after changing this.

      (props @ericandrewlewis, @rmccue, #104, #244, #278)

    • Give null as date for draft posts.

      Draft posts would previously return “0000-00-00 00:00:00” or
      “1970-01-01T00:00:00”, as draft posts are not assigned a publish date. The API
      now returns null where a date is not available.

      Compatibility warning: Clients should be prepared to accept null as a
      value for date/time fields, and treat it as if no value is set.

      (props @rmccue, #229, #230)

    • Fix errors with excerpt.

      Posts without excerpts could previously return nonsense strings, excerpts from
      other posts, or cause internal PHP errors. Posts without excerpts will now
      always return an excerpt, typically automatically generated from the post
      content.

      The excerpt_raw field was added to the edit context on posts. This field
      contains the raw excerpt data saved for the post, including empty
      string values.

      (props @rmccue, #222, #226)

    • Only expose email for edit context.

      User email addresses are now only exposed for context=edit, which requires
      the edit_users permission (not required for the current user).

      The email address field will now return false instead of a string if the
      field is not exposed.

      (props @pkevan, @rmccue, #290, #296)

    • Correct password-protected post handling.

      Password-protected posts could previously be exposed to all users, however
      could also have broken behaviour with excerpts. Password-protected posts are
      now hidden to unauthenticated users, while content and excerpts are shown
      correctly for the edit context.

      (Note that hiding password-protected posts is intended to be a temporary
      measure, and will likely change in the future.)

      (props @rmccue, #286, #313)

    • Add documentation on authentication methods.

      Full documentation on authentication
      is now available. This documentation explains the difference between the
      various available authentication methods, and notes which should be used.

      (props @rmccue, #242)

    • Include new client JS from github.io

      The WP-API Javascript library is now loaded dynamically from
      wp-api.github.io to ensure it is always up-to-date.

      (props @tlovett1, #179, #240)

    • Don’t allow setting the modification date on post creation/update.

      As it turns out, WP core doesn’t allow us to set this, so this was previously
      a no-op anyway. Discovered during test coverage phase.

      (props @rachelbaker, @rmccue, #285, #288)

    • Check post parent correctly on insertion.

      Posts could previously be added with an invalid parent ID. These IDs are now
      checked to ensure the post exists.

      (props @rmccue, #228, #231)

    • Make sure the type is actually evaluated for json_prepare_${type} filter.

      This value was previously not interpolated correctly, due to the use of the
      single-quoted string type.

      (props @danielbachhuber, #266)

    • Return WP_Error instead of array of empty objects for a revisions
      permissions error.

      Previously, when trying to access post revisions without correct permissions,
      a JSON list of internal error objects would be returned. This has been
      corrected to return a standard API error instead.

      (props @rachelbaker, @tlovett1, #251, #276)

    • Flip user parameters check for insert/update.

      Previously, you could add a user without specifying username/password/email,
      but couldn’t update a user without those parameters. The logic has been
      inverted here instead.

      (props @rmccue, #221, #289)

    • Add revision endpoints tests

      (props @danielbachhuber, @rachelbaker, @rmccue, #275, #277, #284, #279)

    • Add post endpoint testing

      Now at >54% coverage for the whole class, and >80% for the main methods. This
      figure will continue to rise over the next few releases.

      (props @rachelbaker, @rmccue, #99)

    • Separate helper functions into global namespace.

      WP_JSON_Server::get_timezone(), WP_JSON_Server::get_date_with_gmt(),
      WP_JSON_Server::get_avatar_url() and `WP_JSON_Server::parse_date() have
      all been moved into the global namespace to decouple them from the server
      class.

      Deprecation warning: These methods have been deprecated. The new
      json_get_timezone(), json_get_date_with_gmt(), json_get_avatar_url() and
      json_parse_date() methods should now be used instead.

      (props @rmccue, #185, #298)

    As always, we’ve got a full list of all the changes and a longer changelog. Here’s who contributed to this release:

    $ git shortlog 1.0...1.1 --summary
         8  Daniel Bachhuber
        12  DrewAPicture
         3  Eric Lewis
         2  JDGrimes
         9  K.Adam White
        54  Rachel Baker
       128  Ryan McCue
         4  Taylor Lovett
         1  jeremyfelt
         1  pkevan

    Version 1.2

    We’ve already started work on 1.2, and as always, we’re looking for help!

    With version 1.2 and onwards, we’ll be tackling a bunch of extra testing for our endpoints, with the aim of eventually reaching >90% coverage. As always, we’ll also be adding new features and fixing bugs.

    We’re also working on improving the new documentation site, and expect to see the majority of documentation migrated over there. Thanks to Sarah Gooding for helping out on the documentation side.

    Core Integration

    In case you missed it, the API is now slated for integration in WordPress 4.1. WP Tavern has a great writeup on the details.

    As always, we look forward to seeing you at the team o2 and on GitHub. Now’s also a great time to remind you that you can get support for the plugin on WP.org, or by tweeting at me. Thanks to everyone who made this release great, and thanks to everyone using the plugin!

     
    • Ian Dunn 4:14 pm on June 23, 2014 Permalink | Log in to Reply

      Include new client JS from github.io

      Is this intended to be a permanent change? I could be wrong, but I think Core’s policy (and also the wporg plugin directory’s) is that assets should be local.

      (Open Sans is an exception, because it’s very difficult to reproduce everything that Google’s API does locally.)

    • Stephane Daury (stephdau) 6:20 pm on June 25, 2014 Permalink | Log in to Reply

      Awesome work, gang.

  • Ryan McCue 4:45 am on May 25, 2014 Permalink
    Tags:   

    JSON REST API: Version 1.0 

    I’m incredibly excited to announce the availability of version 1.0 of the JSON REST API.

    This version is a huge release and introduces a bunch of new features, such as user, revision and post meta endpoints. It also introduces our long-term backwards compatibility policy, aligning with WordPress core backwards compatibility.

    Here’s a selection of the new stuff:

    • Add user endpoints.

      Creating, reading, updating and deleting users and their data is now possible
      by using the /users endpoints. /users/me can be used to determine the
      current user, and returns a 401 status for non-logged in users.

      Note that the format of post authors has changed, as it is now an embedded
      User entity. This should not break backwards compatibility.

      Custom post types gain this ability automatically.

      (props @tobych, @rmccue, #20, #146)

    • Add post meta endpoints.

      Creating, reading, updating and deleting post meta is now possible by using
      the /posts/<id>/meta endpoints. Post meta is now correctly embedded into
      Post entities.

      Meta can be updated via the Post entity (e.g. PUT to /posts/<id>) or via
      the entity itself at /posts/<id>/meta/<mid>. Meta deletion must be done via
      a DELETE request to the latter.

      Only non-protected and non-serialized meta can be accessed or manipulated via
      the API. This is not predicted to change in the future; clients wishing to
      access this data should consider alternative approaches.

      Custom post types do not currently gain this ability automatically.

      (props @attitude, @alisspers, @rachelbaker, @rmccue, @tlovett1, @tobych,
      @zedejose, #68, #168, #189, #207)

    • Add endpoint for deleting a single comment.

      Clients can now send a DELETE request to comment routes to delete
      the comment.

      Custom post types supporting comments will gain this ability automatically.

      (props @tlovett1, @rmccue, #178, #191)

    • Add endpoint for post revisions.

      Post revisions are now available at /posts/<id>/revisions, and are linked in
      the meta.links.version-history key of post entities.

      Custom post types supporting revisions will gain this ability automatically.

      (props @tlovett1, #193)

    • Respond to requests without depending on pretty permalink settings.

      For sites without pretty permalinks enabled, the API is now available from
      ?json_route=/. Clients should check for this via the autodiscovery methods
      (Link header or RSD).

      (props @rmccue, #69, #138)

    • Add register post type argument.

      Post types can now indicate their availability via the API using the
      show_in_json argument passed to register_post_type. This value defaults to
      the publicly_queryable argument (which itself defaults to the
      public argument).

      (props @iandunn, @rmccue, #145)

    • Remove basic authentication handler.

      This breaks backwards compatibility for clients using Basic
      authentication. Clients are encouraged to switch to using OAuth
      authentication
      . The Basic Authentication plugin can be
      installed for backwards compatibility and local development, however should
      not be used in production.

      (props @rmccue, #37, #152)

    • Require nonces for cookie-based authentication.

      This breaks backwards compatibility and requires any clients using cookie
      authentication to also send a nonce with the request. The built-in Javascript
      API automatically handles this.

      (props @rmccue, #177, #180)

    • Clean up deprecated methods/functions.

      Functions and methods previously deprecated in 0.8/0.9 have now been removed.
      Future deprecations will take place in the same manner as WordPress core.

      This breaks backwards compatibility, however these were marked as
      deprecated in previous releases.

      (props @rmccue, #187)

    • Only expose meta on ‘edit’ context as a temporary workaround.

      Privacy concerns around exposing meta to all users necessitate this change.

      This breaks backwards compatibility as post meta data is no longer
      available to all users. Clients wishing to access this data should
      authenticate and use the edit context.

      (props @iandunn, @rmccue, #135)

    • Add json_ensure_response function to ensure either a
      WP_JSON_ResponseInterface or a WP_Error object is returned.

      When extending the API, the json_ensure_response function can be used to
      ensure that any raw data returned is wrapped with a WP_JSON_Response object.
      This allows using get_status/get_data easily, however WP_Error must
      still be checked via is_wp_error.

      (props @rmccue, #151, #154)

    • Use version option to check on init if rewrite rules should be flushed.

      Rewrite rules on multisite are now flushed via an init hook, rather than
      switching to each site on activation.

      (props @rachelbaker, #149)

    As always, you can view all commits or the longer changelog.

    For those interested, here’s the list of contributors to this release:

    $ git shortlog --summary 0.9...
         1  Chris Marslender
         1  Eric Lanehart
         2  K.Adam White
         1  Kat Hagan
         2  Matth_eu
        41  Rachel Baker
       139  Ryan McCue
         5  Taylor Lovett
        10  Toby Champion
    

    There’s a few really important things to note with this release.

    Authentication Changes

    Authentication has changed significantly in 1.0. If you’ve been using Basic authentication previously, you’ll now need to install the Basic authentication plugin. This plugin is designed for local development, as Basic authentication requires sending your plaintext credentials over the wire, which is unsafe for production.

    Production users have two choices: built-in cookie authentication, or OAuth authentication. OAuth 1.0a is an authorization protocol that allows you to authorize clients to act on your behalf, and does not require giving your username and password to the client. It does, however, require a significantly more complicated authentication/authorization process, and clients are required to register on the site beforehand. We’re working on long-term solutions to this.

    Plugins and themes can also use built-in cookie authentication. This is the normal WordPress login process, however requires a nonce for authentication to the site. This is automatically handled for you when using the built-in Javascript client.

    Backwards Compatibility

    From this release forwards, backwards compatibility will not be broken. This includes both the internal PHP API, as well as the REST API we expose. New endpoints may be added, as well as new data, but responses will continue to be supersets of the current response.

    The exception to this is for security concerns. As we continue development, we may need to change some endpoints for security issues, as we did with post meta for this cycle. These will be announced well before release where possible.

    Please note also that this release has removed some previously deprecated methods and changed some internal implementation details. This only affects plugins or themes that extend the API.

    Core Integration

    We’re pushing hard for integration into 4.0 this cycle, and we need your help. Our core integration plan outlines the motivation behind the project and the specific plan for integrating it into core. We’re currently working on a comparison document for the API compared to the WP.com/Jetpack API and others, and will be publishing that soon.

    We need your help to make it into 4.0. Developers, we’d love to know what you’ve built with the API, whether public or internal (even vague details help!), and we’d especially love to see things built with the API. We’re currently in danger of not making it in this cycle, so anything you can do to help us here would be fantastic.

    As always, we’re also looking for help. The main API always needs help, and the other related projects do too. Both the WP-CLI client and Javascript client need help here.

    You’re always welcome over at the team o2, and our next meeting will be at Tuesday, 00:00 UTC; we’d love to see you there. If not, see you soon for version 1.1!

     
    • Nikola Nikolov 7:45 am on May 25, 2014 Permalink | Log in to Reply

      I’ve used the JSON API to make front-end submissions to a budgeting app I did for my family.
      I basically only use it for publishing entries in custom post types. I started using the plugin while it was at .6, or .7, so I had to extend it in order to get the endpoints and post meta handling that I needed, but it wall worked out just great.
      I haven’t had the time to update from 0.8 to the latest version, since I’m not sure how much code I’d have to change and I don’t really have lots of free time these days :)

      But in any case, it saves time(once you have it figured out), it’s reliable, well-written and I personally would love to see it in core. Because if it’s in core, more people would actually use it(which means having a more unified experience for developers). I’m sure almost everyone right now is using one of three methods in order to push/pull data via AJAX:

      • request to /wp-admin/admin-ajax.php
      • request to /wp-content/plugins/…./plugin-ajax.php
      • request to the current url, with a hook on init or something else

      — Nikola

    • Nashwan Doaqan 2:12 pm on May 25, 2014 Permalink | Log in to Reply

      Good work @ryan and all the team.. it’s really a big project :)

    • cemdev 3:17 pm on May 25, 2014 Permalink | Log in to Reply

      Please, please, please let this make it into 4.0. The xml-rpc API is soooooo crap. And insecure. Really looking forward to leveraging a modern, more secure API for our customers.

    • Mikel King 3:21 pm on May 25, 2014 Permalink | Log in to Reply

      Very cool! Thank you @ryan and the whole team I can’t wait to mess around with this! I would love to see a talk on this at WordCamp NYC in Aug…

    • Towfiq I. 3:48 pm on May 25, 2014 Permalink | Log in to Reply

      +1 this SHOULD be in core!!

    • memuller 11:47 pm on May 25, 2014 Permalink | Log in to Reply

      This is really, really impressive. curl’ing those API endpoints is a lot of fun.
      Will surely use in future projects, regardless of its inclusion on core. It’s superior to the Jetpack API, and clearly superior to the default one.

      As Nikola pointed out, the ways currently in use to perform data operations via AJAX are a little awkward. As someone that is frequently sough for WP-related advice, I would *really* appreciate if this was included on core, since them I could teach novices to use it for AJAX calls – if it remains as a plugin, it would be a little irresponsible to do so. I think that’s an important point – experienced developers will always be able to use this API as a plugin, regardless of its inclusion on core; but we can’t expect first-time wordpressers to depend on a plugin; they will just google for the “standard” way of doing things and will stick to it.

      I used to work in a local media conglomerate, heavily dependant on WordPress. At the time, I did a *lot* of integration between WP and other applications – a work that would have been a lot easier if this API already existed; specially since most of those apps were quite RESTfull (rails applications, sinatra and node middlewares and the like). It would have allowed us to keep a higher quality standard on our infrastructure – without it, we did some integrations with the Jetpack API, some with RPC, and some even by mucking with the database directly. This API would have provided us with a way that was so much better and easier than the alternatives, that no developer – regardless of skill level – would have been able to ignore it.

    • Eric Andrew Lewis 2:31 am on May 26, 2014 Permalink | Log in to Reply

      Will there be some kind of versioned usage of the API, so that breaking changes can be made in a new version, but the old version can still be supported?

      • Ryan McCue 4:07 am on May 26, 2014 Permalink | Log in to Reply

        Beau Lebens asked the same over on the o2, here’s my response:

        The plan for versioning, if it’s ever needed, is to use Content-Type headers to indicate the version, much the same way that GitHub versions their APIs. This doesn’t affect the current approach, so it’s not something needed at this point.

        • Eric Andrew Lewis 9:11 am on May 26, 2014 Permalink | Log in to Reply

          B)

        • Aaron Jorbin 6:05 pm on May 28, 2014 Permalink | Log in to Reply

          I don’t like this approach for a couple of reasons. 1) It makes it harder to use tools like Curl for testing. 2) It would make debuging by looking at server logs harder. 3) It also adds a higher barrier to entry for developers as not all developers know how to add headers. Yes this can be solved with education, but I don’t think every problem should be solved with education.

          I think we should add the version string into the url.

          • Mikel King 7:27 pm on May 28, 2014 Permalink | Log in to Reply

            I have to imagine that WP_Http (where adding headers is really rather trivial) is preferred over curl.

            • Aaron Jorbin 7:31 pm on May 28, 2014 Permalink

              I’m was talking about from the command line, not from php. Sorry that wasn’t clear.

    • Eric Lanehart 6:07 pm on May 27, 2014 Permalink | Log in to Reply

      We’ve been using WordPress as an API at sparkart for many of our projects, starting with the Americas Cup (http://sparkart.com/work/americas-cup) in 2012/13. That project used Dan Phiffer’s JSON API plugin in a manner similar to what he built that plugin to do for the MoMA: supply content to a Ruby-based server. Nowadays we use node.js (http://github.com/solidusjs) in the same fashion. This allows us to easily integrate data from other sources and simplify our production and development environments by removing a database dependency. Our production sites are essentially static, fronted by a CDN for fast performance around the world. Unlike static site generators content is refreshed as it expires.

      YoungMoney.com, official site of Lil Wayne, is using the JSON REST API plugin today. All sites in development also rely upon it. We’re actually planning to migrate all content from a legacy, proprietary CMS to WordPress. We began using the plugin as of 0.6, seeing a much clearer future than the existing JSON API plugin and appreciating the thoughtful design behind it. We also considered the Thermal API plugin but found it’s implementation, particularly around media, to be uneven. The response schema also seemed too much of an abstraction.

      This maybe isn’t the most compelling use case since we flout much of the WordPress ecosystem (themes, widgets, plugins, etc). But a new class of CMS’s have emerged in this time (Osmek, Contentful, Prismic.io) that are essentially the same proposition: content management without the presentation layer. The problems they solve around support for mobile apps and other non-browser based environments connected to the web is also tremendously valuable. The Quartz use case along with some examples of similar node.js-fronted sites like the WSJ, other Dow Jones properties, and Artsy have helped validate our approach in my mind. Except unlike Quartz we don’t need expensive WordPress VIP installations to scale to millions of visitors.

      As developers we’re all about the Unix philosophy of small, focused tools. We strongly prefer these tools to be open whenever possible, and this is one reason we continue to use WordPress despite the existence of these services.

    • paulkevan 9:55 am on May 28, 2014 Permalink | Log in to Reply

      Although we (metro.co.uk) haven’t used any the JSON api plugin, due to using WP.com VIP, we have built replica json endpoints so we can consume some of our post meta fields in other applications.

      The other area we use is the XML-RPC endpoints to push in images from our picture management system and as previously mentioned this isn’t the nicest method to use.

      I’d be happy to get involved in the testing of any post meta based endpoints and also the development of the media endpoints, in particular the extending of what data can be send through these endpoints for each media item.

    • K.Adam White 8:44 pm on May 28, 2014 Permalink | Log in to Reply

      We’re using the API as the content backend for an in-development Node.js website and several single-page applications; nothing I can share publicly yet, but the API project was the tipping point that let me convince my colleagues that WordPress was a suitable backend for a non-PHP application. We’re really excited about the work we’re doing and I look forward to sharing it later in the year.

  • Ryan McCue 7:08 am on April 14, 2014 Permalink
    Tags:   

    JSON REST API: Meeting Time Change 

    As announced on the team o2, the meeting time for the API team is changing to Tuesday, 0:00 UTC, in #wordpress-dev.

    This week we’re discussing OAuth (which, P.S., is now available for testing), 1.0 and custom post type data privacy.

    Hopefully I’ll see you there!

     
  • Ryan McCue 2:12 am on April 14, 2014 Permalink
    Tags: , , , symlinks   

    Symlinked Plugins in WordPress 3.9 

    One of the cool little features included with 3.9 is the ability to symlink plugin directories. While it has been possible to symlink plugins in the past, functions such as plugins_url() return the wrong URL, which causes breakage in most plugins.

    In #16953, r27158 and the followup r27999, we corrected this with the help of a new function: wp_register_plugin_realpath(). This function is called automatically during the plugin loading phase, and registers which plugin directories are symlinked, and where they’re symlinked to. This functionality is then used by plugin_basename() (the core of plugins_url(), along with other
    functions) to reverse symlinks and find the correct plugin directory.

    This enhancement means that you can symlink individual plugin directories, or even the whole plugins directory itself.

    For anyone who’d like to use this, keep in mind that there are a few caveats:

    • Single-file plugins are not handled by this code. Any plugins you’d like to symlink must be in subdirectories of the main plugins folder. This restriction is due to the way these paths are registered.

      You can still symlink single-file plugins, however any use of plugin_basename() will be as broken as it was before 3.9. This is not a huge issue, as the main use of this is in plugins_url(), which is not frequently used in single-file plugins.

    • Must-use plugins cannot be symlinked. For the same reasons as single-file plugins, mu-plugins are not handled.

      For anyone using the common pattern of subdirectories within mu-plugins with a common loader file, you can use wp_register_plugin_realpath() directly to ensure that your subdirectories are handled.

      The following example code demonstrates how to use the function:

      <?php
      $plugins = array(
      	'my-mu-plugin/my-mu-plugin.php',
      );
      foreach ( $plugins as $plugin ) {
      	$path = dirname( __FILE__ ) . '/' . $plugin;
      
      	// Add this line to ensure mu-plugins subdirectories can be symlinked
      	wp_register_plugin_realpath( $path );
      
      	include $path;
      }
      

      Hopefully this change is as helpful for you as it was for me! One of the great advantages to this is that plugin developers can keep their plugin separate from their WordPress installation. This is a boon for developers with multiple installs who want to test compatibility; keep in mind that you can symlink the entire plugins directory if you’re testing multiple!

      If you have any questions about this, please leave a comment on this post and we’ll be happy to help you out!

     
    • PeterRKnight 2:29 am on April 14, 2014 Permalink | Log in to Reply

      This is super handy

    • Mike Schinkel 4:25 am on April 14, 2014 Permalink | Log in to Reply

      Kudos Ryan for pushing that feature through.

    • Julien 6:50 am on April 14, 2014 Permalink | Log in to Reply

      That’s great news! Thanks!

    • Fab1en 7:36 am on April 14, 2014 Permalink | Log in to Reply

      Thanks for this Ryan !
      I was using a custom plugin that tweaked `plugin_basename` to make it work with symlinked plugins. Thanks to you, I will not need this plugin anymore !

    • klihelp 12:37 pm on April 14, 2014 Permalink | Log in to Reply

      Thanks for the post.

      >> This is a boon for developers with multiple installs who want to test compatibility
      Tell me more about this.
      Could I read as a multiple WP installs uses the same plugin directory, so you don’t have multiple copies of the plugins?

      • Fab1en 3:42 pm on April 15, 2014 Permalink | Log in to Reply

        yes, that is what you can read ! Just add a symlink to a shared plugins directory in each WP install wp-content folder, and your installs will share the same plugins copy.

    • hinnerk 3:06 pm on April 14, 2014 Permalink | Log in to Reply

      Thanks a lot! Great enhancement! Makes my developer live much easier!

    • Frank 3:18 pm on April 14, 2014 Permalink | Log in to Reply

      Really useful, reduce the custom work.

    • Brian Layman 3:44 pm on April 14, 2014 Permalink | Log in to Reply

      This is a neat little thing. We’d experimented with symlinking the files back in b5media days with our 350ish sites, but there were enough little oddities to make it not the right choice for a poor man’s MU option.

    • Primoz Cigler 5:33 pm on April 14, 2014 Permalink | Log in to Reply

      Very important and useful update. But I have a question: is something like this possible with the themes as well? Would make perfect sense for the same reason, if you are a theme developer: “One of the great advantages to this is that theme developers could keep their theme separate from their WordPress installation. This is a boon for developers with multiple installs who want to test compatibility; keep in mind that you could symlink the entire themes directory if you’re testing multiple!”

      • Ryan McCue 2:12 am on April 17, 2014 Permalink | Log in to Reply

        But I have a question: is something like this possible with the themes as well?

        I can’t think of any issues with allowing this; file a ticket on Trac! :)

    • Primoz Cigler 5:34 pm on April 14, 2014 Permalink | Log in to Reply

      This is very important and useful update. But I wonder if something similar would be possible with the themes too? For the same obvious reasons as for plugins.

    • hinnerk 7:25 am on April 15, 2014 Permalink | Log in to Reply

      I had to add Options +FollowSymLinks to my .htaccess in order to remove a 403 Forbidden on all pages (using symlinks in plugins directory).

    • hinnerk 7:27 am on April 15, 2014 Permalink | Log in to Reply

      I had to add Options +FollowSymLinks to my .htaccess to remove a 403 Forbidden on all pages (using symlinks in /wp-content/plugins/).

    • Todd Lahman 8:45 am on April 15, 2014 Permalink | Log in to Reply

      This is totally awesome!

    • elimc 7:00 pm on April 16, 2014 Permalink | Log in to Reply

      I’m a bit confused about what this future does. Does this allow me to define a constant on my local server that links to the plugin directory on remote sites, thereby, preventing the need to duplicate the same plugins on both the local and remote server?

      • Ryan McCue 2:13 am on April 17, 2014 Permalink | Log in to Reply

        This doesn’t allow you to share plugin files across HTTP, no. It does allow you to have certain plugins live outside of your WordPress content directory, which means you can share the same code between multiple installations on the same server.

    • experiencedbadmom 11:39 pm on April 17, 2014 Permalink | Log in to Reply

      Total newbie here. I blog as a hobby. I do not know code. I updated to 3.9 today and now ALL I get is this error message:

      Fatal error: Call to undefined function wp_register_plugin_realpath() in /home/content/92/8889792/html/wp-settings.php on line 213

      I can’t get to my login page or see my blog anymore. I found this thread by searching “Fatal error: Call to undefined function wp_register_plugin_realpath()”. Any advice would be greatly appreciated to restore my blog! Thank you.

    • satimis 6:14 am on May 1, 2014 Permalink | Log in to Reply

      H all,

      I encountered similar problem on moving a website on Godaddy Deluxe hosting plan to Ultimate hosting plan (the website still works without problem on the former plan)

      On preview after moving
      Fatal error: Call to undefined function wp_register_plugin_realpath() in /home/gopublic2014/public_html/cuisine/wp-settings.php on line 213

      wp-settings.php
      line 213 wp_register_plugin_realpath( $plugin );

      but I couldn’t resolve where to enter;

      <?php
      $plugins = array(
          'my-mu-plugin/my-mu-plugin.php',
      );
      foreach ( $plugins as $plugin ) {
          $path = dirname( __FILE__ ) . '/' . $plugin;
       
          // Add this line to ensure mu-plugins subdirectories can be symlinked
          wp_register_plugin_realpath( $path );
       
          include $path;
      }

      How to change ( $path ) ?

      Please help. Thanks

      satimis

    • styledev 11:39 pm on May 11, 2014 Permalink | Log in to Reply

      I have a local multisite setup and I am symlinking in the entire plugins directory. When I network activate Advanced Custom Fields and go to one of my sites’s ACF Custom Fields page the resource files are still loading in as

      http://oc.flocers.dev/Users/dbushaw/Dropbox/Parapxl/Wordpress/plugins/advanced-custom-fields/css/global.css

      Instead of

      http://oc.flocers.dev/wp-content/plugins/advanced-custom-fields/css/global.css.

      I thought WordPress 3.9 fixed this like you note above?

    • ThreadPasser 10:41 am on June 15, 2014 Permalink | Log in to Reply

      How about when I decide to “remove” the plugin from one install but I want to keep it in the other… will that remove just the symlink (affects only this install) or the entire directory (affects all installs)?

      How about updates which require database changes? Will all this work or is this all very experimental? Or is this just meant to be used by developers and for temporary setups?

      • Ipstenu (Mika Epstein) 4:29 pm on June 15, 2014 Permalink | Log in to Reply

        If you remove the symlink from one install, it won’t impact the others.

        DB changes… should be fine, since the plugin would detect in each install where it’s called what needs to happen.

    • ThreadPasser 6:44 pm on June 15, 2014 Permalink | Log in to Reply

      Thanks for your response, that’s clear (about the DB changes).

      About the symlinks: if an unaware client clicks “uninstall plugin” from backend (just making up a possibly bad scenario), does the wordpress framework automatically detect that it’s a symlink or does it completely uninstall the targetted directory?

    • ScreenfeedFr 3:10 pm on June 25, 2014 Permalink | Log in to Reply

      I’m trying this out and this is great.

      For MU Plugins with the loader file, there’s still a problem: `plugin_dir_url()` won’t work :(

  • Ryan McCue 6:49 am on April 6, 2014 Permalink
    Tags:   

    JSON REST API: Version 0.9 

    Hi everyone! I’m happy to announce that version 0.9 of the JSON REST API is finally available.

    Apologies for the extremely long delay here. I would have liked to ship OAuth authentication with 0.9, and the release was delayed due to that. However, it’s still not in a shippable state, and we’re well overdue for a release.

    Important note: There are backwards compatibility breaks and deprecations in this release. These are all listed before, but exercise caution in upgrading. Backwards compatibility will be maintained from 1.0 onwards only.

    Here’s the big changes:

    • Move from wp-json.php/ to wp-json/

      This breaks backwards compatibility and requires any clients to now use wp-json/, or preferably the new RSD/Link headers.

      (props @rmccue, @matrixik, #46, #96, #106)

    • Move filter registration out of CPT constructor. CPT subclasses now require you to call $myobject->register_filters(), in order to move global state out of the constructor.

      This breaks backwards compatibility and requires any subclassing to now call $myobject->register_filters()

      (props @rmccue, @thenbrent, #42, #126)

    • Introduce Response/ResponseInterface

      Endpoints that need to set headers or response codes should now return a WP_JSON_Response rather than using the server methods. WP_JSON_ResponseInterface may also be used for more flexible use of the response methods.

      Deprecation warning: Calling WP_JSON_Server::header, WP_JSON_Server::link_header and WP_JSON_Server::query_navigation_headers is now deprecated. This will be removed in 1.0.

      (props @rmccue, #33)

    • Change all semiCamelCase names to underscore_case.

      Deprecation warning: Any calls to semiCamelCase methods require any subclassing to update method references. This will be removed in 1.0.

      (props @osiux, #36, #82)

    • Add multisite compatibility. If the plugin is network activated, the plugin is now activated once-per-site, so wp-json/ is always site-local.

      (props @rachelbaker, #48, #49)

    • Add RSD and Link headers for discovery

      (props @rmccue, #40)

    • WP_JSON_Posts->prepare_author() now verifies the $user object is set.

      (props @rachelbaker, #51, #54)

    • Added unit testing framework. Currently only a smaller number of tests, but we plan to increase this significantly as soon as possible.

      (props @tierra, @osiux, #65, #76, #84)

    As always, you can view all changes on GitHub as well as view all closed tickets.

    For those interested, here’s the list of contributors to this release:

    $ git shortlog 0.8... --summary
         1  Aaron Jorbin
         1  Anders Lisspers
         6  Bryan Petty
         1  Dobrosław Żybort
         7  Eduardo Reveles
         1  K.Adam White
        10  Rachel Baker
        41  Ryan McCue
         2  Taylor Lovett
    

    I’m still desperately seeking feedback on our OAuth implementation. This is a hugely important part of the API, and we need to get this nailed down as soon as possible.

    General comments and posts are always welcome on our team o2.

     
  • Ryan McCue 1:54 pm on December 14, 2013 Permalink  

    JSON REST API: Version 0.8 

    Hi everyone! Sorry about the late release, I’ve been a bit sick for most of the week, which has helped my blogging abilities but hindered my coding abilities. In any event, version 0.8 of the JSON REST API is now available.

    As always, here’s what’s changed:

    • Add compatibility layer for JsonSerializable. You can now return arbitrary
      objects from endpoints and use the jsonSerialize() method to return the data
      to serialize instead of just using the properties of the object.

      (props @rmccue, #24)

    • Fix page parent links to use /pages

      (props @thenbrent, #27)

    • Remove redundant WP_JSON_Pages::type_archive_link() function

      (props @thenbrent, #29)

    • Removed unneeded executable bit on all files

      (props @tierra, #31)

    • Don’t include the featured_image property for post types that don’t
      support thumbnails

      (props @phh, #43)

    • Use wp_json_server_before_serve instead of plugins_loaded in the Extending
      documentation for plugins

      (props @phh, #43)

    • Parse the avatar URL from the get_avatar() function in core, allowing custom
      avatar implementations

      (props @rachelbaker, #47, #35)

    • Ensure that the author is set if passed

      (props @kuchenundkakao, #44)

    • Clarify the usage of WP_JSON_CustomPostType in plugins

      (props @rmccue, #45)

    • Ensure JSON disabled error messages are translated

      (props @rmccue, #38)

    • Remove extra “Link: ” from link headers

      (props @jmusal, #56, #30)

    • Remove redundant get_avatar method in WP_JSON_Posts

      (props @rachelbaker, #35)

    • Rename WP_JSON_Server::get_avatar() to WP_JSON_Server::get_avatar_url()

      (props @rachelbaker, #35)

    You can also check out the full list of changes. We had seven contributors to this release, and I’d like to thank everyone who helped us, including creating support issues in the forum.

    The big change this week is the introduction of JsonSerializable support for all versions of PHP. This allows more complex APIs to return full objects and ensure that no data leaks via the API. This should help with reuse of the API internally, as you can now return objects with methods, private data, etc. It’s also a key stepping stone towards adding response objects, which should land in version 0.9.

    For those that have been following along, you may notice that OAuth authentication has been bumped to 0.9. The implementation of OAuth has been a bit of a thorny one, so we’re still deciding some of the implementation for this. Given the size and scope of authentication, we don’t want to rush anything this important. That said, however, I’m aiming to push out both versions 0.9 and 1.0 in the next week to meet our Christmas deadline for version 1.0. This will result in a bit of rescheduling, but shouldn’t be a major concern.

    We’re also desperately seeking help with testing the plugin. Unfortunately, while many of us are familiar with unit testing and can write the tests easily, the framework for doing so is evading us. If anyone can help us set up a testing framework, your help would be greatly appreciated.

     
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