Dev Chat Summary: March 1st (4.7.3 week 5)

This post summarizes the dev chat meeting from March 1st (agendaSlack archive).

4.7.3 Schedule

  • Reminder of plan to release 4.7.3 as bugfix and maintenance release on Monday March 6, 2017
  • RC is available so please test

Community Summit

  • Working to review submissions on Planning for Community Summit 2017 post on Make/Core as well as submissions to the Make/Summit team via the Community Summit 2017: Sign-up Request post
  • Between now and Friday, March 5th the Core team needs to come up with:
    • 1) a list of topics for the summit
    • 2) A list of representatives to attend the Community Summit
    • 3) One or two contributors who are willing to help with the organization of the event
  • “participating” generally means being physically present for the discussions in Paris, France days prior to WCEU this summer for the Community Summit
  • Each topic facilitator will do both a pre-summit and post-summit Make/Core post. @jbpaul17 to confirm timelines with @_dorsvenabili to help prep those facilitators for those post timings.
  • Javascript in core [will submit to CS]
    • “what we hope and imagine for the future with the REST API, and how we hope to get there… what we have in core now and how we can improve it and how we can attract more JavaScript first developers to build on WordPress and especially contribute to core… How the REST API relates to wp-admin.” Submitted by @adamsilverstein to attend and volunteer to help in whatever role is most helpful.
    • “REST API admin usage: Where we can start moving things to using the API (and maybe even get a couple of them done at the summit)” Related submission from @chriscct7, recommended to include @rmccue
    • @kadamwhite: A heavy dependency on “the future of JS in core” and that discussion should originate from the broader WP community, not be mandated by the REST API group
  • Technology version support policies [will submit to CS]
    • @jorbin: (versions of PHP, MySQL, Browsers, Screen Readers, other AT, etc.) Let’s come up with some concrete plans for when we intend to deprecate things and how we want to handle it. People Who would be good to have in this discussion: @dd32 (to help with stats) @pento (to help with messaging) @afercia and @rianrietveld ( to help formulate AT support policies if they don’t exist already), @westonruter ( as maintainer of the largest JS component) @azaozz ( as maintainer of tinyMCE component) @matveb ( as dev lead of new editor)
    • @getsource, @boonebgorges, and @matt as additional reps for this topic
  • Improved management of contributors with time to spare [will submit to CS]
    • @johnbillion: This topic is particularly focused on pre-existing contributors who are paid to contribute to WordPress (eg. those whose time is sponsored by their employers), but also pre-existing contributors who aren’t sponsored but who do want to contribute a significant and/or consistent amount of time, and also potential contributors in a similar position.
      As a project, we need to manage these people’s time much better. These people need to be project managed in one way or another to avoid repeats of situations we’ve had in the past where a contributor is literally being paid to fix things in WordPress and the project is failing to enable them to do so effectively, or even at all. I’d (@johnbillion) like to attend the summit, and I’d be happy to jointly lead this discussion with someone who has good project management experience and some ideas about how WordPress might be able to better manage contributors, but at the same time do it in such a way that retains the fun and interesting aspects of contributing without turning it into something that too closely resembles “work”. [Side note from John: Worth noting that this doesn’t only apply to core, but it’s a good place to start.]
    • @helen did a survey of time availability a while ago, sent list to John to use for this topic
    • @aaroncampbell, @getsource, @jorbin, @boonebgorges, and @logankipp as additional reps for this topic
  • On-boarding experience for new contributors [will submit to CS]
    • @joemcgill: Lots of people who want to get involved have no idea where to focus their efforts.
    • @kadamwhite: Speaking for myself this is hugely related to the future of JS in core and the REST API, since those pieces really need the energy new contribs would bring
    • @getsource: I am willing to participate or lead, although I don’t know what leading it means besides guiding conversation at this point. @aaroncampbell also willing to lead.
    • @peterwilsoncc, @flixos90, @logankipp, @jorbin, @johnbillion, and @stevenkword as additional reps for this topic
  • Communicating changes to WordPress Core [will NOT submit to CS]
    • @jorbin: For the past few years, core has produced a field guide and worked with the meta and plugins team to email plugin others about changes to core. Each release though triggers a number of people who don’t know about changes until after the release. Challenge: How can we help ensure changes that aren’t worthy of user marketing promotion are known by a far greater percentage of WordPress developers?
      Might also impact or benefit from input from +make.wordpress.org/plugins +make.wordpress.org/themes +make.wordpress.org/marketing +make.wordpress.org/meta.
      Even when we get the field guide out on time, issues come up post release.
      two ideas:
      1) Translating the field guide (is this reasonable if the posts that it links to aren’t translated?) Also means polyglots should be in the discussion
      2) Using the new release email mailing list to announce RC
    • @helen: I think it’s worth at least starting the conversation earlier, even if it ends up still being valuable to continue something in person.
    • @desrosj: There may also be some great ideas from people who cannot attend in person. It would be a great opportunity for them to have their ideas heard and contribute, even if they are not able to follow through with the discussion in person at the summit.
    • @jorbinI’m going to withdraw the communication topic as my proposal for the summit with the note that I might want to resubmit it depending on how the virtual discussion goes
    • @azaozz and @sergey as additional reps for this topic
  • Security [will submit to CS]
    • @chriscct7: The process of a security ticket from report through triage through disclosure. Aaron Campbell (security czar) has made it clear this needs to be discussed at some point and I feel like the community summit would provide a good venue as many of those on the team will be there in person and we can mirror the conversation easily for those who are not. Recommend including @aaroncampbell
    • @aaroncampbell: This is actually a good idea, although I don’t think it’s because “those on the team will be there” but rather because I’d love to get input from some other people too, and security is generally sensitive enough that a place like the summit seems useful
    • @rmccue, @kadamwhite, @matveb, @joen, @westonruter, @melchoyce as additional reps for this topic
  • Collection of Anonymous data [will NOT submit to CS]
    • @chriscct7: If core is interested in doing it, I think my experience with doing it for a trac ticket (settings reduction) might prove to be useful to add to the discussion. Recommend including @drewapicture
    • General agreement to NOT include this topic since this is currently opt-in and the issue is finding an owner of this topic
  • Bootstrap/Load [will NOT submit to CS]
    • @schlessera: Opening up the WordPress Core Architecture to make it flexible enough as a platform so that it can:  * serve both novice end-users as well as large-scale enterprise installations in an optimized way;  * quickly adapt to changing external requirements, to keep up with the accelerating pace of the web. Recommend including @rmccue
    • General agreement to NOT include this topic since it does not need to happen in-person, already has discussions underway, and should be scheduled in next couple of weeks
  • Code editor [will NOT submit to CS]
    • @georgestephanis: Code Syntax Highlighting implementation and accessibility concerns — how we can get CodeMirror or whatever better library there is implemented and rolled out for both Customizer Custom CSS, Theme/Plugin Editor, and Content Blocks. Recommend including @afercia @westonruter
    • General agreement to NOT include this topic since it does not need to happen in-person and should happen sooner than the CS.
  • REST API authentication [will NOT submit to CS]
    • @georgestephanis: Third-party authentication with the REST API.    Between OAuth 1.0a, OAuth2, central application brokers, Application Passwords, or some other system — there’s a lot of possibilities here, and it’d be really nice if Core could pick something and move forward with it before folks start spoofing cookie authentication in applications to integrate with core.
    • Relevant chat summary from the last time we had one
    • This really needs an owner, otherwise it’ll continue to be punted. There’s fundamental differences on what the direction should be.
    • @samuelsidler: I don’t think core can decide until someone has documented the possible options, along with their strengths and weaknesses, then had some discussions on what would be best for core and why.
    • @georgestephanis, @rmccue, @logankipp volunteered post on Make/Core to move this topic along
    • We will table this idea and maybe propose it for the summit based upon how the near term discussions go
  • Front-end Editing [will NOT submit to CS]
    • @westonruter: Frontend editing powered by bootstrapping the customizer onto the frontend, with inline direct manipulation of elements on the page and the controls sidebar being lazy loaded to slide in from the left as needed. Editable elements include post content and site configuration (sidebars, menus, options, etc). Recommend including @celloexpressions
    • General agreement to NOT include this topic since it depends on too many other things we won’t know by then, so we will pass on that topic (at least for now).
  • Nextgen Widgets [will NOT submit to CS]
    • @westonruter: Next generation of widgets which harmonize with content blocks in the editor.
    • General agreement to NOT include this topic for the CS, but good conversation for the contributor day.
  • Feedback on Core focuses [will NOT submit to CS]
    • @georgestephanis: Six months in, how are we feeling about shifting away to a more top-directed set of focuses for the year?
    • General agreement to NOT include this topic as it’ll be hard to say until/unless we’ve shipped a core release by then (we likely won’t) and is a conversation that should happen in public.
  • Complete list of representatives nominated to attend the Community Summit: @matt, @nacin, @adamsilverstein@rmccue@kadamwhite@chriscct7, @dd32@pento@afercia@rianrietveld@westonruter@azaozz@matveb, @getsource, @boonebgorges@aaroncampbell, @jorbin, @logankipp, @peterwilsoncc, @flixos90, @johnbillion, @stevenkword, @azaozz, @sergey, @karmatosed, @joen, @westonruter, @melchoyce, @jnylen0, @ipstenu, @joemcgill, @joehoyle, @rachelbaker, @michael-arestad, @petya, @danielbachhuber, @ocean90, @samuelsidler, @afercia@desrosj, @iseulde, @jjj@celloexpressions
  • We’re still searching for 1-2 contributors who are willing to help with event organization, so please comment here or reach out to @jbpaul17 if you’re interested
  • @jbpaul17 will send the Core team responses to the Community Summit team by Friday, March 3rd.

Browser support

  • Please take a look at @desrosj’s post: The New Editor and Browser Support
  • This will be a topic of discussion at next week’s devchat.
  • Please leave your thoughts there as comments, and bring them along next week as well.

#4-7, #4-7-3, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Nextgen Bootstrap/Load Feature Project

The bootstrapping process of WordPress Core (affectionately called the “Bootstrap/Load” component around here) is a critical piece of the system, and everything else depends on it being reliable and performant. However, developers and system administrators also need it to be flexible enough to adapt to the requirements of their differing projects or environments. Large-scale WordPress installations often require substantial customizations to adjust for scalability and redundancy.

Considering the importance of this component, the documentation is not adequate, and very few people actually know what the exact flow is. More importantly, there isn’t a wide understanding of why specific decisions had been taken, and how later code depends on the bootstrap process.

This proposal aims to launch a feature project to work on the next iteration of the bootstrap component with a set of specific goals in mind.

Goals

To be able to guide the design process and have measurable success metrics, clear goals need to be defined.

Here’s an overview of what specific goals the project should aim for:

  1. The component has proper documentation for every step of the process.
    Documentation will include both clear comments in the source as well as an external documentation space that includes reference material, execution flow diagrams, best practices and examples of usage.
  2. The component models a modernized flow which still provides same sane defaults, but enables advanced use cases in a supported way.
    Customizing high-volume sites or specialized applications should be less “hacky”, and all of the major subsystems should provide reliable means of configuration/extension.
  3. The component adapts to differing contexts to optimize both performance and memory consumption where possible.
    The system should be able to intelligently load only the parts of the code that are strictly necessary for the current requests, through means of conditional execution flows, smart routing, proxy objects and autoloading. Special consideration should be given to the WP REST API endpoints to make them as fast and efficient as possible.
  4. The component offers a coherent way of supporting all versions of multisite (networks), reducing some of the idiosyncrasies that currently exist.
    The difference between single sites, networks of sites and networks of networks should be kept as small as possible so that less care needs to be taken to have the code work reliably with all of them.
  5. The component considers both backward compatibility as well as forward compatibility.
    It is of paramount importance that existing sites do not break due to the changes that will be proposed with this project. However, forward compatibility needs to be taken into account just as well, to create a next version of the bootstrap component that can easily grow with future requirements in a controlled way.

Project Phases

The project will have four different phases: Discovery, Design, Execution and Merge Proposal.

1. Discovery

The Discovery Phase aims to properly research and document the status quo. It will be a thorough analysis of source code, trac tickets and contributor discussions to decipher the reasoning behind the current implementation and what the requirements, strengths and weaknesses are. Documentation will be written in parallel, logging all findings and producing a better onboarding process for this component. Characterization tests will be written to be able to detect regressions when making changes in phase 3 later on.

2. Design

The Design phase will examine all the findings from phase one to design a new version of the bootstrap component that meets all the requirements and strengths while reducing some or all of the weaknesses and improving reliability, flexibility and performance.

We want to avoid having yet another component update that just grows organically. There should be strong principles in place that make sure that the new version is not only backward compatible but also forward compatible.

3. Execution

The Execution phase will create a modified fork/branch of WordPress Core, to allow for collaborative work on this new iteration of the bootstrap component.

Through automated tests, refactoring will be guided to implement the design from phase 2. The characterization tests from phase 1 will make sure that compatibility remains a given, even for “compatibility-enforced bugs”. Optional mechanisms to get saner results in such cases will be discussed on a case-by-case basis.

4. Merge Proposal

The Merge Proposal phase will be the final phase of the project, identifying a clean merge process and a proper migration path to merge the new version of the component into Core.

Metrics will need to be defined to have measurable and achievable goals that can objectively tell whether the Component is ready to be merged.

Contributions

During the initial Discovery Phase, contributions in the following areas will prove to be useful:

Advanced Use Cases

We need lots of data about the types of customizations that people use for their projects: bootstrap modifications (WP-CLI), complex network hierarchies, folder rearrangements, specialized caches, etc.

Problems With Current Code

We need to know about all and any challenges and limitations that you have been experiencing with the current bootstrapping flow: setups that were difficult or impossible to achieve, settings that didn’t yield the expected results, etc.

Documentation

Documentation will not only need to be written for the way the current code works, but also for all deprecated functionality, buggy behavior and unexpected side-effects. We are going for completeness, not ease-of-use here. Documentation should also cover best practices for modifying the bootstrap process.

Join us in #core-bootstrap to start contributing!

Thanks to Helen Hou-Sandì (@helen), Jeremy Felt (@jeremyfelt) and Aaron Jorbin (@jorbin) for their help in shaping this proposal.

#bootstrap-load, #core

Dev Chat Summary: February 8th (4.7.3 week 2)

This post summarizes the dev chat meeting from February 8th (agendaSlack archive).

4.7.3 Schedule

  • Still no release date scheduled for 4.7.3, but we began to assess tickets this week and will continue next week
  • Goal is to finish scrubbing tickets in the milestone and plan for release timing
  • 4.7.3 milestone Bug Scrub planned for February 13, 2017 at 10:00 CST in #core
    • Focus on tickets with no owner set to see if any can be picked up and worked towards a commit this month
    • Please attend the scrub if you have tickets you’d like to discuss

Customizer team update

  • Customizer team appreciates any help by looking at tickets and pitching in where you can
  • Going through the customize component ticket backlog, identifying quick wins to add to the next release and then larger issues to tackle for the next major
  • #21666 (Customizer reset/undo/revert) and #38707 (Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out) have initial designs and could use prototype and/or development help

Editor team update

  • The Editor team will post a Make/Design update soon that features a couple of mockups showing block level and inline level controls as well as showing off one or more prototypes in various states of functionality.
  • They’re working to get mockups and prototypes in a place where people can contribute to them, so keep an eye out for their post and please consider contributing and/or giving feedback.

REST API team update

  • @rmccue is working on using the API to improve the editing experience relating to bulk actions in list views
  • With limited team bandwidth, we’re evaluating existing usages of admin-ajax to prioritize places where the API can be implemented to reduce inconsistency
  • During 4.7 Quick Draft stalled out due to questions about content filtering that are happening on the admin-ajax path, and has resurfaced #21170 (JavaScript actions and filters) and #20491 (Introduce some JavaScript i18n functions)
  • @kadamwhite is triaging open API bugs weekly, with a focus on normalizing inconsistencies
  • #38323 (Reconsider $object_subtype handling in register_meta()) is priority from an API design standpoint, because the current behavior completely precludes using register_meta to model your data
  • @jnylen0 has been tracking the multi-site API discussions, and there’s a post from that group up on the make/core blog
  • Our biggest barrier is bandwidth; @rmccue & @kadamwhite are working on 1-2 priorities in their respective areas, but there’s a lot of docs and testing work, as well as POC for future endpoint types (like @westonruter is doing w/ Widgets) that could happen in parallel if there are interested parties
  • Widgets (and therefore Sidebars, later) endpoints are priorities for @westonruter given the Customizer focus
  • Menus endpoints are the other that comes up in conversation the most
  • Once we have the first WP-Admin usage in place, we’ll be looking for more contributors to help spearhead more admin-ajax replacement; that’s higher-priority than new endpoints from a core standpoint, in our opinion
  • The REST API group meets on Mondays at 21:00 UTC in #core-restapi, we hope to see you there!

Trac Ticket(s)

  • @pressupinc advocating for a fix for #34225 (Display correct dimensions for image sizes in media modal)
    • Seems to be caused by #35390 (image_constrain_size_for_editor() should not affect images generated on the front end when `large` size is used)
    • General issue is image sizes not displaying as they should in the Media modal
    • Reported #38906 (wp_get_attachment_image_src() sometimes gives incorrect width and height values)
    • Will check with Media team in #core-media

#4-7, #4-7-3, #dev-chat, #summary

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

#4-7, #4-7-2, #dev-chat, #summary

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

Administration

  • 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

  • Add assertNotFalse() method to WP_UnitTestCase and use it where appropriate. [39919] #39219
  • Correctly reference function names in @covers entries. [39918] #39235
  • After [29858], update .jsintrc to use spaces, not tabs. [39898] #39359

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

Database

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

Editor

External Libraries

Formatting

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

I18N

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

Media

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

Misc

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

Plugins

  • 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

REST API

Taxonomy

  • 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

Themes

  • 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

TinyMCE

  • 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

Upload

Users

  • 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

Widgets

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

#4-8, #week-in-core

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

Administration

  • 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

Comments

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

Customize

  • 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

Database

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

Editor

  • 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

Feeds

General

  • 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

I18N

  • 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

Mail

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

Media

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

Menus

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

Misc

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

Query

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

REST API

Security

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

Taxonomy

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

Themes

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

Upgrade/Install

  • 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

Users

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

#4-8, #week-in-core

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

 

 

#multisite, #networks-sites, #rest-api, #users

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

#multisite, #networks-sites, #rest-api, #users

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

Administration

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

  • 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

Comments

Customize

  • 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

General

  • 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

Media

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

Misc

  • 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

Query

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

REST API

  • 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

Role/Capability

  • 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

Taxonomy

  • 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

Themes

Toolbar

Users

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

#4-7-1, #week-in-core

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!

#4-7, #week-in-core