Make WordPress Core

Updates from August, 2015 Toggle Comment Threads | Keyboard Shortcuts

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

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

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

    Security Release

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

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

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

    add_filter( 'json_jsonp_enabled', '__return_false' );

    To disable JSONP on version 2:

    add_filter( 'rest_jsonp_enabled', '__return_false' );

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

    Version 2.0 Beta 4

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

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

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

    • Show public user information through the user controller.

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

    • Send schema in OPTIONS requests and index.

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

      ⚠️ This breaks backwards compatibility for clients relying on schemas being at their own routes. These clients should instead send OPTIONS requests.

    • Update JavaScript API for version 2.

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

    • Embed links inside items in a collection.

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

    • Move /posts WP_Query vars back to filter param.

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

      ⚠️ This breaks backwards compatibility for users using WP Query vars. Simply change your x=y parameter to filter[x]=y.

    • Respect rest_base for taxonomies.

      ⚠️ This breaks backwards compatibility by changing the /wp/v2/posts/{id}/terms/post_tag endpoint to /wp/v2/posts/{id}/tag.

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

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

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

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

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

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

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

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

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

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

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

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

      Oh, please won’t you see my vest! 🎶

  • Samuel Sidler 2:47 pm on July 10, 2015 Permalink |
    Tags: ,   

    Feature Plugin Chat on July 14 

    Hey everyone!

    As I mentioned at this week’s dev chat, we’re going to have a feature plugin chat this coming Tuesday July 14 19:00 UTC.

    If you have an idea that you’d like to propose as a feature plugin or if you have a feature plugin already in development, come to the chat and comment below with the following details:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current status (e.g. idea, planning, early/late development, existing plugin, testing, stable, etc). If you’re just in the idea stages, list any existing plugins that are similar to your idea.
    • A list of those involved or already interested in your feature plugin (including you!).
    • A link to the plugin in the WordPress.org plugin directory and/or GitHub repository, if applicable
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    Please leave just one comment per feature plugin/idea so others can comment on the ones they’re interested in.

    Current feature plugin leads: We want your feature plugins here too! Please post an update with the information above.

    • Pascal Birchler 3:10 pm on July 10, 2015 Permalink | Log in to Reply

      I think there was a discussion about a toolbar feature plugin as mentioned in #32678. Basically, it should explore adding (most of) the admin menu to the toolbar.

      Status: Idea
      Similar plugins: https://wordpress.org/plugins/admin-bar-plus/

      I’d love to help with development and testing.

    • Pascal Birchler 3:13 pm on July 10, 2015 Permalink | Log in to Reply

      At the moment you can’t edit multiple users at once, which is pretty annoying for some use cases. Maybe this is something that should be explored as a feature plugin.

      Status: Idea
      Similar plugins: https://github.com/Automattic/bulk-user-management (old, multisite-only)

      I could help with scoping, planning and development if there’s enough interest. But I’ll probably end up developing something anyway 😉

      Relevant core tickets: #28050 and #32356

    • BrashRebel 3:49 pm on July 10, 2015 Permalink | Log in to Reply

      The TV team is collaborating on a plugin which places tutorial videos in the contextual help menu. The videos come from WordPress.tv and provide a visual walkthrough of the current screen in the wp-admin. The plugin is being developed for the purpose of assisting beginner WordPress users through video. The idea of proposing it as a future feature plugin has been briefly discussed.

      Current status: existing plugin
      Interested parties: @brashrebel @jerrysarcastic @roseapplemedia @ubernaut @johnparkinson
      Github: https://github.com/brashrebel/wptv
      We’d like help with:

    • jrf 4:37 pm on July 10, 2015 Permalink | Log in to Reply

      > Overview of your feature plugin proposal.

      Dependency management for themes and plugins the WordPress way.
      Allow themes and plugins to indicate dependencies on (other) plugins and providing an easy way for admin users to install, update and activate those. Will include activation prevention if dependencies are not met and providing cascading deactivate of dependents when a providing plugin would be deactivated.

      > Current status

      Existing external library which is widely used. +/- 6% of all themes in the repo use it, also used by a large number of premium themes and numerous plugins.
      A large refactor is planned and knowing what parts would be acceptable for core would be useful before starting the refactor.
      Roadmap for refactor from before this proposal (open to change per scoping): https://github.com/TGMPA/TGM-Plugin-Activation/issues/394

      > People involved

      Thomas Griffin – Project Owner & creator of the original TGMPA library
      Gary Jones – Project Lead
      Juliette Reinders Folmer – Lead Developer

      Suggesting this as a feature plugin is inspired by numerous users who keep suggesting it should be part of core.

      > Link


      > What you’d like help with

      Scoping: the libary currently features some functionality which may or may not be acceptable for core. Advise on this would be helpful before starting the refactor.
      Ref: https://docs.google.com/document/d/1abkiqT15SSboJVF8a16QDOL8o8Ocy4EHxsoZKwuwMFY/edit?usp=sharing

      Placement in the admin/user interface: currently plugins and themes can influence where the admin screen for TGMPA will show up. In the roadmap for 3.0 we’ve already included removal of this functionality and creating a set place for the admin page. Thoughts on where this should be and/or whether this should be integrated in an existing admin page would be helpful.

    • Daniel Bachhuber 9:41 pm on July 10, 2015 Permalink | Log in to Reply


      Shortcake adds a user interface to shortcodes.


      Late development. The next slated version is 0.5.0. You can easily skim through many discussions to date.


      @danielbachhuber, @mattheu, @goldenapples, @davisshaver and others



      Get Involved!

      At this time, we’d very much appreciate involvement in the form of documentation and user testing.

    • Nick Halsey 6:48 pm on July 12, 2015 Permalink | Log in to Reply

      Customizer Theme Installer
      Customizer theme installer would build on the Customizer Theme Switcher plugin merged in WordPress 4.2, bringing .org-repo-browsing and theme installation into the Customizer experience. The current idea is that entering theme-installation mode would bring the Customizer controls area full-width, hiding the preview, and the different tabs on the existing admin screen would be available, along with an “installed” tab. This would incorporate “shiny” theme installs – for each theme there are two options: “install” and “install & preview”. We would remove the existing theme-install previewer and instead offer the ability to download a theme and preview it in the Customizer with your actual site in one click. The basic install action would allow multiple themes to be installed at once, then the user could go through them to preview within the Customizer using the existing workflow.

      Current status: idea/design/wireframing

      Involved: @folletto and I (@celloexpressions) have tossed several ideas around and done some initial branstorming and wireframing, building on the work done in 4.2. I was originally planning on working on this for 4.3, but did Menu Customizer instead. I’d like to set up a meeting in the next couple weeks to get going on this effort and try to develop a merge-ready plugin by the time 4.3 is released, to be ready for merge in 4.4. Based on Customizer Theme Switcher (which was developed in only a few days), this effort will likely be more design/UX-heavy than development-heavy.

      • Paal Joachim Romdahl 7:02 pm on July 13, 2015 Permalink | Log in to Reply

        Features added to the customizer will these also be added outside of the customizer as well? For instance to the settings section. (Just thinking in general here).

    • Nick Halsey 7:51 pm on July 12, 2015 Permalink | Log in to Reply

      Background Image Cropper
      This plugin adds cropping to background images, to bring the feature into closer parity with header images. The plugin is currently awaiting review for the plugin repo, but is trivial code-wise and more about deciding whether this is a feature that users need/want. See also #32403.

      Current Status: Late development. The plugin is not currently functional due to a critical core bug in trunk that will be resolved in #29211 (specifically, it prevents the Customizer from loading, but there are additional issues that need to be cleaned up with the new API here). Once that core ticket is resolved in 4.3, the plugin will be fully functional and only potentially require minor tweaks.

      Involved: @johnbillion first proposed the idea in #32403, and I’ve built the plugin. Now, this feature is all about getting the word out about the plugin (once 4.3 is out, since that’s the required version), and gauging user interest. I suspect that we may run into issues here with some of the broader problems with the background images feature, and it remains to be seen whether cropping should be introduced without exploring broader changes here. Feedback and ideas welcome.


    • Nick Halsey 8:06 pm on July 12, 2015 Permalink | Log in to Reply

      Customizer UI Experiments
      Customizer UI Experiments is a new feature-plugin designed to be used on an ongoing basis for testing smaller UI/UX changes in the Customizer before rolling them into core. It contains several components that can be merged into core and subsequently removed from the plugin on an individual basis, with new components added as ideas are proposed. This single plugin to cover several distinct proposals allows testers to evaluate UI changes without wading through patches on different tickets scattered throughout trac. It also gives us a place to evaluate patches with feedback from a larger audience, hopefully improving our processes around UI-related Customizer tickets, which have had issues in the past. As a general rule, components added to this plugin should have a trac ticket first. This is a great plugin for multiple people to have commit access to, so if you’re interested in working on it (primarily porting patches to plugin form, and maintaining the plugin as components are added, updated and removed), please let me know and I can add you.

      The plugin is awaiting review on the .org repo, and initially contains an implementation of the patch on #32296. Components implementing #31195 (device-preview buttons) and #29158 (testing approaches to increasing visual contrast and improving focus styles for accessibility) are in the works as well.

      Current Status: This is a slightly different type of feature-plugin, so it will always be in a stable mode where testers can try it out (and leave it on) on their sites, with features coming in and out as they’re developed and merged into core. This is a sort of preview and testing ground for minor changes and features to come. Scope is strictly limited to changes with the Customizer UI itself – this plugin should avoid implementing larger features that add new panels/sections/settings/controls. Once the plugin is available on .org, I’ll link it on the tickets that it implements currently.

      Involved: I’ve done the initial development and scoping, with @voldemortensen already volunteering to help out and have commit access. Anyone interested in welcomed to jump in on Customizer-ui-related trac tickets and ping us in #core-customize or #design on Slack to discuss ideas.


    • George Stephanis 4:57 pm on July 13, 2015 Permalink | Log in to Reply

      Two-Factor Authentication

      Simple username/password authentication is fast becoming insufficient for the modern web. Several plugins so far have begun implementing methods for running two-factor authentication through varied systems, but none of them play well with one another. Our goal is to get a framework for two-step, two-factor authentication into core with several default providers (emailing a code, TOTP, and FIDO U2F) that core can support without any dependency on external providers, and keep it extensible, so that third-party plugins can add in new methods, such as Clef or TXT codes.

      Current Status: Active development, probably ~60% complete. Some providers need fleshed out, and the system needs backup provider support and some UI help. Also probably needs a couple audits from varied perspectives to make sure it solves everyone’s use cases and is accessibility friendly.

      Interested folks (who have expressed interest on Twitter or directly):

      @brennenbyrne (and the Clef gang)

      Probably some others I’ve missed.

      Current repository: https://github.com/georgestephanis/two-factor

      I’ve got the plugin approved for the .org repo, I just wanted to get backup methods fleshed out before starting porting it across.

      What we need help with: Code audits, design help, security audits, accessibility audits, development time fleshing out providers.

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

      Customize Partial Refresh

      Refresh parts of a Customizer preview instead of reloading the entire page when a setting changed without transport=postMessage. The goal with this plugin is to eliminate full-page refreshes as much as possible, as they are extremely bad for performance. This has been implemented in Core now for menus in the Customizer as of 4.3 beta. This plugin currently implements partial-refresh for widgets, but it also will abstract the functionality into a general API for developers to register their own partial-refreshable regions. This plugin has been floating around as a feature plugin for awhile. Blue sky: if we can eliminate full-page refreshes, we can start to introduce controls inline with the preview (e.g. widget controls appearing with their widgets), and even eliminate the Customizer iframe altogether since the Customizer pane could then slide-in on any existing frontend page the user is on without having enter into a completely different Customizer state; when done, they can just collapse the Customizer away and continue on their way browsing the site.

      Current status: existing plugin, development, testing

      Contributors: @westonruter

      Project links:

      Areas to contribute: identifying use cases and designing API for registering partial-refreshable region.

    • Pascal Birchler 12:59 pm on July 14, 2015 Permalink | Log in to Reply

      oEmbed for WordPress Posts

      Basically, we want to make WordPress an oEmbed provider. Users should be able to paste an URL from a WordPress blog and the post gets embedded right away. Difficulties here are discovering other WordPress sites as oEmbed providers and whitelisting them. The oEmbed endpoint requires the WP-API to be in use, so this can’t land in core until the API does.

      Current status: Idea / early development. There’s an existing plugin on GitHub we can build upon and we already have mockups of the desired end result.

      People already involved:


      And all the others who have joined the discussion on Trac.

      Project links

      Ticket: #32522
      Plugin on GitHub: https://github.com/swissspidy/oEmbed-API

      What we need help with: Mostly design and development, especially the oEmbed auto-discovery part.

      I’ll be around tonight for the chat, the others can’t make it unfortunately.

    • Ryan McCue 4:43 pm on July 14, 2015 Permalink | Log in to Reply


      The WP REST API adds a JSON-based REST API to WordPress, allowing accessing and modifying your site from a modern API.


      Ready for merge (version 2). Always more work to continue in the meantime.


      @rmccue, @rachelbaker, @danielbachhuber, @joehoyle


      https://wordpress.org/plugins/json-rest-api/ (v1 only)

      Get Involved

      We’re mostly deep focussing on getting it ready for merge, but we always need help on documentation and associated projects (OAuth, Basic Auth, client SDKs).

    • Joe McGill 1:25 am on July 15, 2015 Permalink | Log in to Reply

      For posterity…

      **RICG responsive images**

      **Big idea:** to bring responsive image markup natively into WP core.

      **Current status:** In development, stable (8,000+ active installs) could be considered for a 4.4 merge but will need some shepherding.

      **Plugin devs:** @tevko, @joemcgill, @dnewton, @jaspermdegroot, with consultation from @wilto (and a host of others).

      WP.org: https://wordpress.org/plugins/ricg-responsive-images/
      GH: https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images

      **Get involved:** We could use dev feedback, more testing (particularly against non-standard setups).

    • dshanske 2:01 am on July 15, 2015 Permalink | Log in to Reply

      Overview #32844 – There is interest in trying to put together a group to work on revamping Post Formats. This would not necessarily be the Post Formats UI that has laid dormant since 3.6, but a serious look at the feature as it exists today and how it can be refined in the same way the long-abandoned Press This feature was refined.

      I’m not looking to propose something with the scope of the WordPress 3.6 work, as I think the starting work is refining how Post Formats work. This includes better defining their use, producing examples of the types(documentation), looking for opportunities to better integrate them into existing parts of WordPress and enhance their functionality.


      I think @helen laid out a reasonable list of goals.

      “…existing content must be considered, as well as migration paths for those who currently use plugins/themes that store into meta. This may include things like auto-detection in Press This, modular content building, creation-only UI affordances, and so forth.”

      I’m willing to put in some time on this, and contribute out of my limited ability. Looking for interest.

    • Ryan Boren 2:36 am on July 15, 2015 Permalink | Log in to Reply


      Working on the latest Today in the Nightly post reminded me that I’ve been wanting a carousel feature plugin. The galleries on this post are handled by Jetpack’s carousel. Clicking/tapping an image pops up the image in a modal. The single images are not handled by JP’s carousel. They get the core behavior of following the bare image link. This is a bad experience, especially on mobile. Even on desktop, clicking the single images is a far worse experience than the carouseled images. Bare image links present no nav. You’re only way back is browser back history. This should work out of the box.



  • Rachel Baker 6:03 pm on May 28, 2015 Permalink |

    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 |

    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.

  • Jeremy Felt 11:22 pm on May 12, 2015 Permalink |

    Multisite Office Hours Recap (May 12, 2015) 

    Multisite office hours are held every Tuesday at 20:00 UTC in #core-multisite.

    4.3 Release Objectives

    Our objectives for 4.3 can be split between UI/UX and back-end core. Here’s what we’re working on along with who is assigned or expressed interest in the past.

    Network Admin UI:

    1. Capture mobile flows and find areas to improve. @sofiarose, @kraftbj, @ubernaut
      • See last week’s office hours recap for a list of flows we’d like to capture
      • @hugobaeta has posted some desktop flow
      • This objective will likely mirror some of what the Admin UI group is doing. We’ll know more about individual opportunities as we dive in deeper.
    2. Combine scheme/domain/path in Add New Site and Edit Site workflows. @hugobaeta
      • When adding a new site, you should be able to just type the site’s new address without worrying about where to put each of the individual parts. https://wordpress.org should split into a scheme of https, domain of wordpress.org, and path of /
      • If an admin email is added that does not belong to an existing user, a user will be created with the site’s name and the user’s email address. There should be an opportunity to provide the user’s username and email in this scenario.
      • Related tickets: #22383, #31240, #14172, #14215
      • @hugobaeta will be working on some mock-ups
    3. Improvement of network upgrade workflow (ajaxify)
      • The current network upgrade process cycles through sites 5 at a time and processes the database upgrades. After each set of 5, the page refreshes and the next 5 are loaded. If one encounters an error, the entire process is stopped to await manual interaction. This should be something handled nicely via ajax.
      • Related tickets: #11869, #18292, #22589, #24922, #26056, #31405
      • @boren has posted a Mac/Chrome network upgrade flow

    Multisite core:

    1. Provide validation for domains, paths, emails. @boonebgorges, @johnbillion, @jeremyfelt
      • The combined scheme/domain/path objective above relies on the validation of domains, paths, and emails. There are several quirky restrictions in multisite that would be nice to clear up. The first step is to establish validation functions so that we can write tests and then change the results as needed.
      • Related tickets: #17397, #18777, #20019, #19724, #21994, #15936, #16126, #17904, #26784
    2. Introduce WP_Site, WP_Network, WP_Site_Query, WP_Network_Query. @johnjamesjacoby, @earnjam, @rmccue, @jeremyfelt

    If you’re interested in your name being attached to one of these objectives, please leave a comment here or a ping in #core-multisite.

    There may be room for more, or reason to swap one of these with something else once we start progressing. Let’s keep the list about this size for now so that we have something consumable. We’ll continue to revisit these objectives weekly throughout the cycle.

    • Dave Navarro, Jr. 2:31 pm on May 13, 2015 Permalink | Log in to Reply

      This is probably outside the scope of what you want to accomplish this cycle, but the ability to export a single site from a multisite install so that it can be imported as a stand-alone site is critical to me. The process for this right now is extremely painful.

    • geturwealth 8:55 am on May 27, 2015 Permalink | Log in to Reply

      I really wish I understood this stuff better. I guess I should make use of the tutorial section. Until I do understand this, I’ll not make any changes as I have had too many glitches from doing them without proper understanding. Does anyone out there feel my concern?

  • Rachel Baker 1:51 pm on March 24, 2015 Permalink

    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


        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 :)

  • Mike Schroder 8:49 am on November 14, 2014 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi Everyone!

    It’s that time again: WordPress Core Weekly is here. This is a catchup post and covers all commits since the last post up until 11/9/2014.

    First, a couple quick notes!


    • Do not create shared taxonomy terms. [30240] #21950; See #5809.
    • Split shared taxonomy terms during term update. [30238] [30239] [30241] #5809
    • Don’t force child_of=0 for non-hierarchical taxonomies in get_terms(). [30265] #30275
    • In get_adjacent_post(), $excluded_terms should check term_id rather than term_taxonom_id. [30263] #29663, #22112.
    • Allow resource_type to be specified in get_ancestors(). Being explicit about resource type (taxonomy vs post_type) allows for the proper resolution of conflicts when a taxonomy and post_type share a slug. [30141] #15029
    • In wp_insert_term(), clean up accidental duplicate terms after insert. [30238] See #22023, #5809.
    • Add some unit tests for is_object_in_term(). These tests check a number of the ways that different kinds of values for $terms (integers that match term_id, strings that match term_id or name or slug) are handled. [30204] #29467
    • In in_object_in_term(), only check numeric string values against term_id. [30205] #29467
    • Introduce term_template param to get_the_taxonomies() to allow theme and plugin authors to specify the formatting on term links as they are parsed into the taxonomy list. [30209] See #27238.
    • Allow duplicate slugs across different post types. [30158] #18962
    • In get_terms(), do not override hierarchical and pad_count when parent is present. The previous behavior resulted in descendant terms being improperly excluded from the results when passing a parent, even when hierarchical had been set to true. [30107] #29815
    • Clean up get_term_by() caching, fix cache key/group modification that was missed in [30073], and update unit tests. [30108] #21760

    Twenty Fifteen


    • Bump db_version and add upgrade routine for schema change in [30056]. [30121] [30134] #22023
    • WPDB’s __get() function should perform strict comparisons against member names. [30292]


    • Allow revision Backbone classes to be used on pages other than revision.php. [30128] #30221
    • Add a single responsibility function for outputting Revisions JS templates: wp_print_revision_templates(). Use it in wp-admin/revision.php. [30129] #30220
    • Revisions modules should not rely on global settings; only pass in global settings on init, this allows the classes to be used agnostically elsewhere. [30131] #30219


    • Pass all updated meta IDs to filters in update_metadata(). [30140] #11683
    • Unserialize get_metadata() results when key is omitted. [30115] #15030



    • Display error message when Media Library upload fails. [30156] [30177] #29891
    • Delete admin_created_user_subject() rather than deprecate. As it was never used as anything more than a callback to a filter before the MU merge, and is only available in user-new.php in multisite, it is safe to remove this function entirely. [30176] #29915


    • Improve/introduce Customizer JavaScript models for Controls, Sections, and Panels, along with a reference. [30102] see #28032, #28579, #28580, #28650, #28709, #29758. Fixes #29529.
    • Improve ColorControl‘s wpColorPicker to update UI based on setting changes. Update Twenty Fifteen’s colorScheme control to properly interact with the API, using wp.customize.control(). [30126] #30031
    • Add stable sorting for panels, sections and controls in JS. Improve sorting in PHP. [30214] #30225
    • Bind input and propertychange events for range input types. [30219] #30223
    • Twenty Fourteen: Make featured content in Customizer contextual to the front page. [30143] #29578


    • Introduce new template functions for archive titles and descriptions: [30223] #21995
      • get_the_archive_title() and the_archive_title() for returning/displaying the title of the current term, date, post type, post format, or author archive.
      • get_the_archive_description() and the_archive_description() for returning/displaying the description associated with the current term archive.
    • In get_page_children(), only check $page->ancestors once to avoid duplicates when the function recurses. Adds an argument, $ancestors. [30246] #18962
    • Allow get_pages(), with child_of passed to it, to work with interrupted hierarchies. [30159] #18962

    Thanks to @afercia, @avryl, @azaozz, @bobbingwide, @boonebgorges, @bradyvercher, @Caspie, @celloexpressions, @dancameron, @davidakennedy, @davidjlaietta, @dikiy_forester, @dlh, @donutz, @DrewAPicture, @ericlewis, @filosofo, @florianziegler, @garyc40, @gcorne, @greuben, @hereswhatidid, @iamtakashi, @iandstewart, @imath, @Jayjdk, @jeremyfelt, @jesin, @joedolson, @johnbillion, @jorbin, @kitchin, @kovshenin, @kraftbj, @kurtpayne, @lancewillett, @landakram, @loushou, @markjaquith, @mattkeys, @mattwiebe, @mboynes, @MikeHansenMe, @mlteal, @mordauk, @morganestes, @nacin, @NikV, @nobinobi, @obenland, @ocean90, @pento, @philiparthurmoore, @realloc, @rmccue, @ryankienstra, @sakinshrestha, @SergeyBiryukov, @slobodanmanic, @TobiasBg, @tollmanz, @tywayne, @voldemortensen, @wedi, @westonruter, and @wonderboymusic for their core contributions!

    Revisions covered: [30094] to [30292]. For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 4.1.

  • Ryan Boren 8:15 pm on November 3, 2014 Permalink

    Open Update Thread 

    What’s going on in your core development world this week? Drop a comment. Let it OUT.

  • Mark Jaquith 5:20 pm on September 10, 2014 Permalink
    Tags: ,   

    9/10 Agenda 

    WordPress 4.0 “Benny” is out the door, warming hearts, flying off shelves, and many other euphemisms besides. After a brief respite to enjoy our success and a job well done, we turn our eyes to the future: 4.0.1, 4.1, and more.

    • Ionel Roiban 5:31 pm on September 10, 2014 Permalink | Log in to Reply

      Congratulations, everyone!

    • Stephane Daury (stephdau) 5:43 pm on September 10, 2014 Permalink | Log in to Reply

      4.1 release lead nominations: I’m going to go right in crazy mode and suggest @rmccue.
      Note: I have not discussed that with him, so it’ll catch him by surprise.
      My logic is as so:

      • in May, we had a big IRC convo during our weekly chat about committing to WP API.
      • From what I can tell, said API is quite ripe for 4.1, or could be with the proper effort.
      • Making Ryan a lead (if he can afford to) could be a good way to make WP API the big ticket item for 4.1
      • Stephane Daury (stephdau) 5:46 pm on September 10, 2014 Permalink | Log in to Reply

        That’s also obviously my vote for the focus in 4.1. :)

      • Justin Sainton 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        Really great suggestion! I think @rmccue would make an awesome lead, but I just don’t know about it for the release where he’s the lead on such a major component as the WP-API.

        Just spitballing here, but I wonder if it wouldn’t be a better situation to have someone as a release lead who can shepherd the whole release, not just that specific component? In my imagination, getting the API in the 4.1 release would require someone like Ryan to be more fully devoted to that specific component than to the whole release.

        Just my two cents.

      • Andrew Nacin 6:41 pm on September 10, 2014 Permalink | Log in to Reply

        When the API is merged in, we’d probably be best served with Ryan’s focus to be 100% on the API, and not need to worry about anything else also going on. The release lead is as much a project manager as it is a final arbiter, shepherd, and what not. Also, the API is going to be a big ticket item in the release it’s in, no matter what. :)

      • Michael Beil 4:44 am on September 12, 2014 Permalink | Log in to Reply

        I concur with having @rmccue at the helm.

    • Stephane Daury (stephdau) 5:51 pm on September 10, 2014 Permalink | Log in to Reply

      Call to action on feature plugins for 4.1 and beyond: in the same line as my WP API suggestion, and if it does make it in 4.1, I (we?) would like to resume work on the Press This rewrite, with the twist of building it as a WP API client. It could act as a great bundled example.

    • Andrew Nacin 6:57 pm on September 10, 2014 Permalink | Log in to Reply

      Some questions to ask:

      • What have we done in the last few releases that could benefit from a v2, even small things?
      • What have we added in the last few releases that needs to be propagated to other areas?
      • What have we not touched in a very long time and is long overdue for a revisit?
      • What brand new features should we consider working on?
      • What existing features need a complete rethink?
      • What are some bite-sized things that we could do to make a big impact? (3.9 and 4.0 were full of these.)
      • What are big things that are broken and that we feel like we could fix / make better?
      • What might Twenty Fifteen benefit from having in core?

      Also, if you want to help lead a release or want to suggest someone, be sure to read this post from 4.0.

      • Stephane Daury (stephdau) 7:08 pm on September 10, 2014 Permalink | Log in to Reply

        For #1 and #2: we delayed a move to Backbone.js (propagate) for the plugins browser/modal (updated in last release) in 4.0, under my advice, to focus on functionality rather than getting bogged down in a library switch. Should that be tackled that in 4.1, building on the experiences of the Media Grid et al?

      • Nick Halsey 7:30 pm on September 10, 2014 Permalink | Log in to Reply

        To address several of those points, I’d like to continue iterating on the Customizer. Starting to build out better JS APIs in particular, building up to several features that’ve been delayed due to the lack of structure here.

        I’d really like to get media in the Customizer rebuilt (initial patch on #21483), and to officially deprecate and redirect/deep-link the old header and background admin screens. Given Twenty Fifteen’s emphasis on those features, this seems like a good time to finally pull the trigger here.

      • John Blackbourn 7:31 pm on September 10, 2014 Permalink | Log in to Reply

        What have we not touched in a very long time and is long overdue for a revisit?

        I think we need to have a think about all the JavaScript which is landing in WordPress these days, and make sure we are documenting it well enough, whether we need to prioritise an action/filters API for this, whether we are doing enough to educate contributors and other developers on the JavaScript APIs, whether we need a better structure for the .js files, etc etc. See also Eric’s post on wp-hackers.

        What are some bite-sized things that we could do to make a big impact?

        Fix the currently rubbish comment notification settings. See #6286, #14676, #761, Email Alerts plugin.

      • Ihor Vorotnov 2:01 am on September 11, 2014 Permalink | Log in to Reply

        Jumping in here. The feature which is highly anticipated by literally any WP developer outside US and several other english-speaking countries is… some multilingual features in core.

        Here’s my idea in details: https://wordpress.org/ideas/topic/native-multilingual-cms-features-one-more-time#post-27185

        Basically, even making terms slugs non-unique and adding some super-taxonomy `language` will allow major plugin developers (WPML, Polylang) do the rest. WPML currently allows to have posts and pages with same slugs, but not categories, tags and custom taxonomies.

        Right now I’m building a pretty large international website, which will function a s a website and a mobile app platform (backend) – thanks to JSON API. Having urls like `example.com/ru/profile-2/edit` or `example.com/ru/profile-ru/edit/` (just plain simple hierarchical pages) is kind of freaky. Or `example.com/ru/events/country/canada-2/city/toronto-2` and `example.com/ru/events/country/canada-ru/city/toronto-ru`…

        Sooner or later, we need to add solid multilingual features to core to become CMS / Framework, not a blog platform.

    • Zach "The Z Man" Abernathy 7:18 pm on September 10, 2014 Permalink | Log in to Reply

      I personally would love to see a little more work in the area of media with respect to actually managing the media items. For instance, being able to group things in folders would be a huge improvement.

    • John Blackbourn 7:21 pm on September 10, 2014 Permalink | Log in to Reply

      I would like to get the ball rolling on open and closed Multisite networks which didn’t get any traction in 4.0 due to time constraints.

    • Boone Gorges 7:23 pm on September 10, 2014 Permalink | Log in to Reply

      I won’t be able to make this meeting, but I’d like to spend some time during the 4.1 cycle improving WP_*_Query classes. Improved test coverage (see eg #29560), followed by fixing some of the more egregious bugs (such as #19623), and adding what I see as some missing features (#29181, #29181, and a few others I am cooking up). May also look into abstracting some of the common logic into some sort of base class that the others will extend.

    • Robert Dall 8:01 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to fix the poor UI In the widgets since they were last updated. Specifically #27180 I know we can do better.

    • Aaron Jorbin 8:12 pm on September 10, 2014 Permalink | Log in to Reply

      I’d like to work on getting our JS unit tests running automatically on multiple browsers. I’d also like to look into some automated tests around front end performance of the admin and finding areas that we can speed things up (and also maintain a benchmark of how things are).

    • Xavier Borderie 8:16 pm on September 10, 2014 Permalink | Log in to Reply

      I’d vote for changing the in-editor image update, making like the one in Confluence. I use this wiki tool at my job, and love that, while WP uploads the file and shows the library, letting me inserting the media, when I really want to directly insert it in place. Makes a huge difference.

      • Xavier Borderie 8:17 pm on September 10, 2014 Permalink | Log in to Reply

        “in-editor image upload*”

      • Xavier Borderie 8:35 pm on September 10, 2014 Permalink | Log in to Reply

        Top notch foreign typography. It’s very hard, for instance, using French quotes or non-breaking spaces in the editor without resorting to copy-paste. The editor tries to hot-swap curly quotes but fails in many cases.

      • Xavier Borderie 8:39 pm on September 10, 2014 Permalink | Log in to Reply

        For translators: mark clearly strings that are used in JS, HTML labels/title tags or e-mail, because some translations use HTML entities to get some local things done, and that obviously does only work in HTML situations, not the others. I’m willing to work on that.

      • Xavier Borderie 8:29 am on September 11, 2014 Permalink | Log in to Reply

        Finally tackling that multilinguism issue — or at least build the foundations in 4.1, because it’d make for a great 4.2 announcement (‘cos, y’know, 42, Hitchhiker’s Guide, the Babel fish, all that :) ). Allegedly, the SPIP CMS does it very well (see here for their introductory post).

        • Vincent Mimoun-Prat 8:01 am on September 18, 2014 Permalink | Log in to Reply

          +1 For that too. Multilingual support is as of today more or less buggy depending on the plugin you are using. There are very few options out there and they all are flawed to some extend.

          It would be great to see at least a first step towards a multilingual base framework that plugins could eventually use to build a UI on top of that.

          Current approaches:

          • WPML has CPT and lots of meta data to translate taxonomies -> extra useless queries, bloated UI and code, …
          • Multilingual Press requires one subsites per language -> lots of duplicate site setup required + does not work for e-commerce where you would need two separate shops, would have two separate stocks, …
          • Some other plugins use markup within posts/taxonomies -> Makes editing a nightmare.

          Basically because no foundation for multilingual support is there, we don’t have a mean to get a decent solution to the problem.

      • Xavier Borderie 12:44 pm on September 15, 2014 Permalink | Log in to Reply

        Oh, and since I just got another two requests for that non-ending issue: please do something about the “WordPress address (URL)” and “Site address (URL)” setting fields! People keep using it with no other thought, this bringing their site down, hoping for others to help them out! There must be a better way: hide it, add a warning, anything else than giving the impression that the use can enter URL in these fields and that WordPress will magically set everything in place :)

    • Stephen Edgar 9:50 pm on September 10, 2014 Permalink | Log in to Reply

      The Export API was proposed for 4.0 and didn’t make it, would be great for 4.1:
      Export API improvements/overhaul #22435

    • Dan Milward 11:34 pm on September 10, 2014 Permalink | Log in to Reply

      I agree with Nick Halsey. For me it’d be something small and scene setting for more socket.io integration in the future – its hard to argue against the technology on the basis that Automattic acquired it right?

    • Brandon Wamboldt 2:15 am on September 11, 2014 Permalink | Log in to Reply

      The last few releases have made great strides in user experience in the admin, but now I think the team should focus on developers a bit for 4.1. As somebody who works frequently in WordPress, a big pain point is still list tables.

      I frequently create custom tables for data that really don’t fit the mold of post types, and I often have to duplicate large amounts of code to create a list view that mimics the other list views (posts/pages/etc). If you guys could ease that, it would be awesome!

    • Shail 5:00 am on September 11, 2014 Permalink | Log in to Reply

      For me most awaited feature is taxonomy meta. Is this feature in race? I know this is a very big change but I like to see it in core.

    • Ryan Boren 12:50 pm on September 11, 2014 Permalink | Log in to Reply

      I’ll dump my rough notes.

      Mobile and media. Media and mobile.

      Context, Trust, Awareness, Flow

      Press This. With the mobile improvements to the media modal that landed in 4.0, Press This can use the modal without being crippled on phones. The wordpress.com/post/ editor on wordpress.com has worked through some of the same problems that Press This needed to work through, hopefully smoothing the way. The /post/ editor also showed what you can and cannot get away with. Media, preview, and links are important. wpviews and wplinks are must haves. Media must be visual, not raw html, short codes, or even placeholders. Creating galleries should be possible and easy. Press This has a freedom that the /post/ editor does not. PT doesn’t have to worry with existing content edit flows. It can be tailored to a fairly one way creation flow (akin to Tumblr). It also has an advantage in that it can and does allow escaping to the full editor in the admin when the user needs more than PT provides.

      Press This is not just UI. It is bookmarklets, extensions, side-loading, re-blogging, and sharing. It is the sharing mechanism in Android and iOS8. Someday it will be accommodated by the apps. Keep the entire Press This and sharing ecosystem in mind. When dev resumes, prioritize bookmarklets and fleshing out the sharing mechanisms, especially on mobile. Press This the UI is, in part, a trojan horse for getting a decent mobile posting interface on phones, but the sharing big picture should not be lost to new UI fascination.

      Press This the UI should be a marquee user of WP API.

      Large (full screen-ish) images should be a tap/click away in the media modal. Creating and captioning galleries is difficult when provided only thumbnails. Maybe borrow the attachment details modal from grid view.

      Re-think media modal for touch devices. Get rid of tabs, especially in the absence of multi-select. Full images on tap with details below (like the attachment modal) rather than opening the sidebar and presenting another thumbnail sized image. That sidebar is awful on phones.

      Re-think the media modal in general. We know more about how it is used than we did back when. We know what plugins are actually rather than speculatively doing with it. Is having a separate gallery flow still a necessary compromise? Is a sidebar the best way for plugins to integrate? Is there anything blocking VideoPress and Dropbox plugins from integrating? Which plugins integrate well with the media modal?

      Create gallery and image posts from the media library grid view. Give bulk selection a purpose. This will accommodate mobile flows where images are uploaded to the media lib from a mobile device (via Android’s multi-select capable sharing mechanism, for example) and then gallery posts are later created from a desktop. This is a means of working around our lack of mobile multi-select and gallery creation interfaces.

      Phone UX improvements, particularly menus. Is it possible to swipe to open/close side menus on the mobile web? Side menus must have swipe to be usable. Tapping a menu icon in b’ar should dismiss the menu instead of visiting a link. There is often no safe “tap outside” room on a phone, so all menus should dismiss when their icons are tapped. Very aggravating.

      When adding links on mobile, don’t require highlighting text to activate link icons. Buggy on phones.

      Tweak wplinks for phones. It’s already pretty good and keyboard up/down responsive, but mostly by accident.

      Multi-select upload everywhere.

      B’ar consistency. The front page b’ar on touch devices is my favorite. Tablets in landscape show the narrower b’ar in the admin, which always disappoints me.

      Images uploaded to the media library and then added to a post don’t show up in the “Uploaded to this post” filter. Not being able to filter down to images already on the post makes setting featured images tedious. Uploading from mobile to media lib and then posting later is a common mobile flow.

      Fix the image editor on phones.

      Lose media-new.php?

      Oh wouldn’t it be nice…

      Settings that don’t suck.

      An index.php featuring Press This and a reader.

      Reader views for all list table screens.

      Theme switching from the customizer.

      Notifications, Stream.

    • Paal Joachim Romdahl 11:01 pm on September 11, 2014 Permalink | Log in to Reply

      Improving/renewing Settings was briefly touched upon but stopped up. Having a real useful Settings section would of course be really helpful. I bet a lot of people would have input about this and I bet there are also a few developers that really would like to come together and make this happen.

    • Stephen Edgar 5:54 am on September 12, 2014 Permalink | Log in to Reply

      Another suggestion, and with 99 stars at the time of writing:
      https://core.trac.wordpress.org/ticket/12706 – Custom post status bugs in the admin

      • pampfelimetten 8:37 am on September 18, 2014 Permalink | Log in to Reply

        Oh, yes please! I’m waiting for ages to have this fixed. It’s pretty weird that so much of the post status functionality is hardcoded, when you can tailor pretty much everything else to your needs in wordpress.

    • leemon 6:11 pm on September 12, 2014 Permalink | Log in to Reply

      Please, tackle the following taxonomy bugs once and for all:
      https://core.trac.wordpress.org/ticket/5809 – Updating a term in one taxonomy affects the term in every taxonomy
      https://core.trac.wordpress.org/ticket/5034 – Impossible to have duplicate category slugs with different parents

      Fixing this would be cool too:
      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list


    • Paal Joachim Romdahl 9:12 pm on September 12, 2014 Permalink | Log in to Reply

      Certain features are directed toward a developer and would not really help a “regular” user as much. I am thinking that features also could be placed into categories of who would this be helpful for. Placing a feature into: Developer, Designer, Advanced Users, Basic Users. Most people who are associated with being here on this forum are very likely Developers. A few probably Designers and a very very would then place themself into the remaining two categories.

      As I work with education I identify myself have very strong empathy for a person who has just began with WordPress. And oftentimes see WordPress through their eyes. Core needs eyes on features from people with different backgrounds that can share thoughts and their perspectives into seeing a much larger view.

    • Rodrigo Primo 8:59 pm on September 16, 2014 Permalink | Log in to Reply

      Fixing the performance issue with the algorithm used to display a list of hierarchical posts (pages or another custom post type) would be a great improvement for 4.1. This ticket has a patch already and is waiting for dev feedback.


    • Vincent Mimoun-Prat 7:53 am on September 18, 2014 Permalink | Log in to Reply


      I have just updated the patch I had submitted for 3.8 and 3.9 on an important performance improvement for meta queries. It would be great if that could be reviewed and included in 4.0.1 or 4.1


    • Paal Joachim Romdahl 12:22 am on September 22, 2014 Permalink | Log in to Reply

      Improving the WordPress importer/exporter plugin would be nice. To have a separate section for media or improving on the media aspect of the import/export.

    • Dave Clements 6:39 pm on September 22, 2014 Permalink | Log in to Reply

      It’d be great to see the work already carried out on #21506 (Standard Theme Hooks) carried forward through testing and implementation.

    • JakePT 7:39 am on September 24, 2014 Permalink | Log in to Reply

      I’m desperate for #20943 to be fixed.

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

    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

      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

      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.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar