WordPress.org

Make WordPress Core

Tagged: json-api Toggle Comment Threads | Keyboard Shortcuts

  • Rachel Baker 6:03 pm on May 28, 2015 Permalink |
    Tags: json-api   

    WP REST API: Version 2.0 Beta 2 

    A mere four weeks since releasing the first beta of version 2, the REST API team has returned to announce the second beta of version 2 is available. Adding more than forty enchancements and bugfixes, WP REST API: 2.0 Beta 2 “You Finally Made a Monkey Out of Me” is available for download on Github.

    Some important highlights in version 2.0 Beta 2 are:

    • Load the WP REST API before the main query runs.

      The rest_api_loaded function now hooks into the parse_request action. This change prevents the main query from being run on every request and allows sites to set WP_USE_THEMES to false. Previously, the main query was always being run (SELECT * FROM wp_posts LIMIT 10), even though the result was never used and couldn’t be cached.

      (props @rmccue, #1270)

    • Register a new field on an existing WordPress object type.

      Introduces register_api_field() to add a field to an object and its schema. For example, adding a seo_title to all post objects, you provide register_api_field with a callback function to get the value for a post, a callback for updating the value and a schema to describe the field to API clients.

      (props @joehoyle, @rachelbaker, #927)
      (props @joehoyle, #1207)
      (props @joehoyle, #1243)

    • Add endpoints for viewing, creating, updating, and deleting Terms for a Post.

      The new WP_REST_Posts_Terms_Controller class controller supports routes for
      Terms that belong to a Post. You can now remove and add terms on posts (finally!)

      (props @joehoyle, @danielbachhuber, #1216)

    • Add pagination headers for collection queries.

      The X-WP-Total and X-WP-TotalPages are now present in terms, comments, and users collection responses.

      (props @danielbachhuber, #1182)
      (props @danielbachhuber, #1191)
      (props @danielbachhuber, @joehoyle, #1197)

    • List registered namespaces in the index for feature detection.

      The index (/wp-json by default) now contains a list of the available namespaces. This allows for simple feature detection. You can grab the index and check namespaces for wp/v3 or pluginname/v2, which indicate the supported endpoints on the site.

      (props @rmccue, #1283)

    • Standardize link property relations and support embedding for all resources.

      Change link properties to use IANA-registered relations. Also adds embedding support to Attachments, Comments and Terms.

      (props @rmccue, @rachelbaker, #1284)

    • Add support for Composer dependency management.

      Allows you to recursively install/update the WP REST API inside of WordPress plugins or themes.

      (props @QWp6t, #1157)

    • Return full objects in the delete response.

      Instead of returning an inconsistent message when deleting a Post, Comment, Term, or User, the API will now return the original resource data.

      (props @danielbachhuber, #1253)
      (props @danielbachhuber, #1254)
      (props @danielbachhuber, #1255)
      (props @danielbachhuber, #1256)

    View all changes

     
  • Rachel Baker 11:11 pm on May 18, 2015 Permalink |
    Tags: json-api   

    WP REST API: Version 1.2.2 (Security Release) 

    WP REST API versions 1.2.2 and 2.0 Beta 1.1 are now available. These are critical security releases affecting versions 1.2.1 and 2.0 Beta 1.

    On Saturday, the WP REST API team was made aware of an issue where authenticated users were able to escalate their privileges bypassing the expected capabilities check. Thanks to Kacper Szurek (@kacperszurek) 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.2, 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 1 update the plugin immediately.

    Update with one click from Dashboard → Updates, get it from the plugin directory (zip), or pull it from GitHub.

    If you believe you have discovered a potential security vulnerability with the WP REST API, please disclose it to us privately by sending an email to security@wordpress.org. Security issues can also be reported via HackerOne.

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

     
  • Ryan McCue 5:05 am on April 29, 2015 Permalink |
    Tags: json-api   

    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.

     
  • Rachel Baker 8:39 pm on April 9, 2015 Permalink |
    Tags: json-api   

    WP REST API Critical Security Release 

    WP REST API plugin version 1.2.1 is now available as a critical security release. This release fixes a serious information disclosure vulnerability, which allowed for unpublished content and post revisions to be retrieved via the REST API.

    All previous versions of the plugin are affected. All WP REST API users are strongly encouraged to update immediately. Update with one click from Dashboard  Updates, get it from the plugin directory (zip), or pull it from GitHub.

    This release was coordinated by the REST API team and the WordPress core security team. The security team is pushing automatic updates for this plugin. Each branch was separately patched; there are packages for 1.2.1, 1.1.3, 1.0.2, 0.9.2, and 0.8.2.

    If you believe you have discovered a potential security vulnerability with the WP REST API, please disclose it to us privately by sending an email to security@wordpress.org. Security issues can also be reported via HackerOne.

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

     
    • Jeff Chandler 9:31 pm on April 9, 2015 Permalink | Log in to Reply

      Download – Updates should be Dashboard – Updates. Also, if the team is pushing out automatic updates, it’s a bit confusing to me that we’re also telling users how to manually update. Hopefully, people don’t wait around to see if it’s auto updated for them.

      • Rachel Baker 9:45 pm on April 9, 2015 Permalink | Log in to Reply

        Thanks, Jeff. I corrected the Dashboard/Download issue. We are are telling everyone that we *strongly encourage* anyone using the WP REST API plugin to update it immediately. We do need folks to be aware that the plugin updates are being pushed out to sites automatically, which is an indication of the severity of the issue.

  • Rachel Baker 1:51 pm on March 24, 2015 Permalink |
    Tags: json-api   

    WP REST API: Version 1.2 

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

    A short nine months after our last release we have support for Cross-Origin Resource Sharing, full request hijacking, JSON encode/decode errors, and a swarm of bug fixes.

    Here are the expanded highlights:

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

      Preflighted requests (using the OPTIONS method) include the headers Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Credentials in the response, if the HTTP origin is set.

      (props @rmccue, #281)

    • Allow overriding full requests.

      The json_pre_dispatch filter allows a request to be hijacked before it is dispatched. Hijacked requests can be anything a normal endpoint can return.

      (props @rmccue, #281)

    • Check for JSON encoding/decoding errors.

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

      (props @joshkadis, @rmccue, #461)

    • Add filtering to the terms collection endpoint.

      Available filter arguments are based on the get_terms() function. Example: /taxonomies/category/terms?filter[number]=10 would limit the response to 10 category terms.

      (props @mauteri, #401, #347)

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

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

      (props @pippinsplugins, #392, #335)

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

      (props @pkevan, #294)

    • Handle route matching for - in taxonomy and terms.

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

      (props @EdHurtig, @evansobkowicz, #410)

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

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

      (props @codonnell822, #455)

    • Fix the Content-Type header for JSONP requests.

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

      (props @simonlampen, #380)

    • Add $context parameter to json_prepare_term filter.

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

      (props @traversal, #316)

    • Move the JavaScript client library into the plugin.

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

      (props @tlovett1, #730)

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

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

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

      (props @maxcutler, #300)

    • Give top-level posts a null parent value.

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

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

      (props @maxcutler, #391)

    • Move permission checks out of WP_JSON_Posts.

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

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

      (props @rachelbaker, #486, #378)

    • Split comment endpoints into separate class.

      All comment handling has moved to the WP_JSON_Comments class.

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

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

    • Split meta endpoints into separate class.

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

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

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

    • Rename internal create methods.

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

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

    • Fix discrepancies in edit and create posts documentation examples.

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

      (props @rachelbaker, #305)

    • Update the cookie authentication documentation examples.

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

      (props @rachelbaker, #321)

    • Add flexibility and multisite support to unit tests.

      Tests can be run from any WordPress install, and are not limited to only as a plugin installed within a WordPress.org develop checkout. Unit tests are now run against a multisite installation.

      (props @danielbachhuber, #397)

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

    Here’s who contributed to this release:

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

    Release Plan

    1.2 will be the last major release on the 1.x branch of the plugin. We’ve been working hard over the past four months, with the aim of releasing a beta for version 2.0 next month.

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

     
    • Heather Acton 1:55 pm on March 24, 2015 Permalink | Log in to Reply

      Woohoo!!! Congratulations! Great work to all.

    • Emyr Thomas 2:02 pm on March 24, 2015 Permalink | Log in to Reply

      This is great news, thanks for the update. Two quick questions…

      1. What’s the current status for getting this into WordPress core? I assume if it’s still going to make it into core, that won’t happen until version 2?
      2. What’s the situation with regards to the overlap between this project and the Jetpack/WP.com JSON API? Are both projects going to remain separate, or are there plans to merge somewhere down the line?

      • Rachel Baker 2:46 pm on March 24, 2015 Permalink | Log in to Reply

        Emyr,

        It would be version 2 that makes it into WordPress core, and the timeline for that is “sometime in 2015”. I cannot speak for the Jetpack/WP.com team, but our goal is to make the WP REST API too impressive to refuse.

        • John Teague 3:58 am on March 25, 2015 Permalink | Log in to Reply

          I’ve reviewed v4.2. Believe me, REST API is already too impressive to put off including in core any longer. Not that I don’t appreciate a solid 100% commitment towards maintenance, but a a solid innovative inclusion in core would be a breath of fresh air these days :)

  • Weston Ruter 11:04 am on January 26, 2015 Permalink
    Tags: , , , json-api, partial-refresh   

    Proposal: Customizer Transactions 

    You may be familiar with transactions in a database context. The idea is simple: once you start a transaction, any change made to the database in the current session will not be applied to other database sessions until a transaction COMMIT is done. Changes performed when the transaction is open will be reflected in any SQL SELECT queries made, and if you decide that you do not want to persist the changes in the transaction in the database, you can simply do ROLLBACK and the changes will be discarded. And actually WordPress already uses MySQL transactions, but only in unit tests: a rollback is done after each test is torn down to restore the database state for the next test.

    The parallels between database transactions and the WordPress Customizer are clear. When you open the Customizer you are starting a “settings transaction”. Any changes made to the settings in the Customizer get reflected in the preview only, and they get written (committed) to the database only when the user hits “Save & Publish”.

    As good as the Customizer currently is, the way it has been implemented means that there are limitations on what we can do with it.

    Current Limitations

    The existence of modified settings in the Customizer is restricted to the life of a browser window. When a user changes a control in the Customizer and a setting is modified (with transport=refresh), an Ajax request is made with the changed settings data POSTed to the previewed URL. The Customizer then boots up and adds the setting preview filters based on what it sees in $_POST['customized'] so that the changes are reflected when WordPress builds the page. When this Ajax response is received, the Customizer JS code then writes the response to the iframe via document.write().

    There are a few downsides to this current approach:

    One problem is that if the user navigates away from the Customizer, they lose their drafted settings. To get around this, an AYS dialog was added in #25439, but this still doesn’t account for browser crashes or system failures. It would be ideal if the settings could persist in the same way as when drafting a post.

    Another downside is that whenever the preview needs to refresh it has to re-send all the modified settings so that the Customizer preview will have them available to add to the filters, since the Customized settings data is not persisted in WordPress in any way. There’s a performance hit to continually send all data with each request, which was partially improved with #28580.

    Additional problems stem from the Ajax POST + document.write() approach to refreshing the preview. Since the Customizer iframe starts out at about:blank and the HTML is written to from the document at customize.php, much of the context for the document in the iframe gets inherited from the parent window. This means that window.location in the preview window is the same as in the parent window: /wp-admin/customize.php. Needless to say, this means that JavaScript code running in the Preview will not run as expected (e.g. #23225).

    The Customizer preview intercepts all click events and sends the intended URL to the parent window so that the Customizer can initiate the request to refresh the preview. The only way to change the current page in the preview is by clicking a standard links with a URL; any form submissions in the preview are completely disabled, resulting in the search results page not being reachable from within the preview (#20714). Any navigation system that uses JavaScript to change the window’s location also will fail, for instance using a dropdown.

    The current unique method for refreshing the preview worked fine when the Customizer was limited to a handful of settings. But now as more and more of WordPress is being added to the Customizer, and now that themes are increasingly leveraging JavaScript, we need a more robust approach to implementing the Customizer which will solve the above challenges and provide new opportunities.

    Customizer Transactions

    The proposal is that we introduce persisted Customizer settings, in other words “Customizer transactions”. Here’s how it may work:

    When opening the Customizer for the first time, a transaction UUID is generated. Whenever a setting changes, an Ajax request sends the updated setting to WordPress to be persisted in a wp_transaction post which has a post_name corresponding to that UUID (or such a transaction post is created on the fly if not existing already). Any changes made in the Customizer then get amended to the same wp_transaction post, which has a key/value JSON blob as its post_content.

    When a user hits the Save & Publish button, the underlying wp_transaction post gets a post status change to publish. When transitioning into this status, each of the settings in the transaction at that point get saved to the database—they get committed.

    Instead of using an Ajax POST to send the customized settings to the preview, we then only have to reference the transaction UUID when loading URLs into the Customizer preview. What this means is that we no longer have to use a blank iframe but can load the window with the natural URL for what is being previewed (#30028), but just with the transaction UUID query parameter tacked on.

    When this transaction UUID query parameter is present, filters get added to amend all URLs generated in the preview to also include this UUID, so the transaction context is persisted as the user navigates around the site in the preview window. Forms also get this transaction UUID added as another input element, so any form submissions will also keep the preview inside the transaction. Additionally, WP Ajax requests are intercepted to tack on the transaction UUID so that now even Ajax requests can be previewed in the Customizer without any extra work.

    Now that the document in the preview window is actually at the URL being previewed (as opposed to about:blank), refreshing the preview is greatly simplified: instead of capturing scroll position, doing Ajax POST, writing the response with document.write(), and restoring the scroll position—now the preview window just has to do a simple location.reload(). JavaScript now runs in the expected context, and full JS applications can be previewed in the Customizer.

    As noted above, each time the Customizer is opened and a setting is updated the first time, a wp_transaction post is created with a draft status, and this post gets updated each time a setting is changed during that Customizer session. You also can open the Customizer as a whole (at customize.php) with this transaction UUID supplied and that settings in that existing transaction draft will be loaded. This means you can draft Customizer settings and return to them later, or make some changes and then send it along to another user to finalize (realtime collaboration would be possible as well with some heartbeat integration, or else a locking mechanism would make sense). The capability to publish wp_transaction posts could be restricted to an administrator role, with other roles being able to save posts with a pending status to submit for review.

    Also as noted above, the point at which the settings in a transaction get saved (committed) to the database is when the wp_transaction post transitions to a publish status. This being the case it naturally allows for transaction posts to be scheduled to apply in the future. If you want to make a bunch of changes to your site appear at midnight on Saturday, you could go in on Friday and add/remove widgets, change background images, and do anything else the Customizer allows and then have this transaction be scheduled for the desired time. When it publishes, all of the settings would go live on the site. This resolves #28721.

    With each Customizer session resulting in a new transaction post being created, then there is automatically a Customizer revision history (see #31089). Every transaction that has a publish post status is a change that went live on the site.

    Another side benefit to reworking the Customizer preview to load via a natural URL with the transaction UUID supplied is that there aren’t any intrinsic capabilities needed to preview a transaction on the site. A setting change gets authorized at the time of the change, and the sanitized setting is then persisted in the transaction post. The preview then just applies the pre-authorized and pre-sanitized settings. The interesting side-effect of this is that it means Customizer previews (frontend URLs with the transaction UUID amended) can be shared with anonymous users to review. You can pop open the URL in the preview iframe into a new window and share it with any user for review, and they don’t need the capability to customize.

    Lastly, something else that motivated my investigation into Customizer transactions is thinking about how the Customizer will relate to the upcoming REST API. How can the REST API be improved with the Customizer? Where do they intersect? If the REST API provides a transactions endpoint for doing CRUD operations on Customizer settings, and if the REST API also has global recognition for a customize_transaction_uuid query parameter in all requests, then it becomes possible for the Customizer to be used to preview changes in applications that merely interact with the JSON REST API, as long as they include the transaction UUID in the requests.

    Partial Refresh

    There’s one drawback I’ve encountered when implementing a patch for what I’ve described above. As noted above, when a setting has a refresh transport, the preview window now does a regular location.reload(). When this happens, there is a momentary “flash of unloaded content” (white screen) which currently doesn’t happen when document.write() is employed to refresh the preview window. I’m not sure why this is, other than maybe document.write() initiates a synchronous DOM operation, whereas doing location.reload() initiates an asynchronous one. I’ve tried doing output buffering as well, to try to make sure the response gets sent all at once. But I haven’t had success. This is the current refresh behavior:

    If no solution can be found for the white-screen-flash-during-reload issue, there is an alternative (besides the postMessage transport) which would provide an even better experience than even now with the “seamless” full page refresh: partial refresh (#27355).

    When a setting change can’t be previewed purely with JavaScript (via postMessage), or it doesn’t make sense to re-implement all of the PHP logic in JS (which is not DRY), the Customizer currently necessitates a full refresh of the entire page. With the proposed partial refresh transport, however, only the container element(s) in which the setting appears in the preview would get fetched from the server via Ajax and inserted into the DOM. This is much faster than having to refresh the entire page, and it retains the overall document state (e.g. whether the sidebar is expanded or not).

    There are challenges for implementing partial refresh in a way that it can be enabled by default, however. When implementing partial refresh support for widgets in the Widget Customizer feature-as-plugin for 3.9, I found that themes had to explicitly opt-in to partial-refreshed widgets because a widget could be inside a sidebar that has a dynamic layout (e.g. jQuery Masonry) or the widget may have JS-driven functionality that has to be re-initialized when updated partial is injected. So partial refresh for widgets was removed from being included in WordPress 3.9, but the functionality has recently been resurrected in the Customize Partial Refresh plugin. More research is needed into how much partial refresh we can have enabled by default, and where we need explicit opt-in.

    Call for Feedback

    So there’s a lot of exciting possibilities introduced with Customizer transactions. I’d love to hear what you think. I have an working patch written and it exists in a pull request on GitHub. I welcome comments there on the PR. Naturally, the changes would need to be split up into smaller patches for committing to SVN.

    Related tickets:

    • #30937: Add Customizer transactions (main ticket)
    • #30028: Load Customizer preview iframe with natural URL
    • #30936: Dynamically create WP_Customize_Settings for settings created on JS client
    • #27355: Customizer: Add framework for partial preview refreshes
    • #20714: Theme customizer: Impossible to preview a search results page
    • #23225: Customizer is Incompatible with jQuery UI Tabs.
    • #28721: Scheduled changes for the customizer
    • #31089: Customizer revisions
    • #31517: Customizer: show a notice after attempting to navigate to external links in live previews

    Appendix: Why not just use MySQL transactions?

    Something interesting to investigate for the future would if we could take this another (lower) level and actually use MySQL transactions for the Customizer. This would make the Customizer much easier to extend beyond options and theme mods, as the Customizer could just start a MySQL transaction and when a setting is changed, just keep a log of any INSERT/UPDATE/DELETE statement performed during a MySQL transaction. They can then be re-played whenever the preview reloads, and then followed by a COMMIT when the Customizer is saved. These SQL statements can be saved in the wp_transaction post, as opposed to the JSON blob containing the key/value settings data. Or the use of MySQL transactions could go deeper and the SAVEPOINT could be utilized to store the transaction natively in MySQL.

    But there are some concerns about using MySQL transactions: first, there’s the question of compatibility and whether MySQL transactions would be available on the wide array of hosting environments where WordPress runs, and what MySQL storage engines are used. Then there’s the question of how conflicts would be resolved when the auto-incremented IDs in the transaction diverge from those outside. And also there’s the concern of storing SQL statements the wp_transaction post’s post_content, and how this might introduce vulnerabilities. Lastly, if we use MySQL transactions as opposed to storing the staged settings in a wp_transaction post, then we’d miss out on being able to inspect the contents of a transaction to see what changes are contained within it.

    In any case, using MySQL transactions would be an interesting alternative to the current WP_Customize_Setting abstraction.

     
    • nvartolomei 12:47 pm on January 26, 2015 Permalink | Log in to Reply

      Huh, nice writeup.

      The idea of transmitting UUID via URL looks kinda scary to me, so many places to keep this in head, and again looks like a crappy hack.

      Isn’t a better way to store this uuid along with user session data?

      • Weston Ruter 6:59 pm on January 26, 2015 Permalink | Log in to Reply

        Initially I was thinking of using a cookie to store which transaction that is currently open. But I realized that using a cookie (or usermeta) would not work because a user could have multiple Customizer sessions open in different windows, with a different transaction in each of them: there can be multiple Customizer sessions for a given user session. A query parameter was the only way to implement this, that I could find.

        Besides, using the UUID query var has the nice benefit of being able to share frontend URLs including the UUID query var with non-authenticated users to review what changes the transaction would apply.

    • PeterRKnight 8:28 pm on January 27, 2015 Permalink | Log in to Reply

      I like the idea of revision history and perhaps even the ability to save settings as a per-theme profile of sorts (makes a ton of sense in my book). I do think part of the problem as described can be dealt with more simply by using localstorage to store settings during a customizer session.

      Partial refresh could perhaps be tackled by letting widget developers have the ability to explicitly opt-out (rather than opt-in) and force a reload instead, as well as being able to globally filter the refresh method. This way plugins/themes can force fallback behaviour if they have javascript logic running that would not work properly otherwise. I might be underestimating the amount of widgets that have the kind of js logic that wouldn’t work properly in the partial refresh scenario though.

      Themes that use ajax techniques share this problem though. Right now WordPress doesn’t offer any help with developers making their scripts function robustly when, say, their widget is inserted dynamically, or when page content containing a shortcode that has javascript logic. For one of my own plugins I use node insertion detection to load/initialize scripts on demand. This can be achieved with Mutation observer or detection through css animation events. There is also a need I think for a clientside asset loader a-la require.js that compliments the existing scripts and styles api on the php side of things.

      • Weston Ruter 10:54 pm on January 27, 2015 Permalink | Log in to Reply

        localStorage could be used to prevent losing settings upon leaving the Customizer, but that’s about it. It would still require doing a POST request for each load of the preview since the data wouldn’t be stored in the database to reference otherwise, so you would miss out on the many advantages gained by just referencing a transaction via a query param, as I tried to detail above.

        Regarding partial refresh, I like the idea of adopting an opt-out approach as opposed to opt-in, however the value of doing this would have to be carefully evaluated in light of the Core principle of backwards-compatibility.

        Regarding Ajax, my patch automatically handles ensuring that Ajax requests get evaluated in the context of the current transaction. This is done simply by using a jQuery.ajaxPrefilter to inject the transaction UUID into the URL being requested. If the Customizer’s settings weren’t stored in a transaction on the server and referenceable by UUID, then this would not be possible, or it would be complicated by having to force the method to POST and then include the transaction’s data encoded as JSON in $_POST['customized']. This may not work, however, because the Ajax handler could be explicitly expecting a GET request. I think overall it is messier.

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

    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-api   

    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-api   

    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-api   

    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!

     
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