Make WordPress Core

Updates from January, 2017 Toggle Comment Threads | Keyboard Shortcuts

  • Jeffrey Paul 7:35 pm on January 19, 2017 Permalink |
    Tags: , , ,   

    Dev Chat Summary: January 18th (4.7.2 week 1) 

    This post summarizes the dev chat meeting from January 18th (agendaSlack archive).

    4.7.x Releases

    • Moving to monthly checkins for 4.7.x releases
    • A few people stepped up to lead a future 4.7.x releases, a great way to get involved in the release process. If you’re interested in leading a future minor release, ping @samuelsidler anytime.
    • For 4.7.2, we haven’t set a schedule yet, but we’ll be checking tickets and commits in early February to decide if we should release. @jnylen0 will be the release lead.
    • Reminder for those who helped get 4.7.1 out, please check the handbook to see if updates are needed to help @jnylen0 on 4.7.2.
    • @jnylen0: some API stuff I want to get into a potential 4.7.2, but let me know about other tickets you’d like to milestone
    • Outside pressure on MIME issues not as horrific as one might have expected (ticket #39550: Some Non-image files fail to upload after 4.7.1)
    • Potential that since people using special MIME types (which are the most likely to get caught by this bug) are already aware of having to add in custom mimes, adding in the “unbreak” plugin to fix the problem right now isn’t seen as insurmountable.

    REST API team update

    • kicking off the new year by defining the scope of our activities, and prioritizing what is most critical to do first
    • @kadamwhite, @jnylen0, @tharsheblows, @kenshino, & others working on expanding the documentation
    • As we’ve moved the support for the REST API from the “WP-API” github repo, we’re seeing a few repeat questions that can be clarified with better docs & docs organization
    • Today we finished grouping existing docs from the old wp-api.org site into “Using” and “extending” buckets, which are reflected in the left nav; next up, we’ll be adding more docs for using the basics of what’s there
    • @rmccue leading the technical investigations into what to prioritize from an implementation standpoint (see: January 9th 4.8 kickoff meeting notes)
    • a lot that could be converted to use the API within WP-Admin, but change for the sake of change has never been a core value of this project
    • Whereas for something like list table actions, there’s a lot of inconsistency within the admin and converting some of those areas of functionality to use the REST API endpoints would be a clear win
    • We’re using a Trello board to track the areas of investigation
    • the Multisite and BuddyPress teams are both investigating how best to improve or create API endpoints tailored to those use cases
    • @flixos90 did an excellent writeup of our users endpoint discussion
    • We are sorting out how user and site membership management and display should work for the users endpoint.
    • master ticket #39544: REST API: Improve users endpoint in multisite
    • the REST API team intends to continue using the feature projects model to structure proposed API enhancements (such as menu support), with the added requirements of starting from a design document, and checking in with a core committer for periodic review to avoid the feature project from becoming silo’d
    • Multi-site is the first such feature project that’s officially under way.
    • For 4.7.2 we should be looking for related bugs around the existing functionality
    • @jnylen0: propose that we continually evaluate test and documentation coverage for new additions, as an excellent way to find bugs before they ship and we are stuck with them
    • Regarding bugs, to all: when (not if) you find a documentation issue or omission, or find an area where the API does not behave as expected, you are all welcome in #core-restapi at any time and we welcome the feedback.
    • We’re glad to see that the support questions so far tend to fall in a few specific buckets, but this is a new thing and the more eyes on it, the more likely that we’ll be able to identify the key areas where improvement will really drive admin or customizer improvements.
    • REST API team meeting is weekly at Monday 14:00 UTC in #core-restapi, and we welcome one and all to come chime in about how you’d like to see this used

    Customizer team update

    • Please read and contribute to the discussion happening on the “What makes a great customization experience?” post
    • Also recommend reading through the meeting that happened earlier today in #core-editor. There’s going to be a lot of overlap, especially as the editor team starts working on content blocks. Lots of discussions have been happening there and in #core-customize related to what we focus on for customizer in the immediate term.
    • We’re identifying some smaller, quick wins we can do to improve the customization experience while content blocks are being built.
    • Update coming on Make/Core soon for more ways to get involved and a separate post from @karmatosed on Make/Design for some ways to help us test the existing customization flow
    • Customize team meeting is weekly at Monday 17:00 UTC in #core-customize, please do join us for general brainstorming and ticket triage (see also: prior meeting notes)

    Editor team update

    • Please read and comment on the “Editor Technical Overview” post
    • Recap of #core-editor meeting on a target of a prototype plugin for exploring these concepts from @matveb: Yes, target could be:
      • Data structure.
      • Parsing mechanism.
      • General UI for block display / controls.

    Trac Ticket(s)

    • #39535: Canonical redirects disallow tag named comments
      • @asalce: looking to get owner on the ticket and review of patch
      • will ping @markjaquith or @dd32 as maintainers of Canonical component
  • Andrew Rockwell 3:41 am on January 19, 2017 Permalink |
    Tags: ,   

    Week in Core, January 11th – 17th, 2017 

    Welcome back the latest issue of Week in Core, covering changes [39759-39923]. Here are the highlights:

    • 165 commits
    • 44 contributors
    • 87 tickets created
    • 9 tickets reopened
    • 83 tickets closed

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

    Code Changes


    • List Tables: Pass the $which parameter to restrict_manage_posts filter instance in WP_Media_List_Table, missed in [37422]. [39917] #38772
    • Improve tab character width in Plugins and Themes editor. [39897] #38684

    Build/Test Tools

    Bundled Theme

    • Twenty Seventeen: Remove duplicate global $post declaration in twentyseventeen_front_page_section(). [39909] #39590
    • Twenty Seventeen: Correct @param entries for twentyseventeen_custom_colors_css filter. [39901] #39575
    • Twenty Seventeen: Remove extra asterisk from a translator comment so the comment could be parsed correctly. [39894] #39116

    Cache API

    • Docs: Add missing @param type for wp_cache_get_last_changed(). [39900] #39571


    • dbDelta: Ignore index subparts when checking for duplicate indices. [39921] #34870


    External Libraries


    • Tests: wpautop() should not add extra before. [39914] #39307
    • Fix wpautop() to stop adding paragraph tags around “. [39912] #39307


    • Move “Site Language” setting above “Timezone”. [39885] #38562


    • Use a consistent error message for file type errors on uploading. [39891] #33242


    • Post-4.7.1 version bump for 4.7 branch. [39883]
    • Only show major version in readme.html for 4.7 branch [39871]
    • Media: Fix exif_imagetype check in wp_get_image_mime [39851-39861]
    • Tests: Replace broken codeispoetry.png file. [39848-39849]
    • Use plural string ‘Maintenance and Security Releases’ since we have two now [39847]
    • REST API: Change which users are shown in the users endpoint. [39844]
    • Media: Improve image filetype checking. [39832-39842]
    • Updates: Translate plugin data on the Updates screen. [39808]
    • Themes: Fix markup for theme name fallbacks. [39807]
    • Multisite: Use wp_rand() in signup key creation. [39795-39806]
    • Mail: Disable wp-mail.php when mailserver_url is mail.example.com. [39772-39782][39784]


    • Docs: Use a consistent description for $plugin parameter in various plugin API functions. [39890] #36333
    • Docs: Improve the DocBlock for validate_plugin(). [39889] #36333

    Posts, Post Types

    • Increase the height of post slug input to prevent certain characters from being cut in Firefox on Windows. [39905] #28084



    • Docs: In wp_set_object_terms(), add a note that passing an empty value as $terms argument will remove all related terms. [39893] #36690

    Text Changes

    • Taxonomy: Add an explanation for “Parent” dropdown for hierarchical custom taxonomies. [39895] #23447


    • Add a unit test for get_theme_feature_list() to make sure that the list of theme features pulled from the WordPress.org API returns the expected data structure. [39906] #28121
    • Docs: After [37083], change “HEX format” to “3- or 6-digit hexadecimal form” for clarity. [39888] #36336
    • Use curly braces for variables inside strings in `get_page_template() to explicitly specify the end of the variable name. [39884] #38625


    • Strip browser inserted <u> and <font> tags from inside links when copying and pasting in IE and Edge. [39916] #39570
    • Ensure the inline toolbar is shown and properly positioned when there are several wpview blocks in the editor and the user selects one after the other. [39910] #38849
    • Prevent the inline toolbar from appearing on partially selected wpview nodes. This can happen when HTML is initially loaded in the editor and wpview is the first node, or sometimes on repeatedly pasting the same wpview. [39904] #38849
    • When inserting a wpview, place the caret after is so the user can continue typing without interruption. [39903] #39337
    • Improve removal of spaces from empty paragraphs when loading HTML in the editor. [39902] #39437



    • Introduce signup_site_meta and signup_user_meta for filtering signup metadata in wpmu_signup_blog() and wpmu_signup_user(), respectively. [39920] #39223
    • User Query: Cast $user_total as an int. [39915] #39297
    • I18N: Reference correct placeholder in a translator comment added in [30333]. [39908] #30264
    • Display the name of user being edited on Edit User screen. [39907] #28182
    • Docs: Make $meta parameter description in multisite signup and registration functions more consistent. [39887] #38781
    • In wpmu_signup_blog() and wpmu_signup_user(), pass unserialized signup meta data to after_signup_site and after_signup_user filters introduced in [34112], to match the documented value. [39886] #38781


    • In unregister_sidebar(), rename the $name parameter to $sidebar_id for consistency with is_registered_sidebar(). [39892] #35147
    • Add nonce for widget accessibility mode. [39760-39771] #23328

    Thanks to @aaroncampbell, @afercia, @afzalmultani, @Ankit K Gupta, @azaozz, @barryceelen, @ccprog, @dd32, @diddledan, @DrewAPicture, @dspilka, @F J Kaiser, @gitlost, @iandunn, @iseulde, @ixkaito, @jackreichert, @jblz, @jeremyfelt, @jnylen0, @joemcgill, @johnjamesjacoby, @kuck1u, @MaximeCulea, @Mista-Flo, @netweb, @ocean90, @pavelevap, @pbearne, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @raggedrobins, @rmccue, @runciters, @seanchayes, @SergeyBiryukov, @Soean, @swissspidy, @theMikeD, @tmatsuur, @vortfu, and @wpsmith for their contributions!

  • Andrew Rockwell 8:42 pm on January 14, 2017 Permalink |
    Tags: ,   

    Week in Core, January 4th – 10th, 2017 

    Welcome back the latest issue of Week in Core, covering changes [39666-39758]. Here are the highlights:

    • 93 commits
    • 35 contributors
    • 100 tickets created
    • 8 tickets reopened
    • 80 tickets closed

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

    Code Changes


    • Docs: Remove incorrect @param tags for admin_print_footer_scripts-{$hook_suffix} and admin_footer-{$hook_suffix} dynamic actiona. [39755] #39527

    Build/Test Tools

    • Build: Update pinned version of grunt-cssjanus for the 4.0 branch to hopefully please the build. [39747-39748] #29038

    Bundled Theme

    • Twenty Seventeen: Expand a changelog entry added in [39742] with the new item name. [39752] #39489
    • Twenty Seventeen: Correct @param entries for twentyseventeen_content_width, twentyseventeen_custom_colors_saturation and twentyseventeen_social_links_icons filters. [39733] #39488
    • Twenty Seventeen: Correct @param entry for twentyseventeen_front_page_sections filter. [39732] #39488
    • Twenty Seventeen: Introduce a theme-specific filter twentyseventeen_starter_content for customizing the starter content array. [39720] #39109
    • Upgrade: Fix the installation of TwentySeventeen upon upgrade from an early version. [39687] #38551, #30799, #39138


    • Docs: Use correct closing tag in submit_field description in comment_form(). [39753] #39508


    • Correct a comment in get_theme_starter_content() added in [39561]. [39751] #39104
    • Docs: Correct @access entries and duplicate hook references in WP_Customize_Selective_Refresh. [39734] #39501
    • Prevent removal of underline upon hover/focus for nav menu deletion links. [39696] #37527, #39444
    • Remove extra left padding in core for site title and widgets in preview. [39695] #38651, #39349
    • Ensure theme_mod-cache of custom_css lookup of -1 short-circuits a WP_Query from being made. [39694] #35395, #39259
    • CDon’t query for postmeta for Custom CSS (for not-current-themes) and Customizer Changeset posts. [39692-39693] #39194
    • Ensure theme_mod-cache of custom_css lookup of -1 short-circuits a WP_Query from being made. [39688] #35395, #39259
    • Update customize.php URL with changeset_uuid param the instant a change is made instead of deferring until the changeset update request responds. [39686] #39227
    • Remove extra left padding in core for site title and widgets in preview. [39685] #38651, #39349
    • Prevent removal of underline upon hover/focus for nav menu deletion links. [39677] #37527, #39444
    • Docs: Correct @access tag for WP_Customize_Partial::id_data property. [39674] #39464
    • Docs: Add missing @since and @access tags for WP_Widget_Form_Customize_Control::to_json() and ::render_content(). [39673] #39463


    • Docs: Move install_network() DocBlock after the function_exists() call. [39709] #39478


    • Docs: Use 3-digit, x.x.x style semantic versioning for @since entries in wp-admin/js/word-count.js. [39739] #37718
    • Docs: Add documentation for wp-admin/js/editor.js. [39738] #38933
    • Always add page-template-default class to the editor body when the template is not specified. This matches the behavior on the front-end. [39678-39679] #39368

    External Libraries



    • Docs: Add missing @since entry for Walker::unset_children(). [39741] #39506
    • Update copyright year to 2017 in license.txt. [39698-39707] #39433
    • Docs: Correct rest_insert_* duplicate hook references in REST API. [39671] #39371
    • Docs: Add missing session_token_manager duplicate hook reference in wp-includes/class-wp-session-tokens.php. [39670] #39371
    • Docs: Correct comment_email duplicate hook reference in wp-admin/includes/class-wp-comments-list-table.php. [39669] #39371
    • Docs: Add missing duplicate hook references in wp-admin/includes/ajax-actions.php. [39668] #39371


    • Docs: Correct @access entries for WP_Locale::init() and WP_Locale::register_globals(). [39737] #39504
    • Add post type context to “Featured Image” post labels. [39667] #39458


    • In PHPMailer 5.2.7 the case of the Send() method changed to send(), update our call for consistency with the library. [39691] #39469


    • Docs: Use 3-digit, x.x.x style semantic versioning for @since entries in wp-admin/js/image-edit.js. [39740] #38748


    • Posts, Post Types: Add a @since entry for archives post type label introduced in [35382]. [39666] #16075


    Options, Meta APIs

    • Docs: Add variable to @param entry for whitelist_options filter. [39708] #39477

    Posts, Post Types

    • Use an existing string for “Invalid post type” error message. [39756] #39171
    • Docs: Add missing @param tag for show_post_locked_dialog filter. [39710] #39479


    • Docs: Add missing @since and @access tags for WP_Date_Query::is_first_order_clause(). [39672] #39462



    • Docs: Make @deprecated entry for wp_kses_js_entities(), deprecated in [38785], consistent with other entries. [39758] #39541


    • Docs: Correct @since and @access tags for WP_Term_Query::get_terms() and WP_Term_Query::parse_orderby_meta(). [39675] #39467


    • Docs: Add missing @since entries for WP_Theme class methods. [39736] #39503
    • Docs: Correct the DocBlock for get_header_video_url(). [39676] #39468


    • Docs: Move install_global_terms() DocBlock after the function_exists() call. [39754] #39526
    • Avoid creating nonce during installation. [39697] #39047
    • Updates: Properly define $filesystemForm to handle error in modals. [39689-39690] #39057
    • Avoid creating nonce during installation. [39684] #39047


    • Docs: Change @param type for $user_object in WP_Users_List_Table::single_row() from object to WP_User to be more accurate. [39757] #39536
    • Docs: Correct @access entry for WP_User::filter property. [39735] #39502, #39278

    Thanks to @ocean90 @Presskop, @aaroncampbell, @adamsilverstein, @asalce, @azaozz, @BharatKambariya, @celloexpressions, @chiragpatel, @dd32, @dlh, @ireneyoast, @Jaydeep Rami, @karmatosed, @keesiemeijer, @ketuchetan, @michalzuber, @monikarao, @Nikschavan, @nullvariable, @pento, @priyankabehera155, @prosti, @ramiy, @rmccue, @sanket.parmar, @sebastian.pisula, @SergeyBiryukov, @sirbrillig, @stevenkword, @teinertb, @terwdan, @timph, @truongwp, and @westonruter for their contributions!

  • Felix Arntz 11:22 am on January 11, 2017 Permalink |
    Tags: , , ,   

    Controlling access to REST API user functionality for multisite 

    Following last week’s discussion in #core-multisite (read the recap) this week’s office hours agenda was to continue the chat about the multisite-related enhancements for the REST API users endpoint, focussing heavily on how to access the required functionality. Here is a wrap-up of the discussion.

    Chat log in #core-multisite

    Attendees: @jeremyfelt, @jnylen, @nerrad, @ipstenu, @earnjam, @kenshino, @maximeculea, @mikelking, @lukecavanagh, @flixos90

    Now that the way on how one should be able to modify user roles per site was clarified last week, this week the focus laid on where one should be able to perform those actions. The current state of the wp-json/wp/v2/users endpoint in multisite is:

    • The users overview accessible with a GET request to wp-json/wp/v2/users only lists users that are part of the current site.
    • When creating a user with a POST request to wp-json/wp/v2/users, that user is created and added to the current site. When providing the roles parameter, the passed roles are added to the user, otherwise the user will still be part of the site, but without any role. See #38526 for background.
    • It is possible to both read and edit any user from any site with a request to wp-json/wp/v2/users/<id>, regardless of whether the user is part of that site.
    • A DELETE request to wp-json/wp/v2/users/<id> results in an error. See #38962 for background.

    After the discussion about how to be able to add a specific user to a site, update their site capabilities and remove them from a site, this week’s chat revolved around where these actions can be accessed, as they are for the most part network-specific actions not available to a site administrator. The approach that was agreed on is:

    • The users overview at wp-json/wp/v2/users should continue to only show users of that site by default, but a request like wp-json/wp/v2/users?global=true should show all users in the WordPress setup. This parameter must only be available to network administrators though, more specifically users with the manage_network_users capability. In the future a network parameter might also be introduced for support of multi networks, but at this point core does not support querying users per network. Accessing global users should be available from all sites in a setup instead of only from the main site. While this approach makes these endpoints duplicates of each other, it has several benefits like preventing the requirement for cross-domain requests, allowing easier API discovery and not requiring the main site of a setup to be exposed to REST API calls to a sub site.
    • Assigning an existing user to a site and removing a user from a site should generally be only available to network administrators, and the site administrators of the site that is being interacted with.
    • Similarly, editing a user that does not belong to the current site should only be possible for a network administrator. Currently this is available to site administrators as well which is probably wrong.
    • Deleting any user completely should only be available to a network administrator. A good way to handle the reassign parameter needs to be found though.

    Before coming to the conclusion that dealing with multisite functionality at the existing users endpoint, the possibility of introducing a multisite-specific endpoint only available on the main site was discussed. However this was considered not practical due to the nature of how users work in WordPress. Having separate endpoints for other network-wide functionality might still be a possibility though as long as that component solely affects the network admin, so this idea is something to keep in mind for thought about further network functionality endpoints in the future.

    Back to the users endpoint, one related question that came up is:

    • Should the sites a user belongs to be available at the wp-json/wp/v2/users endpoint or at a future wp-json/wp/v2/sites endpoint? If they were available in the wp-json/wp/v2/users endpoint, every user entity would have a new sites key available if the current user had sufficient permissions to see these. If they were available in the wp-json/wp/v2/sites endpoint, that endpoint could easily support this functionality through usage of a user parameter.

    @jeremyfelt suggested to look at the “Add New User” screen in the site admin to have a good use-case for how to scaffold the multisite functionality of the API endpoint. This has helped during this week’s office-hours and can also be beneficial in the future. Eventually this screen should be revamped entirely, being powered by the REST API.

    Regarding the enhancements of the users endpoint, a general ticket for this task was opened at #39544. This ticket is meant to be used for discussion on the topic, while separate smaller tickets should be opened for actually implementing the individual pieces. For now feedback is welcome on that ticket. The discussion on multisite improvements for the REST API will continue at Tuesday 17:00 UTC.

    /cc @rmccue and @kadamwhite



    • James Nylen 6:40 pm on January 11, 2017 Permalink | Log in to Reply

      Excellent writeups and discussion, thanks Felix and everyone else involved.

      > It is possible to both read and edit any user from any site with a request to wp-json/wp/v2/users/, regardless of whether the user is part of that site.

      I think this should require the new `global=true` parameter as well. This is a change we would need to make sooner rather than later, in 4.7.2.

      • Felix Arntz 8:02 pm on January 11, 2017 Permalink | Log in to Reply

        I agree, however I think we should be fine by prohibiting access to users that are not part of the site as that would be the fix for the current bug. Adding the `global` parameter can happen in 4.8 IMO, as we only start supporting multisite behavior there in general.

  • Jeremy Felt 8:04 pm on January 9, 2017 Permalink |
    Tags: , , ,   

    Improving the REST API users endpoint in multisite 

    One of the objectives for multisite is sorting how users are managed with the REST API. This was one of the agenda items for last week’s #core-multisite office hours and generated some good discussion. Here’s a wrap-up of the ideas and thoughts from that discussion.

    Chat log in #core-multisite

    Attendees: @iamfriendly, @johnjamesjacoby, @nerrad, @florian-tiar, @mikelking, @earnjam, @jeremyfelt

    Users in multisite exist globally and are shared among sites on one or more networks. Users are associated with sites in the user meta table with a wp_#_capabilities key.

    The current state of the wp-json/wp/v2/users endpoint for multisite is:

    • A POST request for a new global user to the main site creates the user and associates them with the main site only.
    • A POST request for a new global user to a sub site creates the user and associates them with the sub site only.
    • A POST request for an existing global user results in an error.
    • A PUT request for an existing global user to a sub site updates the user’s meta with a capability for that sub site.
    • A DELETE request on multisite is invalid and results in an error. See #38962.

    It is not possible to remove a user from an individual site or to delete the user from the network.

    Previous tickets: #38526, #39155, #38962, #39000

    The following are a few thoughts expressed separately from the above summary.

    • The right way to associate existing objects over the REST API is with a PUT request.
    • The right way to disassociate existing objects is with a PUT request.
    • Linked previous discussion – “Deleting an item should always delete an item
    • We already have functions like remove_user_from_blog() and add_user_to_blog() available to us.
    • Does “add” invite or literally add? This can probably be included as data in the PUT request.
    • What happens if an API client is built for single site and then that site gets switched to multisite?
    • Handling bulk actions on an endpoint would be nice. (e.g. Add a user to multiple sites) No endpoint has implemented batch handling yet though.

    Initial tasks:

    • It should be possible to remove a user from a site with a PUT request to the wp-json/wp/v2/users/# endpoint.
    • It should be possible to delete a global user with a DELETE request to the wp-json/wp/v2/users/# endpoint once all sites have been disassociated.

    New tickets will be created soon for these tasks. Please leave any initial feedback in the comments on this post covering the assumptions and conclusions made above. There will be another round of discussion during tomorrow’s #core-multisite office hours at Tuesday 17:00 UTC.

    /cc @rmccue and @kadamwhite

    • James Nylen 8:12 pm on January 9, 2017 Permalink | Log in to Reply

      I am assuming that “`PUT` request” is being used as a shorthand to refer to any of `POST/PUT/PATCH` to an existing user. These should be treated equivalently via the `WP_REST_Server::EDITABLE` constant.

    • John James Jacoby 8:22 pm on January 9, 2017 Permalink | Log in to Reply


    • Darren Ethier (nerrad) 8:33 pm on January 9, 2017 Permalink | Log in to Reply

      One thing that may have been brought up elsewhere, but I don’t think was brought up in the meeting (likely because its something that will happen on further implementation) is whether the schema response for the users endpoint would change in a multisite environment vs single site. For instance, does the `user` resource in a multisite environment include the sites the user belongs to? Is that something that should be exposed? If so, then its something that would need to go into the schema as well.

      • John James Jacoby 12:11 am on January 10, 2017 Permalink | Log in to Reply

        You’re right that this is an implementation detail. My hunch is not as part of the default user response (which probably has higher value as something that doesn’t have too many variants) but it would be useful to have a dedicated endpoint to get the sites of a User – that way the response can more easily be setup behind its own capability check.

    • Brainy 12:30 am on January 10, 2017 Permalink | Log in to Reply

      I may miss something (the wp-api.org documentation doesn’t tell me at least), but I think it would be great if there would be a way to list users sites via rest api as well since the current way of looping get_blogs_of_users is very, very slow.

    • Knut Sparhell 1:55 am on January 10, 2017 Permalink | Log in to Reply

      I think there should be a network level (endpoint) where users of a multisite may be removed from all sites in a network, or actually deleted if only one network. Then a top (installation) level endpoint for actually deleting users in a multi-network. When a removed or deleted user is the only/last user of it’s primary site, then maybe also mark the site as deleted.

    • Ryan McCue 2:28 am on January 10, 2017 Permalink | Log in to Reply

      Definitely want to see better API support for multisite. To that effect, @jnylen0 has volunteered to be the multisite API coordinator, so you’ll have a permanent point of contact. Obviously, the rest of the team is also always around. 🙂

      • James Nylen 2:30 am on January 10, 2017 Permalink | Log in to Reply

        s/volunteered/been volunteered/ 😉

        I’m happy to help, though, and it makes a lot of sense for me to be involved with this: I’m also responsible for the WP REST API integration on WordPress.com, the largest multisite installation in the world.

  • Andrew Rockwell 11:24 pm on December 16, 2016 Permalink |
    Tags: ,   

    Week in Core, December 7 – 13, 2016 

    Welcome back the latest issue of Week in Core, covering changes [39530-39598]. Here are the highlights:

    • 69 commits
    • 39 contributors
    • 143 tickets created
    • 29 tickets reopened
    • 100 tickets closed

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

    Code Changes


    • Remove the WordPress version number from readme.html. [39583] #35554
    • De-Emphasise the minor (x.y.Z) version in readme.html by including only the major version for the 4.7 branch. [39582] #35554
    • Accessibility: Remove inappropriate content from the Edit Categories and Edit Tags screens headings. [39553] #26601
    • Accessibility: Remove inappropriate content from the Edit Comments screen heading. [39552] #26601
    • Accessibility: Remove inappropriate content from the Network screens headings. [39551] #26601
    • Accessibility: Remove inappropriate content from the Menus screen heading. [39543] #26601
    • Accessibility: Remove inappropriate content from the old Edit Media screen heading. [39542] #26601
    • Accessibility: Remove inappropriate content from the Widgets screen heading. [39541] #26601
    • Accessibility: Remove inappropriate content from the Edit User screen heading. [39538] #26601
    • Accessibility: Remove inappropriate content from the Link Manager screens headings. [39537] #26601
    • Accessibility: Remove inappropriate content from the Add Plugins screen heading. [39536] #26601
    • Accessibility: Remove inappropriate content from the Plugins screen heading. [39535] #26601
    • Accessibility: Remove inappropriate content from the Users screen heading. [39534] #26601


    • Bootstrap: Re-initialize any hooks added manually by object-cache.php.
      Prior to 3.1 if a object cache dropin wanted to add actions, they needed to use $wp_filter directly. [39565] #39132

    Build/Test Tools

    • Facilitate SVN and Git being co-located in the same directory. [39577] #39245
    • Remove some more randomness. [39556] #37371
    • Reuse another fixture in the user capability tests. [39555] #38716
    • Remove commented out tests that have existed in an unimplemented state since the dawn of the test infrastructure. [39554] #38716



    • Prevent navigation in preview when clicking on child elements of preview links that have non-previewable URLs. [39584-39585] #39098
    • Prevent edit shortcut from losing event handler after selective refresh. [39581] #27403, #39100
    • Deprecate page_home nav menu item starter content in favor of home_link; replace usage in Twenty Seventeen. [39561], [39575] #38615, #38114, #39104
    • Allow (optional) url parameter to be omitted in intercepted calls to history.pushState() and history.replaceState() in customize preview. [39547], [39574] #39175
    • Trim whitespace for URLs supplied for external_header_video to prevent esc_url_raw() from making them invalid. [39560], [39573] #38172, #39125
    • Fix ability to shift-click on placeholder/pre-saved nav menu items in preview to focus on corresponding control. [39562], [39572] #39102
    • Use selected user language for edit shortcuts in preview instead of site language. [39545], [39571] #39009
    • Fix inability to delete nav menus by preventing preview filters from being added during customize_save admin ajax request. [39558], [39570] #30937, #39103
    • Prevent scrolling custom_css textarea to top when pressing tab. [39557], [39569] #38667, #39134
    • Use esc_url_raw() instead of wp_json_encode() to eliminate extraneous slashes when outputting background image URL in CSS url(). [39546], [39568] #22058, #39145
    • Prevent single quotes (apostrophes) in custom_css values from unexpectedly causing false positives for unbalanced character validation errors. [39559], [39567] #39218, #35395, #39198
    • Collapse available nav menu items panel when clicking outside over preview or over existing items. [39548] #38953

    External Libraries

    • Libraries: Update zxcvbn from version 1.0 to 4.4.1 [39596] #31647


    • Correctly detect trailing newline when prepending. [39592] #37082
    • Remove most uses of create_function() [39591] #37082
    • Taxonomy: Correct the type for the first parameter of the the_category filter. [39530] #39130

    Login and Registration


    • PDF Images: Avoid a PHP Warning when attempting to process a file without an extension. [39580] #39195


    • Bump the version in package.json to 4.7.1 after [39576]. [39579] #
    • The 4.7 branch is now 4.7.1-alpha. [39576] #

    Options, Meta APIs

    • Options: Prevent unnecessary SQL updates by update_option. [39564] #38903


    • Docs: Correct param definition for WP_Query::query(). [39550] #38963


    • Add support for filename search in media endpoint. [39598] #39092
    • Allow sending an empty or no-op comment update. [39597] #38700
    • Do not include the password argument when getting media items [39595] #38977
    • Do not error on empty JSON body [39594] #39150
    • Treat any falsy value as false in ‘rest_allow_anonymous_comments’. [39566] #39010
    • Allow schema sanitization_callback to be set to null to bypass fallback sanitization functions. [39563] #38593, #39042


    • Tests: Use wp_delete_user() during teardown to delete a single site’s user. [39590] #39065
    • Multisite: Replace is_super_admin() with manage_network in get_dashboard_url(). [39589] #39065, #37616
    • Multisite: Handle capability check for removing oneself via map_meta_cap(). [39588] #39063, #37616
    • Multisite: Replace is_super_admin() with update_core for update permissions. [39540] #39060, #37616
    • Multisite: Remove redundant is_super_admin() when checking for edit_others_posts. [39539] #39059, #37616


    • Use get_term_link() instead of get_category_link() in get_term_parents_list(). [39593] #17069
    • Restore the ability to use string-based $args in wp_get_object_terms(). [39578] #39215
    • Introduce get_term_parents_list(). [39549] #17069




    • Style the super admin message on the user editing screen as a notice, not a success message. [39531] #39131

    Thanks to @afercia, @boonebgorges, @bradyvercher, @celloexpressions, @chandrapate, @Christian1012, @david.binda, @dd32, @flixos90, @Hristo Sg, @iaaxpage, @jblz, @jnylen0, @joehoyle, @johnbillion, @jorbin, @JPry, @kafleg, @keesiemeijer, @ketuchetan, @kkoppenhaver, @obenland, @ocean90, @pento, @peterwilsoncc, @rachelbaker, @rafaehlers, @rmccue, @rockwell15, @salcode, @SergeyBiryukov, @sgolemon, @Shelob9, @sirbrillig, @sstoqno, @tomdxw, @tyxla, and @westonruter for their contributions!

  • Andrew Rockwell 8:34 pm on December 8, 2016 Permalink |
    Tags: ,   

    Week in Core, November 30 – December 6, 2016 

    Welcome back the latest issue of Week in Core, covering changes [39380-39529]. Here are the highlights:

    • 150 commits
    • 63 contributors
    • 140 tickets created
    • 17 tickets reopened
    • 104 tickets closed
    • WordPress 4.7 released 🎉

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

    Code Changes


    • Accessibility: Remove inappropriate content from the Themes screen heading. [39528] #26601
    • Accessibility: Remove inappropriate content from the Add Themes screen heading. [39527] #26601
    • Accessibility: Remove inappropriate content from the Media Library screens headings. [39526] #26601

    Build/Test Tools

    • Correctly set up the current screen during list table tests so that they don’t fail when run individually. [39481] #38761
    • Specify exact node version in package.json. [39480], [39478] #35105, #38657
    • Remove PHP 7.1 from allowed failures [39424-39425] #37625

    Bundled Theme

    • Default Themes: Update version numbers and readme files for 4.7 release [39496] #38858
    • Twenty Seventeen: Fix CSS specificity problem with CSS feature query for object-fit [39495] #39073
    • Twenty Seventeen: Improve display of video header and header image in modern browsers [39485], [39483] #39035
    • Twenty Seventeen: Add specific font stack for Thai language [39484], [39482] #38937
    • Twenty Seventeen: Improve ARIA for the nav menu. [39451-39452] #39029, #39026
    • Twenty Seventeen: Ensure header text color updates in Customizer preview when cleared [39447-39448] #38993
    • Twenty Seventeen: Fix broken menu toggle in Customizer after menu items are added [39419], [39423] #38992
    • Twenty Seventeen: Fix style issues with gallery image links [39418], [39422] #38969
    • Twenty Seventeen: Hide front section panels on page load of Customizer. [39417], [39421] #38951
    • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39416] #38995
    • Twenty Seventeen: Better handling of custom headers when no image is set. [39413-39414] #38995
    • Twenty Seventeen: Make spacing on pages without comments consistent [39404-39405] #38972
    • Twenty Seventeen: Make sure header text color is applied when color schemes are active. [39397-39398] #38980
    • Twenty Seventeen: Make fixed navigation apply at correct height on front page, without header video or image [39394], [39392] #38927
    • Twenty Seventeen: Provide a background color fallback for non-webkit browsers on input styles [39388] #38939
    • Twenty Seventeen: Allow child themes to easily extend custom color patterns [39386] #38949
    • Twenty Seventeen: Make screen reader text on scroll arrow more meaningful [39384] #38970
    • Twenty Seventeen: Keep header videos from extending past footer. [39380-39381] #38950


    • Merge a similar string between comments.php, XML-RPC and the REST API comments controller. [39508] #39013


    • Prevent infinite full refresh from occurring when selective refresh falls back for a nav menu that has items excluded from rendering via filtering. [39510-39511] #38612
    • Defer populating post_name for auto-draft posts in customized state until posts are published. [39506-39507] #39078
    • Ensure changeset_uuid query param is removed from the customize.php window’s location once a changeset has been published (committed) with starter content. [39504-39505] #39081
    • Prevent posts/pages imported via starter content from being dropped when adding post/page stubs via nav menus and the dropdown-pages control. [39502-39503] #38114, #34923, #39071
    • Ensure textarea for Custom CSS displays as code (in LTR) when an RTL language is active. [39499-39500] #35395, #39085
    • Ensure a custom_css post insertion gets an initial post revision. [39479], [39477] #30854, #38672, #35395, #39032
    • Custom CSS: Change the help link to something better for users. [39467], [39466] #39015
    • Fix posts limit query arg for WP_Query from incorrect number to posts_per_page. [39434-39435] #39022
    • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39411] #38114, #38928
    • Reject a changeset update when a non-future date is provided and also ensure that a published changeset always gets set to the current date/time. [39409-39410] #30937, #38943
    • Fix handling of the nav menu item labels (titles) that match defaults (original titles) and fix the display of item type labels. [39395], [39393] #38015, #38955





    • Accessibility: Improve keyboard accessibility avoiding confusing tab stops in the Media views. [39529] #30599
    • Docs: Add inline documentation for image-edit.js. [39493] #38748
    • Fix regression with display of small images in media library. [39399], [39396] #38965
    • Docs: Document the usage of the global $wpdb in _filter_query_attachment_filenames(). [39390] #38973


    • Tag 4.7 [39525] #
    • WordPress 4.7 “Vaughan”. [39524] #
    • Post-RC3 bump. [39519] #
    • WordPress 4.7 RC3. [39516] #
    • Post-RC2 bump. [39474] #
    • WordPress 4.7 RC2. [39473] #
    • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39415]

    Options, Meta APIs

    • REST API: Register the admin_email setting in single site only. [39470-39472] #38990
    • REST API: Site URL setting should not be present on multisite installations. [39468] #39005
    • REST API: Correct the admin_email setting description for single site installs. [39406] #38990
    • Multisite: Display different descriptions for multisite or single site installations. [39407] #38990
    • Options: Pass the $passed_default parameter to the 'default_option_{$option} filter in add_option(). [39382] #38176, #38930



    • Comments: Merge similar strings between comments.php and the REST API comments controller. [39490-39491] #39014
    • Merge similar date strings in the revisions and comments controllers. [39488-39489] #39016
    • Treat any falsy value as false in ‘rest_allow_anonymous_comments’. [39487] #39010
    • Docs: Add missing REST API-related args to register_post_type() and register_taxonomy(). [39462-39463] #39023
    • Merge similar strings in a comments endpoint parameter description. [39457] #39036
    • Fix bug where comment author and author email could be an empty string when creating a comment. [39446], [39444] #38971
    • Fix handling of some orderby parameters for the Posts controller. [39440-39441] #38971
    • Disable DELETE requests for users in multisite. [39438-39439] #38962
    • Return a WP_Error if meta property is not an array. [39436-39437] #38989
    • Add test for creating a comment with an invalid post ID. [39408] #38991
    • Fix incorrect uses of rest_sanitize_value_from_schema(). [39400-39401] #38984


    • Don’t assign the delete_site capability to anyone on single site installs. [39494] #38326
    • Multisite: Replace is_super_admin() with manage_network for admin bar permissions. [39492] #39064, #37616


    • Docs: Update an @since as there will not be a 4.6.2 before 4.7. [39475-39476] #37291
    • REST API: Capability check for editing a single term should use the singular form. [39464] #35614, #39012
    • REST API: Use the correct error message when editing a single term. [39460-39461] #39017
    • REST API: Fix incorrect capability check on term create. [39402-39403] #35614, #38958
    • Performance: Revert [38677] from the 4.7 branch. This avoids fatal errors caused with recursive calling of term functions within the get_terms filter. [39454] #21760


    • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39412] #38114, #38928


    • Fix the styling of notices generated by the editor UI. [39501] #38917


    • Clarify the return value of get_current_user_id() for non-logged-in users. [39486] #39051
    • REST API: Require the reassign parameter when deleting users. [39426-39427] #39000

    Thanks to @andizer, @mor10, @adamsilverstein, @afercia, @azaozz, @boonebgorges, @celloexpressions, @ChopinBach, @clorith, @coffee2code, @davidakennedy, @dd32, @desrosj, @dlh, @flixos90, @georgestephanis, @helen, @helen, @hnle, @iaaxpage, @imnok, @jbpaul17, @jeremyfelt, @jnylen0, @joedolson, @joehoyle, @joemcgill, @johnbillion, @jorbin, @kadamwhite, @karmatosed, @ketuchetan, @laurelfulford, @littlebigthing, @lucasstark, @melchoyce, @michaelarestad, @mikeschroder, @mt8.biz, @nacin, @netweb, @ocean90, @ovenal, @pento, @peterwilsoncc, @presskopp, @rachelbaker, @rahulsprajapati, @ramiabraham, @ramiy, @rensw90, @rianrietveld, @rmccue, @samuelsidler, @sayedwp, @SergeyBiryukov, @sstoqnov, @The PHP tea, @timmydcrawford, @utkarshpatel, and @westonruter for their contributions!

  • Andrew Rockwell 3:54 am on November 25, 2016 Permalink |
    Tags: ,   

    Week in Core, November 15 – 22, 2016 

    Welcome back the latest issue of Week in Core, covering changes [39233-39340]. Here are the highlights:

    • 108 commits
    • 53 contributors
    • 114 tickets created
    • 16 tickets reopened
    • 101 tickets closed

    Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

    Code Changes

    Bundled Theme

    • Twenty Seventeen: CSS coding standards [39340] #38901
    • Twenty Seventeen: Ensure galleries display correctly in IE11. [39339] #38872
    • Twenty Seventeen: Avoid an undefined index notice after [39291]. [39317] #38847
    • Twenty Seventeen: Adds background-attachment: fixed; to devices that should support it [39297] #38395
    • Twenty Seventeen: Ensure the use of proper image size for custom header image [39291] #38847
    • Twenty Seventeen: Remove some extraneous function calls. [39286] #38848
    • Twenty Seventeen: Additional default header image optimizations. [39279] #38793
    • Twenty Seventeen: Add styles for custom header video controls. [39273] #38697
    • Twenty Seventeen: Compress the default header image. [39248] #38793


    • REST API: On Comment create, limit the ability to set the author_ip value directly. [39302] #38819
    • REST API: Change “ipv4” types to “ip” to support ipv6. [39296] #38818
    • REST API: Remove the karma property and query parameter from the Comments endpoints. [39292] #38821
    • REST API: On comment create, return an error if the type property is set to anything other than comment. [39290] #38820
    • REST API: On comment create, return an error if the post parameter does not relate to a valid WP_Post object. [39288] #38816
    • REST API: On comment create, fallback to the user_agent header value. [39287] #38817
    • Query used to fill comment descendants should reset ‘offset’ and ‘number’ params. [39274] #37696


    • Prevent selective refresh from causing infinite fallback refreshes when nav menu contains invalid items. [39333] #38890
    • Remove iframe-specific behaviors from customize preview when previewing on frontend and not contained inside iframe. [39332] #30937, #38867
    • Ensure that WP_Customize_Manager::save_changeset_post() returns setting_validities even for supplied values that are unchanged from values in changeset. [39320] #38705, #30937, #38865
    • Ensure WP_Customize_Setting::value() returns previewed value for custom types utilizing the customize_value_{$id_base} filter. [39318] #38864
    • Autoprefixer for [39249]. [39301] #29158
    • Remove obsolete edit shortcut style rules from Twenty Seventeen. [39285] #38776
    • Ensure Close button actually closes customizer (instead of going back) after switching to a different theme inside a customize-loader iframe. [39271] #38833
    • Prevent edit shortcut buttons from being inserted into container elements in the head or into elements which should not get interactive children. [39270] #27403, #38672, #38830
    • Allow URL for Codex link in Additional CSS section to be translated. [39268] #35395, #38823
    • More visible focus and hover states for close and back buttons. [39249] #29158
    • Ensure edit shortcuts have same background color regardless of theme colors. [39243] #38776
    • Add !important line-height to edit shortcut buttons. [39242] #38787
    • Allow starter content to apply in a new theme when switching from another theme containing changes. [39241] #38114, #38541
    • Only show video header controls if previewing front page; show explanatory notice when controls are hidden. [39237] #38796, #38778
    • Adjust layout for edit shortcuts only when shown. [39233] #38651


    • Add support for LIKE-escaped tables in ::get_table_from_query(). [39275] #38751



    • Plugin install: De-duplicate a conditional, introduced in [38172]. [39336] #38190
    • Docs: Use 3-digit, x.x.x style semantic versioning for @since 4.7.0 entries. [39281] #37770
    • Tests: Add a missing $message argument for assertEquals() in [39265]. [39267] #23626
    • Tests: Use assertEquals()‘ native functionality for delta comparison in test_wp_convert_bytes_to_hr(). [39265] #23626


    • In wp_dropdown_languages() rename the new show_site_locale_default argument to show_option_site_default. [39331] #38632, #38871
    • Add an additional caching layer for _load_textdomain_just_in_time(). [39330] #37997
    • Introduce more translator comments for strings that contain placeholders but don’t have an accompanying translator comment. [39326] #38882
    • Move the support forums URL in update-related HTTP API error messages to a separate translatable string that is already used elsewhere. [39325] #38880
    • Remove an erroneous @TODO introduced in [39323]. [39324] #38882
    • Begin introducing translator comments for strings which include placeholders but no accompanying translator comment. [39323] #38882
    • REST API: Merge two error messages for edit / update. [39322] #38879
    • REST API: Update error messages in WP_REST_Comments_Controller to use the common text for permission errors. [39321] #38875
    • Use ‘WordPress hook name’ instead of ‘PHP hook name’ in translator comments added in [39315]. [39316] #38862
    • Add translator comments for strings in _deprecated_*() functions. [39315] #38862
    • Remove unnecessary __() calls in _rotate_image_resource() and _flip_image_resource(). [39314] #38862
    • REST API: Merge some more permission error strings missed in [39309]. [39313] #38857
    • Text Changes: Merge strings referring to list_users capability. [39312] #38857
    • Merge two ‘RSS Error:’ strings. [39311] #38861
    • REST API: After [39306], move author_ip argument to the correct place. [39310] #38822
    • REST API: Merge and clarify some permission error strings. [39309] #38857
    • Text Changes: Merge and clarify some permission error strings in the admin. [39308] #38857
    • Merge two ‘ERROR:’ strings. [39307] #38860
    • REST API: After [39302], clarify author_ip parameter in error message. [39306] #38822
    • REST API: Merge two similar permission error strings in class-wp-rest-comments-controller.php. [39305] #38857
    • REST API: Merge two similar permission error strings. [39304] #38857
    • REST API: Clarify parameters when used in error strings. [39298] #38822
    • REST API: After [39252] and [39264], uppercase some more ‘ID’ references in translatable strings. [39266] #38791
    • REST API: Uppercase ‘ID’ in endpoint descriptions and error messages for consistency with other strings. [39264] #38791
    • REST API: Unify some more permission error messages. [39259] #38803
    • REST API: Unify permission error messages. [39257] #38803
    • Remove “ tags from translatable strings in wp-includes/class-wp-customize-manager.php. [39254] #38802
    • REST API: Remove two duplicate strings, use the ones we already have. [39252] #38791
    • REST API: Unify permission error messages. [39251] #38791, #34521
    • REST API: After [39238] and [39239], move the remaining translator comments to preceding line. [39245] #38791
    • Docs: Apply documentation standards to the new get_available_languages filter. [39244] #38788
    • REST API: Move translator comments to preceding line. [39239] #38791
    • REST API: Add translator comments to text with placeholders. [39238] #38791
    • Add the get_available_languages filter. [39235] #38788



    • REST API: Check read permissions on posts when viewing comments. [39295]
    • Small coding standards cleanup of wp-custom-header.js. [39277]
    • Post-4.7 beta 4 bump. [39263]
    • WordPress 4.7 Beta 4. [39262]

    Options, Meta APIs

    • REST API: Update description strings to match already existing ones in the admin. [39335] #38807

    Posts, Post Types

    • Accessibility: Improve the Post Attributes meta box fields labels. [39247] #38790
    • Improve sanitisation of templates’ post types. [39236] #38766


    • Set the comment type to a readonly property in the schema. [39337] #38820, #38886
    • Trim trailing slashes from routes. [39329] #38873
    • Correctly map meta keys to field names. [39328] #38786
    • Disable anonymous commenting by default. [39327] #38855
    • Add test case for users/me endpoint that the context param defaults to view. [39293] #38842
    • Allow parent property to be explicitly set to 0 when creating or updating a Post. [39289] #38852
    • Clean up argument and property types. [39250] #38792


    • Update register_taxonomy hook to use WP_Taxonomy object. [39283] #38765
    • Prevent wp_list_categories() from producing not well-nested output if hide_title_if_empty is true. [39280] #38839, #33460

    Text Changes

    • Merge some duplicate strings with the same meaning in error messages, adjust some other strings for consistency and accuracy. [39278] #38808
    • Unify permission error messages in wp-admin/users.php. [39258] #38804
    • Unify permission error message in wp-ajax-response.js. [39253] #34521


    • Prevent unneeded database updates in wp_get_custom_css_post(). [39338] #38866
    • Twenty Seventeen: Make all Codex links in DocBlocks use HTTPS [39300] #38854
    • Twenty Seventeen: Rename the starter content menus to match the menu area names. [39294] #38615
    • Improve a11y and extendability of custom video headers. [39272] #38678
    • Theme starter content: Add reference IDs for most default widgets. [39261] #38615
    • Theme starter content: Refine the content for pages. [39260] #38615
    • Theme starter content: Add more social link items to select from. [39256] #38615
    • Theme starter content: Revamp the credits widget into an about widget. [39255] #38615
    • Remove front page restriction from video header functions. [39240] #38738
    • Customize: Use video-specific labels for buttons in Header Video media control. [39234] #38172


    • Avoid calling editor.focus() on loading the content in the editor. It may trigger scroll-into-view in the browser. Call the quirks fix in TinyMCE directly. [39334] #38511
    • Fix automatic scroll on page load. [39299] #38511
    • Remove extra space in tooltip. [39284] #38063
    • Tews: fix Firefox issues. [39282] #36434, #38511



    Thanks to @adamsilverstein, @afercia, @andy, @azaozz, @boonebgorges, @bradyvercher, @celloexpressions, @chesio, @ChrisWiegman, @danielbachhuber, @davidakennedy, @dd32, @derrickkoo, @dimadin, @flixos90, @folletto, @gitlost, @helen, @iseulde, @jnylen0, @joehoyle, @joemcgill, @johnbillion, @johnpgreen, @jrf, @laurelfulford, @lucasstark, @lukecavanagh, @markoheijnen, @melchoyce, @mikeschroder, @netweb, @ocean90, @odysseygate, @pento, @peterwilsoncc, @Presskopp, @rachelbaker, @ramiy, @rianrietveld, @rmccue, @schlessera, @SergeyBiryukov, @sharkomatic, @sirbrillig, @sstoqnov, @swissspidy, @tharsheblows, @timmyc, @transl8or, @welcher, @westonruter, and @yoavf for their contributions!

  • K.Adam White 11:15 pm on October 13, 2016 Permalink |
    Tags: ,   

    Merge Proposal Discussion: REST API Content Endpoints 

    There are discussion meetings and office hours in #core-restapi at 2016-10-14 14:00UTC and 2016-10-14 19:00UTC on Friday the 14th. Our next team meeting is on 2016-10-17 14:00UTC. Please attend some of all of these, because

    We are meeting at 2016-10-18 01:00 UTC to make a decision on this merge proposal!

    To that end, the below discussion points will be updated regularly, please leave comments on this post or join the conversation in #core-restapi.

    Yesterday at the dev chat the API Team proposed the Content API Endpoints for merge in WordPress 4.7. There was popular support for this feature but as @jorbin and @helen noted that the lack of dissent suggested additional review is needed, so the API Team is continuing to seek thorough review & constructive criticism of the content endpoints, including the open questions previously shared on the week 7 and week 8 API team updates.

    The merge proposal also engendered follow-up discussion in the #core-restapi channel about the benefit content endpoints bring to core, whether having such endpoints built in is quantifiably more beneficial than having them as a plugin, whether moving development from a plugin to core would slow development, and whether the endpoints as-proposed have been sufficiently reviewed for security and performance. We attempt to capture those questions & concerns (and the perspectives on them) below.


    Have the content API endpoints been thoroughly reviewed for security?

    • The REST API plugin has been on HackerOne for over a year with paid bounties for bugs
    • @barry has begun a security review


    How does the API measure up against alternatives? Are there concerns about how the API could impact the servers to which it is deployed?

    • DeliciousBrains did a performance comparison with Admin AJAX and found the REST API to have a performance improvement (These tests have not yet been independently verified)
    • @mikeschroder notes in the comments that using the REST API in place of Admin-Ajax will also bring speed benefits by permitting many previously-uncacheable requests to be cached.

    User Feedback

    Are the content endpoints sufficiently well-tested & vetted by the community?

    • @matt questions whether feedback is coming too late in development for concerns to be acted upon
      • @rmccue notes that the v2 endpoints were created based on user feedback; REST API endpoints are being deployed by plugins and running on VIP, and the content endpoints have been in wide use across a variety of sites, leading to 90+ code contributors and far more developers’ support & feedback on the endpoints
    • @rmccue has also reached out to Phil Sturgeon for feedback and will follow up

    Do Content Endpoints Benefit Core Development?

    Will having these endpoints in core improve future core development, or solve any immediate problems?

    • @bradyvercher suggested that the content API endpoints would remove the need to write a variety of one-off ajax callbacks when developing future WordPress Core AJAX functionality
    • @westonruter notes that the customizer could dynamically create settings for posts and other kinds of content without having to wire up new admin-ajax handlers

    Will Merging Negatively Impact API Development?

    Will having to work through trac instead of GitHub cause development to atrophy?

    • @jjj argues that merging will slow development, because GitHub-hosted plugins are not bound to WordPress release cycles and have less overhead for features to be developed and deployed for testing. @jjj requested a plan for how the REST API will be developed going forward after the merge of these endpoints that would account for the added friction.
    • @krogsgard countered that core increases the visibility of a project like the content endpoints
      • The number of new contributors in this Slack discussion suggests that this merge proposal is bringing in new voices; whether this supports Brian’s point or not, the team is grateful for the breadth of perspectives being shared -Ed.
    • @rachelbaker suggested that the API endpoints are sufficiently inter-dependent with core WordPress code that maintaining the plugin separately amounts to maintaining a fork, and that such separated development is untenable long-term.
    • @matt hopes that a merge of these endpoints would slow release speed, but not development speed; @rmccue feels that development speed will stay the same or increase, and that tying releases to WordPress Core increases the stability and predictability of the API endpoints.
    • The versioning of the API endpoints supports forward compatibility

    Do Content Endpoints Belong on Every WordPress Site?

    What are the pros and cons to having every WordPress site have content API endpoints?

    • @rmccue suggests the API has network effects that can only be realized with a large install base. @krogsgard draws a comparison to RSS, the widespread availability of which enables everything from podcasting from WP to the use of apps like Feedly.
    • @matt suggests that the Atom API is a better analogue than RSS, which is an independent and pre-existing standard, and that network effects could be tested through inclusion in Jetpack
    • @joostdevalk notes that many plugins, like Yoast, have data tied to existing content such as posts and pages; either they expose the content through their own endpoints, or core does. If Core exposes content types through the API then plugins may build on top of that shared foundation, not independently reinvent the wheel. “if this doesn’t end up in core, we’ll start rolling our own API for stuff. Others will too. Interoperability won’t be there, for even the most basic stuff. I think this isn’t like RSS, I think this is much more like all of us using the same table space in MySQL.”
      • @shelob9 and @masonjames agree that merging the endpoints would create a consistent and reliable open “standard” that WordPress developers can use instead of continually reinventing how to read and edit post data over HTTP.
      • In response to the question “what prevents you from building on the endpoints in their plugin form,” @joostdevalk went on to note that plugin dependencies would make that a viable option, but that burden currently lies on the user. Plugin installation is not frictionless.
    • Can these endpoints be bundled? short takeaway: no
      • Woo bundled the API infrastructure before it was merged; doing so for content endpoints would require bundling prohibitively large amounts of endpoint code.
      • @nerrad worries that if plugins bundle different versions of the endpoints plugin, then those plugins may conflict if all bundled copies are not kept in sync.
        • @nerrad clarifies in the comments below that these worries also encompass the additional risk of conflicts when plugin authors each build their own versions of these content endpoints, instead of leveraging a shared standard: if two plugins each expose their own REST collection for posts, a developer working on a site with multiple such endpoints will need to decide which to extend, and will then have their extension tied to that specific plugin rather than to a core API.
    • @schrapel and @jorbin discussed that these content endpoints make it much easier to crawl a site, which also brings some potential performance concerns: no new content is exposed, but the process of aggregating it is easier and more easily automated.
    • In the  comments below @foliovision believes that merging the endpoints will be the best way to assert the level of back-compatibility that mid-size agencies need in order to confidently utilize the endpoints.

    Please leave thoughts, questions, concerns, comments & experience in the comments below. Thank you!

    Edited 2016-10-16 to include the below comments into the body of the post

    • FolioVision 11:27 pm on October 13, 2016 Permalink | Log in to Reply

      Great discussion summary Adam. As the leader of a mid-size development agency, the sooner these endpoints are in core, the sooner we can start to use the REST API. For smaller to medium size clients, trying to play pin the tail on a donkey on a moving train (i.e. different versions of the REST API plugin, different versions of core) is simply not economically or technologically viable.

      As long as the REST API team can commit to retaining some backward compatibility if the API endpoints must change significantly in a couple of major releases, I can’t see any benefit to keeping REST API separate from core. So much great work has gone into creating the additional REST potential, it would be a shame to see it remain bottled up and a niche product only for huge agencies and hosts like VIP.wordpress.com or WordPress.com.

    • Josh Pollock 11:39 pm on October 13, 2016 Permalink | Log in to Reply

      One thing I wanted to add to this is that the REST API adds standards. I and many others have written tons of custom systems for alternative ways to read and edit post data using admin-ajax, or using custom rewrite rules.

      The constant reinventing of the wheal is counter to the spirit of open-source. By agreeing to a standard, with tons of eyes on it, we can all do better with greater efficiency and security. This after all is why we use WordPress and other open-source tools, instead of making our own CMSes.

      • masonjames 12:53 pm on October 14, 2016 Permalink | Log in to Reply

        I want to affirm this point as well. Our agency looks to WordPress (core) to provide an opinion. We value the decisions and respect them (even when we disagree).

        Web development is an incredibly competitive space with pressures in open source and otherwise. Having content end points in core ensures consistency and reliability across the WP community.

    • rag-guay 7:00 am on October 14, 2016 Permalink | Log in to Reply

      I would like to be able to edit widgets from the desktop app. So slow over the net from Thailand!

      • K.Adam White 12:58 pm on October 14, 2016 Permalink | Log in to Reply

        That’s a good point and I agree we need a solution for it. On behalf of the API Team, support for editing widgets is on the roadmap but is not part of what’s being proposed for merge this cycle. It is definitely a common request, and is one of our priorities for 4.8 as we expand the site management capabilities of the API!

        You can see some early experiments from earlier this year towards this usage here: https://github.com/WP-API/wp-api-menus-widgets-endpoints

    • Darren Ethier (nerrad) 10:46 am on October 14, 2016 Permalink | Log in to Reply

      Great summary! A lot of great back and forth in that discussion thread that isn’t always easy to capture 🙂

      Just wanted to clarify that the comments I made were not only in regards to the possibility of conflicts if plugin authors bundled the plugin version of the REST API with their own plugins, but also, with the presence of the infrastructure already in WordPress core, there is the possibility of conflicts should plugin authors roll their own different versions of the content endpoints to support what they are doing.

      Imagine plugin author A has used to api infrastructure in WP core to build custom endpoints for his plugin and his users are asking if he can add some endpoints for their posts, pages and users as well, so he goes ahead and does that. In the meantime, plugin author B has users asking her to build custom endpoints for users that support her needs as well so she adds them. Then along comes User Sally who installs and activates both plugins. She contracts mobile app developer Jimmy to build an app for her that interacts with both plugins and her website. Jimmy starts running into conflicts between what “user” endpoint to use but he manages to get it working. Then Sally tells Jimmy that she wants to distribute this app for anybody using plugin A or plugin B and Jimmy starts thinking about building a custom user endpoint in a plugin that site owners will need to install to use the app to save having to worry in the mobile app about what user endpoint to utilize.

      There are definitely different technical solutions to the above example story, but the reality is, things would be MUCH simpler for all the actors in the story above if there was an accepted standard in WordPress core for the content endpoints. It prevents a lot of problems from occurring.

    • K.Adam White 1:00 pm on October 14, 2016 Permalink | Log in to Reply

      If I may make a request of the developer community: Share this with your colleagues and friends outside of WordPress. See what they like, and what they find rough; let us know what they think! We’ve been gathering outside input on this but for more is always better.

    • Mike Schroder 6:03 pm on October 14, 2016 Permalink | Log in to Reply

      I noted this in the #core chat this week, but from my perspective at a host, we’re excited that landing the REST API will have performance benefits — in particular, because it will mean that we can cache requests that could only go through `admin-ajax` previously (and were thus forced to be dynamic).

      This will help with scaling even if it’s found that performance for the actual time in PHP/MySQL is exactly the same.

      Gradually moving those requests (whether they be core related, or added with plugins) out of `admin-ajax` will also help SysEng/Support more easily spot which requests are problematic.

      • Matt Mullenweg 1:15 am on October 18, 2016 Permalink | Log in to Reply

        It probably won’t have any real-world performance benefit — the admin-ajax benchmark was kind of flawed, and you won’t be able to do HTTP-level caching unless you also support some quite-fancy invalidation.

    • Luke Cavanagh 9:49 pm on October 14, 2016 Permalink | Log in to Reply

      I only see this as positive thing to be in WP core.

    • Brian Richards 2:21 pm on October 17, 2016 Permalink | Log in to Reply

      I’m late to the party but I want to officially register my voice in favor of merging the content endpoints into core.

      As @joostdevalk mentioned in Slack (and others have discussed elsewhere), there are a lot of opportunities to include API-based interactions within a plugin that are stifled presently because of the dependency on the REST API as a plugin. While it does seem like a small thing to inform end-users “This plugin requires the WP REST API plugin” it’s still a burden they needn’t bear. Further, by relegating the REST API to a plugin it stifles the ability for API-based interactions across many sites. For instance, a plugin that creates a widget that shows the most recent comments across a number of sites that you don’t control (e.g. getting the latest comments from a variety make/core inside a personal dashboard … and having the ability to bookmark certain comments or posts into a “read later” list for later consumption).

      As @getsource mentions above there are some fantastic wins by moving these interactions that currently depend on admin-ajax.php into standard, cacheable API calls.

      The most convincing dissenting opinion that gave me reason to pause was @JJJ‘s post that merging would hinder development. I do believe that is true. However, I also believe @rachelbaker is correct in that maintaining parity within the plugin as a long-term stand-alone is implausible. Given the choice between a REST API that can adapt and change quickly at the expense of dying slowly from a thousand cuts and a REST API that changes slowly but maintains perfect core parity I will pick the latter, every time.

      TL;DR: I really want to see the REST API land in core because I want to build some fantastic utilities (for myself and others) that can communicate with many sites without necessarily requiring administrative access (the ability to install the REST API plugin) within those sites.

    • K.Adam White 2:30 pm on October 17, 2016 Permalink | Log in to Reply

      I don’t think we’ve noted yet that the endpoints here don’t just encompass the built-in types, but also the endpoints that extend them — `WP_REST_Controller` provides a strong base for implementing new endpoints, and a custom post type with `show_in_rest => true` will automatically pick up behavior extending that class without any further action from the developer than a single line in `register_post_type`.

      Aside from the benefits of augmenting a shared resource like the posts collection @joostdevalk mentions above, having a sharable code foundation for new custom classes has the potential to reduce a lot of endpoint class duplication and fragmentation across the plugin ecosystem.

  • Ryan McCue 4:05 am on October 8, 2016 Permalink |
    Tags: , , merge-proposals,   

    REST API Merge Proposal, Part 2: Content API 

    Hi everyone, it’s your friendly REST API team here with our second merge proposal for WordPress core. (WordPress 4.4 included the REST API Infrastructure, if you’d like to check out our previous merge proposal.) Even if you’re familiar with the REST API right now, we’ve made some changes to how the project is organised, so it’s worth reading everything here.

    (If you haven’t done so already, now would be a great time to install the REST API and OAuth plugins from WordPress.org.)

    A brief history of the REST API

    The REST API was created as a proof-of-concept by Ryan McCue (hey, that’s me!) at the WordPress Contributor Summit in 2012, but the project kicked off during the 2013 Google Summer of Code. The end result was Version 1.0, which grew into a community supported initiative that saw adoption and provided for a solid learning platform. The team used Version 1 to test out the fundamental ideas behind the API, and then iterated with Version 2, which made some major breaking changes, including explicit versioning, the introduction of namespacing for forwards compatibility, and a restructure of the internals. Version 2 also led to the infrastructure of the REST API being committed to WordPress core in 4.4.

    This infrastructure is the core of the REST API, and provides the external interface to send and receive RESTful HTTP requests. Since shipping in 4.4, the infrastructure is now used by WordPress Core for oEmbed responses, and by plugins like WooCommerce and Jetpack, enabling anyone to create their own REST API endpoints.

    The team has also been hard at work on the API endpoints. This has included core changes to WordPress to support the API, including deeper changes to both settings and meta.

    Today the REST API team is proposing the inclusion of a collection of endpoints that we term the “Content API” into WordPress Core.

    Proposals for Merge

    Content Endpoints

    For WordPress 4.7 the API team proposes to merge API endpoints for WordPress content types. These endpoints provide machine-readable external access to your WordPress site with a clear, standards-driven interface, allowing new and innovative apps for interacting with your site. These endpoints support all of the following:

    • Content:
      • Posts: Read and write access to all post data, for all types of post-based data, including pages and media.
      • Comments: Read and write access to all comment data. This includes pingbacks and trackbacks.
      • Terms: Read and write access to all term data.
      • Users: Read and write access to all user data. This includes public access to some data for post authors.
      • Meta: Read and write access to metadata for posts, comments, terms, and users, on an opt-in basis from plugins.
    • Management:
      • Settings: Read and write access to settings, on an opt-in basis from plugins and core. This enables API management of key site content values that are technically stored in options, such as site title and byline.

    This merge proposal represents a complete and functional Content API, providing the necessary endpoints for mobile apps and frontends, and lays the groundwork for future releases focused on providing a Management API interface for full site administration.

    Content API endpoints support both public and authenticated access. Authenticated access allows both read and write access to anything your user has access to, including post meta and settings. Public access is available for any already-public data, such as posts, terms, and limited user data for published post authors. To avoid potential privacy issues we’ve taken pains to ensure that everything we’re exposing is already public, and the API uses WordPress’ capability system extensively to ensure that all data is properly secured.

    Just like the rest of WordPress, the Content API is fully extensible, supporting custom post meta, as well as allowing more complex data to be added via register_rest_field. The API is built around standard parts of WordPress, including the capability system and filters, so extending the API in plugins should feel as familiar to developers as extending any other part of WordPress.

    This Content API is targeted at a few primary use cases, including enhancing themes with interactivity, creating powerful plugin interfaces, building mobile and desktop applications, and providing alternative authoring experiences. We’ve been working on first-party examples of these, including a mobile app using React Native and a liveblogging web app, as well as getting feedback from others, including WIRED, the New York Times, and The Times of London. Based on experience building on the API, we’ve polished the endpoints and expanded to support settings endpoints, which are included as the first part of the Management API.


    The API Infrastructure already in WordPress core includes support for regular cookie-based authentication. This is useful for plugins and themes that want to use the API, but requires access to cookies and nonces, and is hence only useful for internal usage.

    To complement the Content Endpoints, for WordPress 4.7 the API team also proposes merging the REST API OAuth 1 server plugin into WordPress Core. This plugin provides remote authentication via the OAuth 1 protocol, allowing remote servers and applications to interact securely with the WordPress API.

    OAuth is a standardised system for delegated authorisation. With OAuth, rather than providing your password to a third-party app, you can authorise it to operate on your behalf. Apps are also required to be registered with the site beforehand, which gives site administrators control over third-party access. Access to these apps can be revoked by the user if they are no longer using the app, or by a site administrator. This also allows apps with known vulnerabilities to have compromised credentials revoked to protect users.

    We’ve chosen OAuth 1 over the newer OAuth 2 protocol because OAuth 1 includes a complex system for request signing to ensure credentials remain secure even over unsecured HTTP, while OAuth 2 requires HTTPS with a modern version of TLS. While it is strongly encouraged for sites to use HTTPS whenever possible (Let’s Encrypt makes it easier than ever to do so), WordPress itself does not require HTTPS and we do not believe WordPress should make HTTPS a requirement for using the API. The additional complexity that OAuth 1 adds can be easily supported by a library, and many such libraries already exist in most programming languages. OAuth 1 remains supported around the web, including for the Twitter API, and we also provide extensive documentation on using it.

    Authentication Beyond 4.7

    One issue with OAuth over direct username and password authentication is that it requires applications to be registered on the site. For centralized OAuth servers this wouldn’t be a problem, but the distributed nature of WordPress installations makes this tough to handle: your application must be independently registered with every WordPress site it connects to. If you’ve ever had to create a Twitter or Facebook app just to use an existing plugin on your site, you’ll know this can be a less-than-optimal experience for users.

    To solve this distribution problem, we’ve created a solution called brokered authentication. This allows a centralised server (called the “broker”) to handle app registration and to vouch for these apps to individual sites. It simplifies app registration by allowing app developers to register once for all sites, and improves security by allowing the broker to vet applications and revoke them across the entire network. The system is designed to allow multiple brokers; while the main broker is run at apps.wp-api.org, organisations can run their own broker for internal usage, and developers can run a broker locally for testing.

    While the broker system has been running live at apps.wp-api.org for months, we want to stay conservative in our approach to the API, especially where security is concerned. We are therefore proposing brokered authentication for WordPress 4.8 to ensure we have further time to continue testing and refining the broker system. In addition, this will require an installation of the broker on a centralised server to act as the canonical broker for out-of-the-box WordPress. While apps.wp-api.org is currently acting in this role, this is currently hosted by a third-party (Human Made) on behalf of the API team. For long-term usage the broker should instead be hosted on WordPress.org, alongside the existing plugin and theme repositories. This migration will take time but we remain committed to continuing to develop and support the broker.

    After Merge

    After merging the REST API, the team plans to continue developing the API as before. We expect that integrating the REST API into WordPress core will bring additional feedback, and we plan on incorporating this feedback through the rest of the 4.7 cycle.

    During the remaining parts of this release cycle and through into the 4.8 cycle, additional work will go into other parts of the API. This includes further work and refinement on the broker authentication system, including work on WordPress.org infrastructure. Additionally, we plan to continue working on the Management API endpoints, including theme and appearance endpoints to support the Customiser team. Both of these components will be maintained as separate feature projects on GitHub until they’re ready for merge into core.

    The team remains committed to supporting the API in core, and the Content API will switch from GitHub to Trac for project management and contributions. This same process occurred for the API Infrastructure in WordPress 4.4.

    Reviews and Feedback

    With this merge proposal, we’re looking for feedback and review of the project. In particular, we’re focussing on feedback on the security of the API and OAuth projects, and are also reaching out to specific people for reviews. (We take the security of the API seriously, and bug reports are welcomed on HackerOne at any time.) Design and accessibility reviews for the OAuth authorisation UI are also welcomed to ensure we maintain the high standards of WordPress core.

    Both the REST API plugin and the OAuth plugin are available on WordPress.org, and issues can be reported to the GitHub tracker for the API and the OAuth plugin respectively. We have released a final beta (Beta 15 “International Drainage Commission”) which includes the meta and settings endpoints.

    With Love from Us

    As always, this is a merge proposal, and is not final until 4.7 is released. We’re eager to hear your thoughts and feedback; the comments below are a perfect place for that, or you can pop along to one of our regular meetings. We’re also always available in the #core-restapi room on Slack.

    We’d like to thank every single one of our contributors, including 88 contributors to the main repository and 23 contributors to the OAuth repository. Particular thanks goes to my (@rmccue) wonderful co-lead Rachel Baker (@rachelbaker), our 2.0 release leads Daniel Bachhuber (@danielbachuber) and Joe Hoyle (@joehoyle), and our key contributors for the 4.7 cycle: Adam Silverstein (@adamsilverstein), Brian Krogsgard (@krogsgard), David Remer (@websupporter), Edwin Cromley (@chopinbach), and K. Adam White (@kadamwhite). Thanks also to the core committers helping us out through the 4.7 cycle, including Aaron D. Campbell (@aaroncampbell) and Aaron Jorbin (@aaronjorbin), and to the fantastic release lead, Helen Hou-Sandí (@helen).

    Thanks also to everyone who has used the REST API, and to you for reading this. We built the REST API for you, and we hope you like it.

    With love, The REST API Team

    • George Stephanis 12:17 pm on October 8, 2016 Permalink | Log in to Reply

      Regarding Authentication, as nice as OAuth 1.0a may be in some respects, I feel that we’re missing some rather obvious problems here.

      We’re expressing such concern about securing the REST API endpoints to work on HTTP — that we’re missing the fact that for sites that don’t support HTTP, normal wp-login requests or cookies could just as easily be sniffed.

      It just feels to me like we’re spending a lot of time reinforcing the back door against attackers, when the front door isn’t even locked.

      The concept of a third-party broker feels very antithetical to WordPress Core. To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.

      I’d much rather see something akin to the Application Password system we’ve devised. It has unique per-application passwords, with 142 bits of entropy, usage logging (date and ip last used), and trivial invalidation, as well as a proposed simple flow for applications to request passwords and get the generated passwords passed back.. And, as an added bonus, it works with the legacy XML-RPC API.

      Compared to that, making someone hoping to do something for API access to a single site register for a cloud broker, and then reauth with the individual site .. the UX doesn’t pass muster for me. :\

      Authentication is probably the most important key to getting the REST API correct, and it’s necessary (imho) to ship. We need to get it right.

      • marsjaninzmarsa 7:25 am on October 9, 2016 Permalink | Log in to Reply

        To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.

        Nope, you’re missing the point, third party will be pinged only on first use of new app on particular site, and next every few hours or so for invalidation (same as with checking for security updates).

      • Dion Hulse 10:40 am on October 9, 2016 Permalink | Log in to Reply

        Core. To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.

        I tend to agree here.

        I’d much rather see something akin to the Application Password system we’ve devised

        However, I feel that Application Passwords are actually a far worse solution to the problem than the various oAuth options out there, to the point that I think Application Passwords are an anti-pattern which core should never directly support. The user experience of Application Passwords are not user friendly at all, they’re a hacky solution to avoid using a proper modern application authentication mechanism.

        I could ramble for quite some time on the UX of these, but at the end of the day moving towards oAuth is going to provide a far better developer and user experience for API clients.
        Unfortunately though with all options here there’s the downside that Applications need to be registered/known/considered safe and also be able to invalidate their credentials in the event the applications key store is leaked (For example, Plugin X which relies upon a service has it’s keystore hacked, the application would have no way of informing those sites to distrust it’s previous authenticated sessions).

        In an ideal world, a central provider wouldn’t be needed, but we don’t have a decentralised platform for WordPress yet, so there’s no other mechanism for WordPresses out there to be told the sort of information they need to know.

      • Ryan McCue 8:40 pm on October 9, 2016 Permalink | Log in to Reply

        At its core, OAuth is just a standardised system for issuing app tokens. The primary things that it builds on top of this are specifically for security over HTTP, so I would be extremely reluctant to move backwards from those to a more simple token-based system.

        Regular WordPress logins are protected by two main factors: nonces and session tokens. While it is possible to sniff a raw username/password over the initial login, subsequent requests are protected, which means automated attacks are much harder. The nature of an external API means neither WP nonces nor session tokens (which are both intentionally server-only secrets) can be used to protect authentication, so we need a replacement system.

        OAuth incorporates a combination of nonce and timestamp to replace these in a similar manner, which are then combined with the secret, which we need since it’s no longer server-only. (WP nonces and session tokens have an internal secret with NONCE_SALT, the only difference is that we share them with the client for OAuth.)

        The broker system exists specifically because dynamic registration (either with OAuth or your plugin) has a number of key problems, primarily that it makes revocation useless. If the app is revoked, it can simply register again, which subverts both the site admin and W.org team if it were intentionally revoked. We looked at dynamic registration and rejected it specifically because of the issues with it.

        While the system might seem conceptually complex, it’s pretty simple to actually implement, because the broker is just regular OAuth under the hood. The entirety of the flow can be written in 200 lines of JavaScript. From the app’s perspective, it primarily Just Works, with most of the complexity hidden inside the broker implementation instead.

        The OAuth 1.0a specification is rigorously tested by security researchers and in production on huge web apps. The broker system builds on top of this, but avoids reimplementing the wheel, and instead just uses OAuth for some of the heavy lifting. Application Passwords is at its core HTTP Basic Authentication, which in its own specification 17 years ago recommended against actually using it.

        OAuth 1 isn’t perfect, but every thing in it is there for a reason. Is it perfect? No. But it provides a lot of benefit over Basic Auth for a relatively low cost.

    • Jon Brown 1:09 pm on October 8, 2016 Permalink | Log in to Reply

      Much love back at you all. This looks fabulously well thought out and complete.

    • Josh Pollock 2:42 pm on October 8, 2016 Permalink | Log in to Reply

      5 Stars!

    • fgilio 3:09 pm on October 8, 2016 Permalink | Log in to Reply

      Thanks to all of you!

    • Ahmad Awais 4:07 pm on October 8, 2016 Permalink | Log in to Reply

      I’m all in. Let’s do it this time. BTW great read Ryan.

    • Omaar Osmaan 5:55 pm on October 8, 2016 Permalink | Log in to Reply

      Thanks so much for all the hard work from the team- eager to see it get merged on core!

    • Noel Tock 7:56 pm on October 8, 2016 Permalink | Log in to Reply


    • Sergio Santos 1:45 pm on October 9, 2016 Permalink | Log in to Reply

      Thanks to all the team behind this outstanding work!

    • Matthew Eppelsheimer 9:43 pm on October 9, 2016 Permalink | Log in to Reply

      Thumbs up!

    • Weston Ruter 12:12 am on October 10, 2016 Permalink | Log in to Reply

      Additionally, we plan to continue working on the Management API endpoints, including theme and appearance endpoints to support the Customiser team. Both of these components will be maintained as separate feature projects on GitHub until they’re ready for merge into core.

      I’d like to note that customizer changesets (#30937, formerly “transactions”) allows for REST API responses to have customizations applied when the request includes a customize_changeset_uuid query param which identifies a customize_changeset post. This allows the customizer to be used with headless sites and mobile apps.

      A feature plugin needs to be started shortly that allows for these changeset posts to be CRUD’ed via the REST API as well, allowing for new customizer administrative applications to be built on top of the REST API without any need to go to customize.php.

    • Tammie Lister 8:08 pm on October 10, 2016 Permalink | Log in to Reply

      As requested in the design Slack channel, here is a design review. I took the OAuth plugin for a spin today and only focused on the design elements.

      I first of all had discoverability issues, but that was mainly due to not using this. I sort of imagine if someone is going to use this they will be doing so knowing more than I did – so that’s ok.

      The first screen is minimal but as expected when empty. It seemed to all fit the existing WP patterns. Thanks for taking the time and doing that. Should there be select all boxes though – I don’t see any actions for all.

      On the ‘add’ screen, I tried adding nothing in the fields. I was surprised when got a green message. I would expect this should be red over the success green.


      The term ‘Add Application’ but then the action button being ‘Save Consumer’, this threw me. Perhaps this is my lack of knowledge over terminology, but shouldn’t they both be the same?

      The page gets cluttered fast, I sort of want a break here visually, just a simple line would do:


      Regenerating the secret success message I felt should be by the secret. It was odd as the message appeared above my eye view. I click to regenerate lower and then this message pops up the top, feels like it should be close to add context.


      This may be a bug but when I searched for applications it tried to search users and I got the following:


    • Matt Mullenweg 8:26 pm on October 10, 2016 Permalink | Log in to Reply

      1. Given the hurdles of authentication I don’t think that bringing this into core provides benefits for WP beyond what the community gets from the plugin. I don’t believe in its current state the benefit outweighs the cost, and we should err on the side of simplicity.

      2. I am not interested in hosting the centralized brokered authentication server on WordPress.org in the 4.8 timeframe, and hesitant about the implications it has for WP more broadly. I do appreciate the thought that has been put into solving this tricky problem.

      • K.Adam White 9:39 pm on October 11, 2016 Permalink | Log in to Reply

        @matt, thanks for the comment. Can you clarify whether with (1) you mean the authentication solution, or the merge proposal for the content endpoints more broadly? There was discussion today in slack where we weren’t sure which way to interpret this point.

    • Dominik Schilling (ocean90) 10:01 pm on October 10, 2016 Permalink | Log in to Reply

      I gave the OAuth 1 plugin a try and here’s some feedback:

      • https://github.com/WP-API/OAuth1/issues/161 makes me wonder how we can integrate something with may not work on “a lot of sites”.
      • Adding Applications as a sub menu of Users doesn’t feel right to me. I just can’t imagine that 80% of our users really need this there. Twitter and Facebook have it both in the settings.
      • The UI: https://cloudup.com/c1emHXcHP4g Reusing existing elements is fine, but that looks a bit to simple and not fully developed. I’m sure that this can made better and doesn’t require a table. See Twitter/Facebook.
      • The plugin is using closures so it’s not compatible with the minimum requirements of WordPress.
      • I got a “500 Internal Server Error” error when the callback URL was invalid.
      • A few DocBlocks don’t follow the documentation standards.

      For some reasons I can’t get a successful `oauth1/access` request, I’ll try this again tomorrow…

    • Aaron D. Campbell 7:30 pm on October 11, 2016 Permalink | Log in to Reply

      The API endpoints themselves seem to be in a really good place, but I’m not sure the oAuth plugin is. Would it be reasonable to separate these into different proposals?

    • Mark Howells-Mead 2:32 pm on October 12, 2016 Permalink | Log in to Reply

      Issues aside, I’m strongly in favour of the REST API becoming a core feature as soon as it is stable.

    • Chris Smith 3:13 pm on October 12, 2016 Permalink | Log in to Reply

      +1 here as well and thanks to the team for their hard and thoughtful work.

      Based on the comments here, it does seem like it would make sense to split the proposal into the Content API and oAuth pieces for 4.7 so they can be dealt with/commented on independently as needed.

      @kadamwhite, what were the team’s thoughts on that in yesterday’s discussion?

    • Nilambar Sharma 5:32 pm on October 12, 2016 Permalink | Log in to Reply

      Really waiting for this. Lets make WordPress more awesome. It would be a great step merging new endpoints to core.

    • brad989 5:33 pm on October 12, 2016 Permalink | Log in to Reply

      Been looking forward to this for a long time. The content endpoints are an essential addition to WordPress core.

    • Chuck Reynolds 6:52 am on October 14, 2016 Permalink | Log in to Reply

      full api integration into core needs to happen eventually… API endpoints are at/near a good place. re: oath tho… meh..
      needs full support of CPT’s, which theoretically it would but… lots to test there.

    • forbze 7:16 am on October 14, 2016 Permalink | Log in to Reply

      I really want this! I’ve had to use hacky solutions in the past to repurpose content for mobile apps (I didn’t want to use web views / Mobile ui plugins).

      WordPress’s admin interface would make it really simple for me to give clients content control for their app content – rather than me having to build a custom editor UI on top of Parse / Firebase.

      I think oauth is the right solution for auth.

    • pwaring 9:23 am on October 14, 2016 Permalink | Log in to Reply

      I’m only in favour of this if the API can be disabled (ideally by default). I don’t need or want this functionality and it sounds like another remote attack vector.

      “we do not believe WordPress should make HTTPS a requirement for using the API”

      I *strongly* disagree with this. TLS uptake is increasing all the time and some browsers (e.g. Chrome) are starting to show stronger warnings for plain HTTP. Plus, if a popular application like WordPress requires HTTPS for its API, that will act as a significant nudge to hosting providers to provide HTTPS by default (a bit like moving from PHP 4 to 5).

      • Ryan McCue 9:18 pm on October 14, 2016 Permalink | Log in to Reply

        It’s super easy to disable the REST API via the `rest_enabled` filter (just return false), and there’s already a plugin for it. 🙂

        • pwaring 8:10 am on October 15, 2016 Permalink | Log in to Reply

          Whilst I’m capable of changing the code to add a filter, I don’t think that counts as ‘super easy’. It really should be a tick box somewhere in the admin settings.

          Installing a plugin to disable optional behaviour in core also seems unnecessarily complicated, plus it introduces another dependency and there’s no guarantee that the plugin author will keep it up to date.

          • Dave McHale 1:59 pm on October 18, 2016 Permalink | Log in to Reply

            I understand your concern, pwaring, but we already don’t have the ability to disable XML-RPC in core (ever since they enabled it by default in 3.5) – and since the REST API is “the same but different” I believe that’s why the new feature is following the same model. “Decisions, not options” and all that 🙂

            It’s also why I’m the author of the plugin Ryan linked to above. I think the REST API is great, and can’t wait to start using it myself *and* also see what other people build with it. But it’s not going to be for everyone, and I thought that people may want the easy ability to turn it off if they had a reason to.

            Since the plugin uses the root-level filters provided by the REST API there should very, VERY little need for actual plugin updates moving forward into the future (though I do keep an eye on the project, in case an update is needed). The only time I’ve needed to make a real functional change was when the filters themselves changed from version 1.x to 2.x of the API, before it was even merged into core. New features like the content endpoints won’t change the use of the plugin, because the REST API is still entirely disabled if you’re using the filters.

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