WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Ryan McCue Toggle Comment Threads | Keyboard Shortcuts

  • Ryan McCue 2:01 am on June 23, 2014 Permalink | Log in to leave a Comment
    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 | Log in to leave a Comment
    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 | Log in to leave a Comment
    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 | Log in to leave a Comment
    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 | Log in to leave a Comment
    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.

     
  • Ryan McCue 7:00 am on December 2, 2013 Permalink
    Tags:   

    JSON REST API: Version 0.7 

    Apologies for the delay on this one, but it’s here now: version 0.7 of the JSON REST API! Go download it now. This is mainly a bugfix release to catch up on all the unreleased items:

    • The response handler object is now passed into the endpoint objects via the constructor, allowing you to avoid excess global state where possible. It’s recommended to use this where possible rather than the global object.

      (props @rmccue, #2)

    • Fix undefined variables and indices
      (props @pippinsplugins, #5)
    • Correct call to deactivation hook
      (props @ericpedia, #9)
    • Check metadata access correctly rather than always hiding for users without
      the edit_post_meta capability
      (props @kokarn, #10)
    • Return all term metadata, rather than just the last one
      (props @afurculita, #13)
    • Access post metadata from cache where possible – Note, this is a backwards compatibility break, as the format of the metadata has changed. This may change again in the near future, so don’t rely on it until 1.0.
      (props @afurculita, #14)
    • Add term_link to prepare_term
      (props @afurculita, #15)
    • Fix hardcoded /pages references in WP_JSON_CustomPostType
      (props @thenbrent, #26)
    • Sanitize headers for newlines
      (props @kokarn, #7)
    • Register rewrite rules during plugin activation
      (props @pippinsplugins, #17)

    (As you can see, we had 6 separate contributors to this release, with 3 team members also reviewing and merging code. Thanks to everyone who was involved with this release!)

    We’ve also got some future plans, which I’d like to share with you guys now if you haven’t seen them previously (you’re always welcome over at the team o2). This slightly delayed release is a catch-up release, and we’re planning on hitting 0.8 this week, then 0.9 on December 11th and 1.0 on December 18th. We’ll then be taking a short break over Christmas, and letting the code settle for a bit.

    The 1.0 release will freeze our (internal PHP and external JSON) core API, with any future changes to be completely backwards compatible. This should coincide with the 3.9-early stage, and we’ll be able to get underway on core integration discussions with this backwards compatibility policy.

    The big feature we’re working on now is authentication. After much discussion, we’ve decided that OAuth 1.0a is really the only way to go here. While Basic authentication is nice and simple, it doesn’t give us any sort of CSRF protection, which is a blocker. Luckily for us, WooCommerce has recently added a JSON REST API (based on this project; giant props to Max Rice for his effort and feedback here) and implemented OAuth, so I’m working on porting this back upstream. This should hopefully land in 0.8 (this week) or 0.9 (next week).

    As always, if you want to get involved, head on over to our team o2. Now that we’re established, comments have been opened to all, and you’re welcome to suggest new topics via the form too!

     
    • Andrew Nacin 2:40 pm on December 2, 2013 Permalink | Log in to Reply

      The 1.0 release will freeze our (internal PHP and external JSON) core API, with any future changes to be completely backwards compatible.

      This is a noble idea, but how does it affect merger? Things are going to need to change based on additional feedback and eyes. I would not make this promise in any plugin specifically built to be included in core, until core actually merges it. The work here being done is fantastic. I’ve kept an arms length to let others influence direction, but at some point, I and other lead developers are going to need to roll up our sleeves and dive in. I just don’t want this to handcuff us. If this policy is to apply to the plugin only, that’s fine.

      • Ryan McCue 8:53 pm on December 2, 2013 Permalink | Log in to Reply

        To clarify, yes, this applies to the plugin only and does not affect merge. Here’s how I see it playing out:

        • We hit 1.0, and internal API freezes. Any future changes have backwards compatibility.
        • Merge begins and the plugin is branched twice: once for the merge candidate, and once for the last major version.
        • The prefix is changed in the merge candidate branch (likely from `json_` to `api_` and `WP_JSON_` to `WP_API_`)
        • The core team begins suggesting changes for merge, and those are implemented in the merge candidate branch
        • The merge candidate branch is merged into core, hurray!
        • The last major version is changed to become a backwards compatibility shim for the core version. Anyone who wants to use the plugin right now can continue using it with no change to prefixes/etc, but using the new code actually in core.
        • The plugin version eventually dies out.

        Maintaining the compatibility shim might be hard, but it offers huge guarantees to users that outweigh that. Plus, who doesn’t love a challenge. :)

    • Mte90 2:30 pm on December 27, 2013 Permalink | Log in to Reply

      Why use OAuth 1.0a instead of 2?
      The 1.0a is not widely used, even the big names like Google, Microsoft and Facebook support it anymore!

      • Ryan McCue 7:41 am on December 28, 2013 Permalink | Log in to Reply

        Unfortunately, OAuth 2 isn’t a replacement for OAuth 1.0a, as it only works on SSL-enabled sites. We can’t guarantee that we have SSL on every site, so OAuth 2 is out of the question.

    • Dave Navarro, Jr. 5:45 pm on February 23, 2014 Permalink | Log in to Reply

      Are you still on 0.7? I see you were hoping to hit 1.0 last December.

  • Ryan McCue 2:36 am on September 28, 2013 Permalink
    Tags: ,   

    JSON REST API: Version 0.6 and The Future 

    We’ve finally come to the end of Summer of Code, so it’s time for the final GSoC release in this slightly late update (hey, would it be a post by me if not?). This release is mainly a stability release, so there are only minor changes:

    • Huge documentation update – Guides on getting started and extending the API are now available for your perusal
    • Add generic CPT class – Plugins are now encouraged to extend
      WP_JSON_CustomPostType and get free hooking for common actions. This
      removes most of the boilerplate that you needed to write for new CPT-based
      routes and endpoints (#380)
    • Use defined filter priorities for endpoint registration – It’s now easier to
      inject your own endpoints at a defined point
    • Update the schema – Now includes documentation on the Media entity, plus more
      (#264)
    • Add better taxonomy support – You can now query for taxonomies and terms directly. The routes here might seem strange (/posts/types/post/taxonomies/category for example), but the intention is to future-proof them as much as possible (#275)
    • Ensure the JSON URL is relative to the home URL (#375)
    • Check all date formats for If-Unmodified-Since (#378)
    • Register the correct URL for the JS library (#376)
    • Correct the usage of meta links (#379)
    • Add filters for post type and post status data (#380)
    • Separate parent post and parent comment relation (#330)

    The big feature for this final week is a bunch of documentation changes. I’ve created guides and documents on how to use the API, intended for both beginners and experts. I’d especially like to highlight the Getting Started guide, as well as the Extending the API guide for plugin developers. The documentation in the past has been less than fantastic, so I’ve made a concerted effort towards it this week. In addition, I’ve also fixed up all the remaining bugs reported via Trac.

    Now that GSoC’s over, what’s next? The aim with the project is to now move it from a solo project to a team one, and to that end, I’ve been working on assembling a fantastic team to work on the project with, with aim to integrate the API into core in the future. 3.8 time is fast approaching, so we’ve elected to aim for 3.9 as a more realistic target, although the advantage of the Feature as a Plugin method of development is that we’re not locked down here.

    We’re held two meetings so far as a team, and I’ll announce a proper office hours time next week, but I’m also looking to try something new with the organisation of the team. More to come on that in the next team update, but in the meantime, you can check out the internal team discussion site. Anyone looking to get involved in the team is welcome to join as always, but I’d ask that only those serious about working on the project join, as there are a fair few people committed already.

    Thanks to everyone, especially my mentors and Jen, for making this project a joy to work on so far. Here’s hoping we can keep the momentum as we push forward with the project.

     
  • Ryan McCue 8:27 am on September 12, 2013 Permalink
    Tags: ,   

    JSON REST API: Version 0.5 

    This week, I finally have a new release for you! Version 0.5 is now available, with the following changes (and more!):

    • Add support for media – This has been a long time coming, and it’s finally at a point where I’m happy to push it out. Good luck. (#272)
    • Separate the post-related endpoints – Post-related endpoints are now located in the WP_JSON_Posts class. When implementing custom post type support, it’s recommended to subclass this.

      The various types are now also only registered via hooks, rather than directly in the server class, which should make it easier to override them as well (#348)

    • Add page support – This is a good base if you’re looking to create your own custom post type support (#271)
    • Switch from fields to context – Rather than passing in a list of fields that you want, you can now pass in a context (usually view or edit) (#328).
    • Always send headers via the server handler – Endpoints are now completely separate from the request, so the server class can now be used for non-HTTP/JSON handlers if needed (#293)
    • Use better error codes for disabled features (#338)
    • Send X-WP-Total and X-WP-TotalPages headers for information on post/pagination counts (#266)

    As always, the full changes are available if you’re interested.

    This week finally brings media into the fold. The process for uploading media is a little different to creating normal posts, so here’s how you do it.

    First, upload the file via a POST request to /media. This can either be as a standard HTTP multipart body, with the name field set to file, or as a raw file in the body with the Content-Type header. (You can also optionally send a Content-MD5 header if you’d like the server to check the consistency of your file.) This will give you a 201 Created status, and point you to the new resource. You can now update that resource with the correct post data.

    This multistep procedure is required to enable raw file uploads, and I’m not entirely pleased with it, but it’s the only way without requiring multipart requests. I’d love to have feedback on this system, as I think practical use will eventually reveal the correct method here.

    So, it’s time to start winding up the Summer of Code portion of the project. There’s still one week left for the Summer of Code project, so you may still see a release next week, but most likely in the form of smaller updates, especially with documentation and testing. As I finish up, it’s time to look forward to the future of the project. The plan is to form a Feature as a Plugin team as we work towards core integration in future releases. People have already volunteered for the team back in the 3.8 scoping days, and I’ll be getting in contact with them shortly, but it’s not too late to nominate yourself for the team; let me know if you’re interested.

    Thanks to everyone for testing and for your feedback. Stay beautiful.

     
  • Ryan McCue 2:20 pm on September 4, 2013 Permalink
    Tags: ,   

    JSON REST API: Coming Soon 

    It’s been a while since you’ve all heard from me, so I wanted to check in and assure you I am still alive. I’ve been plodding along behind the scenes with the JSON API and mostly getting design documents sorted.

    The big feature I’m working on at the moment – media – has turned out to be tricker than I initially thought. While media is technically handled via custom post types, it’s a completely different kettle of fish to normal post types, so I’ve been working through the conceptual issues behind this to ensure that the API stays consistent both internally and externally. I really believe that it’s worth my time to sit down and consider these conceptual issues in depth rather than pumping out the feature as soon as possible. (The implementation of the media-related endpoints is working locally, but I don’t want to push this up while it’s still in flux.)

    I still hold out hope to push through media, but will likely reduce the scope of the other tasks to compensate, due to the complexity of media and the time it has taken so far. I’d like to personally apologise for this, this is a result of improper scheduling for the second half of the project.

    Personally, the past month or so has been pretty stressful as well, due to a number of other things going on in the background. Balancing this project with university work has become a big issue recently, so I’m working through this as best as I can. Ideally, my preferred option at this point would be to push this project out of the Summer of Code phase and into the open source team phase rather than continuing to work on the project in isolation.

    Along those lines, revisions will be bumped from the Summer of Code phase completely. While they are part of core functionality, they’re a rather large task that is secondary in importance to media and also behind taxonomy handling. I’d love to see these in the plugin at some point, but that won’t be happening during the Summer of Code phase. What I would love is for someone to volunteer to develop this (in a separate plugin for now, thanks to GSoC’s restrictions) for integration back in as soon as possible, which would also help with validating the API’s usefulness.

    So again, sorry and hopefully I’ll have something better to show you next week. Thanks for your patience.

     
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