WordPress.org

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

    Administration

    • 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

    Comments

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

    Customize

    • 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

    Feeds

    General

    Help/About

    Media

    • 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

    Misc

    • 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

    Plugins

    REST API

    • 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

    Role/Capability

    • 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

    Taxonomy

    • 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

    Themes

    • 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

    TinyMCE

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

    Users

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

     
  • Jeffrey Paul 4:00 am on October 20, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: October 19 (4.7 week 9) 

    This post summarizes the dev chat meeting from October 19th (agenda, Slack archive).

    Reminders

    Dev Notes / Field Guides

    • In general, if you worked on something that needs to be called out for testing or building upon, there should be a post about it.  These are all tagged as `dev-notes` on the Make/Core site.  The target is everything written before beta 2 so we can get a field guide summarizing them and an email sent to all plugin developers while we are still in beta. In general all active components should have at least one post about what has changed.

    Final Merge Decisions

    • Twenty Seventeen (@davidakennedy)
      • Merge Proposal & Trac ticket
      • 59 contributors. Merging later today.
      • There are 34 issues left, some of which will be moved to Trac. There are 0 pull requests left.
      • A code review was performed by @aaroncampbell, and he didn’t find anything that should hold up merge.
      • Theme does not depend on any core features being merged before/at the same time, but will greatly benefit from any completed.
      • Video headers (#38172) needs consensus on the best approach and testing of functional patches
      • Merge proposal accepted. 🎉
    • REST API: Content API (@kadamwhite)
      • Merge ProposalSuccess metrics
      • 99 contributors. 25 merged PRs in the past 3 days. 27 issues left in the current milestone and a few stray PRs, which will be closed out shortly or moved to Trac.
      • Monday meeting in #core resulting in conditional merge approval
      • Conditions:
        • 1) 4.7: Press This / Quick Draft Core feature (#38343 and #38342)
        • 2) 4.7: Object / non-single level meta. @joehoyle, @jnylen and others have been working on this, tracking via GitHub.
        • 3) 4.7: Define success metrics (see link above)
        • 4) 4.7: Continuing to ensure the API forward compatibility (EVERYONE should be building things with it).
        • 5) 4.7: Review .com API settings discrepancies, determine how to resolve or where to document. @joehoyle, @jnylen and others have been working on this; Progress/documentation.
      • WP-API is code-frozen at this time; open enhancements will be ported over by @rachelbaker as appropriate.
      • Merge proposal accepted (“Let’s do it.”). 🎉

    Components and Other Enhancements

    • i18n (@swissspidy)
      • Nothing newsworthy from the i18n side which isn’t already on Make/Core.
    • Make it easier to visualize where to put your content in a given theme (aka “dummy content”)
      • If there are people out there interested in content writing and stuff like customizer integration, hit up @helen.
    • Media (@mikeschroder, @joemcgill)
      • We’re working on trying to get #31050 (Better PDF Upload Management) into shape for commit this week. Still some issues to iron out, but it’s getting close.
      • I want to call out that we’ve removed the automatic fallbacks for generating `alt` attributes from images with consultation from the a11y team to improve the user experience for screen readers. See: #34635 for details.
      • We have a few other things we’re looking at this week, but if there is anything pressing that needs eyes specifically from someone on the Media team, please reach out in #core-media.
    • Customize (@westonruter, @celloexpressions)
      • Remaining three major 4.7 feature projects merged in the last 24 hours.
      • #27403 and #38164 are our larger remaining tickets needing attention currently, with #29158 and #22058 pending final patches for review and discussion.
    • Editor (@azaozz, @iseulde)
      • TinyMCE: allow pasting in image captions (#36211) needs some more testing
        • Add an image in the editor, add a caption, then try pasting different things copied from another web page in it. This makes some assumptions of what the user expects, and what should happen, i.e. when pasting an image into a caption it should remove the image but let the text in, or keep all that is pasted but move it under the caption?
     
  • Jeffrey Paul 3:59 am on October 20, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: October 12 (4.7 week 8) 

    This post summarizes the dev chat meeting from October 12th (agenda, Slack archive).

    Reminders

    Feature Proposals for 4.7

    • REST API: Content API (@kadamwhite)
      • REST API Team Update
      • Content API endpoints have been stable for some time and now have the missing functionality established at the start of this development cycle
      • We pitched merging in the OAuth 1 server alongside those content endpoints, to simplify the process of authenticating from remote applications
      • The auth method in core right now is cookie/nonce-based, so it’s available to any code running within the same domain as the main WordPress install and leverages the existing login cookie
      • plugins and themes that utilize JS to enhance the editing experience within their admin UI have full read/write access, restricted to the capabilities of the authenticated user
      • External applications, e.g. a mobile app, desktop app or external server, would have read-only access
      • readers, aggregators, etc are possible without authentication, and more complex read-write apps can be written by installing one of the available authentication plugins, of which OAuth is but one
      • Reference for options and when/how to use
      • 90 contributors for the rest-api plugin
      • automated test coverage currently at 90.44%
      • 37 more open tickets
      • weekly meeting on Monday at 1400UTC in #core-restapi
    • Discovering and installing themes in the customizer (@celloexpressions)
      • Related Make/Design and Make/Flow posts, but best to post all feedback to the Make/Core feature proposal
      • Working through the accessibility feedback, but it’s a bit unclear what’s specific to this feature versus the customizer in general, and which issues are also present in the admin theme installer
      • Haven’t heard anything from polyglots, security (unlikely to have any issues), or docs
      • There is one known i18n concern where we’ll need a compromise until we have JS i18n in core
      • @celloexpressions to do a final iteration to pick up any remaining feedback on Thursday, then pass to @westonruter for the code review process
    • Custom CSS with live previews (@celloexpressions)
      • seems to have decent support as a feature, with the biggest question in the comments being how to store and output the CSS
      • CSS is output from the db via a style tag, use of `style` tag is key for targeting for `postMessage` live preview
      • Post-based storage allows for revisions built in (ensuring that there are hooks for a plugin that wants to write a file would alleviate many concerns)
      • CSS is theme-specific in the proposal for this, with a post object for each theme that has CSS
      • Scheduling a meeting to go through these concerns and make a decision, coordination to occur in #core-customize
    • Customize Changesets (née Transactions) (@westonruter)
      • Technical Post (audience is developers who have extended the customizer significantly, as there may be impacts to any heavy customizer integrations since changesets touches some very low-level stuff in the customizer)
      • Users will be able to bookmark a customizer session since the changeset UUID will be part of the URL
      • Theme switches will no longer result in changes being lost (no more AYS dialog)
      • a few other open questions and issues that have been noted

    Components

     
  • Helen Hou-Sandi 7:40 pm on October 19, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for October 19 (4.7 week 9) 

    This is the agenda for the weekly dev meeting on October 19, 2016 at 20:00 UTC:

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

     
  • Helen Hou-Sandi 8:01 pm on October 12, 2016 Permalink |
    Tags: , ,   

    Dev Chat Agenda for October 12 (4.7 week 8) 

    This is the agenda for the weekly dev meeting on October 12, 2016 at 20:00 UTC:

    If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

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

    Authentication

    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

      :+1:

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

      https://cldup.com/JMW8wRzxx4.png

      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:

      https://cldup.com/3BZcACH2u9.png

      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.

      https://cldup.com/BF3C3iuVeF.png

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

      https://cldup.com/UjY8mgctGd.gif

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

  • Jeffrey Paul 6:06 pm on October 7, 2016 Permalink |
    Tags: , ,   

    Dev Chat Summary: October 5 (4.7 week 7) 

    This post summarizes the dev chat meeting from October 5th (agenda, Slack archive).

    Reminders

    Components & Features

    • Non-4.7 Feature Proposal: Notifications API (@johnbillion)
      • Discussion on this in #feature-notifications, but no meeting scheduled
    • Non-4.7 Feature Proposal: Status API for taxonomy terms (@boonebgorges)
    • Customize (@westonruter, @celloexpressions)
      • Feature proposal for 4.7: Discovering and installing themes in the customizer (@celloexpressions)
        • Deadline for feedback and review from various teams is Wednesday, October 12th
        • Need review/audit from Flow (and mobile), Docs, Security, Polyglots/i18n, Design/UX, Accessibility, and when those are done a Code Review (@westonruter)
        • Would like user testing & testing of the patch itself
        • Please provide feedback as a comment on the Feature Proposal Post, User Testing Post, or via Trac
        • The plan is to begin final code review/commit next Wednesday, October 12th, so feedback needs to be received by then
      • Merge proposal for Customize Changesets (fka Transactions) – Trac & Github
        • Needs developer attention, specifically on expected/best behavior on maintaining changesets across multiple theme previewing/testing. Details to be included in a Make/Core post by @westonruter with discussion continuing in #core-customize
      • Otherwise we’re working toward finalizing patches for all of our other projects and will publish a feature proposal for custom CSS in the next week. All 4.7 customize non-bugs have an owner assigned to work toward commit or punt to a future release.
    • Twenty Seventeen (@davidakennedy, @melchoyce)
      • Highlight: start testing the theme, we need help on the features from a development perspective, plan is theme merging into core by October 19th with enhancements needing to complete by October 26th
      • Latest theme update
      • Latest features update
      • Theme recap: This week the initial design implementation was merged into the master branch on GitHub. The rest of the theme is moving along nicely, and the initial design implementation should make it easier to test the theme’s features. Please start testing, and creating issues! The next step is to get a public demo up to help with that. Best way to test is to get it via GitHub ( if using wp-cli, wp theme install <github-url> --activate).
      • Features recap: For the multi-panel feature, at the weekly meeting, the feature was reduced in scope to focus only on the front page of sites, only include content from pages and be implemented in the Customizer. @karmatosed has some mocks posted (including live preview). For the video headers feature, it still needs to be focused with a reasonable MVP defined. Although, some recent feedback on the ticket is helping there.
      • Twenty Seventeen needs you. Home pages should be fun to create and a heck of alot easier. Headers can be even more captivating. If you’re interested in working on either of these projects, please let @davidakennedy know.
    • REST API (@krogsgard, @kadamwhite)
      • Settings (PR against the main plugin repo) and Meta (PR here against the meta repo) are still open for review from the team; we’ll be formally posting updates on Make/Core outlining the new functionality as these land
      • Need a lot of eyes on Authentication, released v2 beta 14 last weekend and intend to release a beta 15 with the merge-candidate functionality. Plan to propose that OAuth1 be included in the merge.
      • Testing and review is top priority right now. Docs for folks getting up and running with the API will be getting a strong push post-Proposal.
      • Next meeting: Thursday at 2pm UTC
    • Media (@mikeschroder, @joemcgill)
      • Latest update
      • Media search doesn’t include file name (#22744): Just committed a fix for a bug that was trampling existing JOINs. Please test, especially if you’re doing any custom filtering to media queries that might be impacted.
      • Starting work on potential feature plugin to introduce additional UX improvements to the media library. Likely future release material, but expect to fix some bugs and lay groundwork during this release. Development will happen in GitHub. Plan to make a feature project proposal after we’ve had some initial conversations about UI/UX direction.
      • After some conversation with @sheri, may still try to land a core media widget (#32417). Most of the work here has already been done, but need to make some decisions. We’ll plan to talk about this during our meeting on Friday at 5pm UTC in #core-images.
    • i18n (@swissspidy)
      • User Admin Language (#29783) landed this week. It allows each user to set their language (locale) and the admin will be translated accordingly for them. A dev note has yet to be written.
      • Focusing on making use of that feature by sending emails in the respective user’s locale. See #26511 if anyone wants to help with a new patch.
      • Introduce some JavaScript i18n functions (#20491): progress currently happens outside of core. There’s a proof of concept for extracting strings from JavaScript files as well as a PR on the GlotPress repository to add JSON export functionality.
    • Editor (@azaozz, @iseulde)
      • We’ll work on a better experiences for when nonces expire; posted an idea dump in #core-editor, thoughts on any points are very welcome.
      • Bug scrub Thursday at 4pm UTC in #core-editor.
      • In order to move ahead with several UI proposals/tickets we will need to get more usage data.
      • Planning to update TinyMCE next week, even if no new version by then.
     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar