Dev Chat Summary: January 11th (4.7.1 week 5)

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

4.7.1 Update

2017 Release Schedule

  • 4.7.1 will NOT be last in the 4.7 branch, so it’s best to start on anything that needs to go in 4.7.2 immediately
  • Proposal from @samuelsidler:
    • Since we don’t have a set release date for WordPress 4.8, I’d like to propose we look at applicable 4.7.x issues about once a month, and decide if we should ship a release.
    • For 4.7.2, I think we should take a look at issues at the beginning of February, during devchat, and decide if the issues warrant a release, then ship about a week later.
    • That would mean we’d be looking at a release around February 14, but we’d update the schedule after looking at the specific issues.
    • We’d want to evaluate issues the week of February 6 and make a call.
    • I think we said regressions and minor bug fixes are okay in 4.7 at the moment, but we can evaluate other fixes on a case-by-case basis.
  • General agreement on approach, though date for 4.7.2 to be confirmed in February
  • Plan to choose someone soon to lead 4.7.2, maybe at or before next week’s devchat, to keep things moving along. @jnylen0 @aaroncampbell @voldemortensen @swissspidy interest in leading that or future releases. If you have interest, ping @samuelsidler as he’s compiling a list of those interested.
  • @davidakennedy: I’d imagine we’ll package up default theme updates more in minor release. Though, we can also release those whenever to .org. I’d like to think through a schedule for that. Maybe looking at things monthly, and making a decision.

Trac Tickets

  • #39309: Secure WordPress Against Infrastructure Attacks
    • @paragoninitiativeenterprises: propose making it a point of focus for 4.8
    • @aaroncampbell: may not fit as a focus for 4.8, since those should be in the editor, customizer, and API areas. But good to talk about and try to figure out steps forward.
    • @paragoninitiativeenterprises: recommend against punting too far into the future
    • @samuelsidler: let’s think through how to implement it and work on patches for that, then decide which release to put it in
    • @westonruter: Security and performance hardening are ongoing and not limited to focuses
    • @paragoninitiativeenterprises: would like to see this land ASAP, will work on a patch with necessary tests and any necessary back-compat and post to the ticket
  • #38418: Add telemetry (aka usage data collection) as opt-in feature in core)
    • @lukecavanagh: thoughts from the group?
    • @brechtryckaert: personally in favor of usage data collection, but we’ll need to be very upfront about it upon release to avoid criticism; also worried what the impact would be on loading times/slowdown due to communication with the servers that store the data, would all depend on the way it’s implemented.
  • #39157: Feed returns 404 when there are no posts
    • @stevenkword: looking for feedback on approach on adding new conditionals and what to do now. Issue was addressed in 4.7 but caused a regression and code was reverted for 4.7.1.  After 4.7.0 landed, before the reversion, an updated patch was committed that resolved the regression, but it introduced new getters to WP_Query.
    • @stevenkword: would like to find a resolution for this for 4.7.2, but need some opinions how to solve it.
    • Will ping @peterwilsoncc and @dd32 to look at it

#4-7-1, #core, #dev-chat, #summary

Dev Chat Agenda for January 11 (4.7.1 week 5)

This is the agenda for the weekly dev meeting on January 11, 2017 at 15:00 CST:

  • Schedule reminder: 4.7.1 scheduled to launch at January 11, 2017 at 15:00 UTC
  • 2017 releases: 4.7.1 will NOT be last in the 4.7 branch, so it’s best to start on anything that needs to go in 4.7.2 immediately
  • General announcements: bring your bullhorn, step up on the soapbox, and shout for all to hear

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!

#4-7-1, #agenda, #core, #dev-chat

Dev Chat Summary: January 4th (4.7.1 week 4)

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


2017 Release Schedule

  • no update on the “new release schedule”, so for now it will be process as usual

#4-7-1, #core, #dev-chat, #summary

4.7.1 Release Candidate

A Release Candidate for WordPress 4.7.1 is now available. This security and maintenance release fixes 62 issues reported against 4.7 and is scheduled for final release on Wednesday, January 11, 2017. Note this does not address a number of other issues, which are slated for a 4.7.2 release.

Thus far WordPress 4.7 has been downloaded over 9 million times since its release on December 6, 2016. Please help us by testing this release candidate to ensure 4.7.1 fixes the reported issues and doesn’t introduce any new ones. As always, the entire WordPress project is grateful to security reporters for practicing responsible disclosure.

PHPMailer Update

Last month a security vulnerability (CVE 20016-10033) in the PHPMailer library was made public. WordPress uses this library as the basis for its email functionality. The Security Team has spent some time analysing this vulnerability, and how it applies to WordPress. This vulnerability does not appear to be directly exploitable in WordPress Core, or any major plugins in the plugin directory. The wp_mail() function, which WordPress Core and most plugins use for sending email, blocks this vulnerability from being exploited.

All Changes

Here’s a list of all closed tickets, sorted by component:


  • #39132 – WP 4.7, object-cache.php breaks the site if APC is not enabled in php

Build/Test Tools

  • #39327 – Database connection errors in unit tests on 4.7

Bundled Theme

  • #39138 – wordpress 4.7 default theme does not get installed when upgrading
  • #39272 – Twenty Seventeen: Incorrect $content_width
  • #39302 – Twenty Seventeen: Featured image not displayed on single template
  • #39335 – Twenty Seventeen: customize-controls.js incorrectly assumes theme_options section is always present
  • #39109 – Twenty Seventeen: starter content array needs a filter
  • #39489 – Twenty Seventeen: Bump version and update changelog


  • #37982 – 4.6.1 Breaks apostrophes in titles and utf-8 characters


  • #39280 – comment permalink wrong in WordPress 4.7
  • #39380 – wp_update_comment can cause database error with new filter


  • #39009 – Customizer: the preview UI language should be the user language
  • #39098 – Customize: Clicking on child elements of preview links fails to abort navigation to non-previewable links
  • #39100 – Customize: Edit shortcuts do not work if page hasn’t been saved and published
  • #39101 – Customize: edit shortcuts for custom menu widgets do not work
  • #39102 – Customize: Shift-click on placeholder nav menu items fails to focus on the nav menu item control
  • #39103 – Customize: menus aren’t deleted
  • #39104 – Customize: starter content home menu item needs to be a link, not a page
  • #39125 – Customize: Video Header YouTube field has issues when whitespace is inserted at beginning or end of URL
  • #39134 – Customize: custom CSS textarea is scrolled to top when pressing tab
  • #39145 – custom-background URL escaped
  • #39175 – Customizer assumes url is passed with replaceState and pushState
  • #39194 – Invalid parameters in Custom CSS and Changeset queries
  • #39198 – Customize: Apostrophes in custom CSS cause false positives for validation errors
  • #39227 – Changeset parameter not generated
  • #39259 – ‘custom_css_post_id’ theme mod of `-1` doesn’t prevent queries
  • #39270 – Use a higher priority on wp_head for inline custom CSS
  • #39349 – Customizer (mobile preview) site title extra padding
  • #39444 – Text Decoration Underline removes on hover in Customizer


  • #39276 – Link Editor bug – target=”_blank” not removed
  • #39313 – Add New button not disappearing in Distraction-free Writing mode
  • #39368 – .page-template-default body class in editor doesn’t appear in initial post/page load.

External Libraries

  • #37210 – Update PHPMailer to 5.2.21


  • #39066 – `fetch_feed()` changes REST API response `Content-Type`
  • #39141 – RSS feeds have incorrect lastBuildDate when using alternate languages


  • #39148 – Correct concatenated dynamic hooks
  • #39433 – Update copyright year in license.txt


  • #37839 – wp_remote_get sometimes mutilates the response body
  • #37991 – fsockopen logic bug
  • #37992 – fsockopen hard codes port 443 when http scheme used
  • #38070 – RegEx to remove double slashes affects query strings as well.
  • #38226 – “cURL error 23: Failed writing body” when updating plugins or themes
  • #38232 – Setting `sslverify` to false still validates the hostname


  • #39195 – Undefined index: extension in class-wp-image-editor-imagick.php on line 152
  • #39231 – Allow the pdf fallback_intermediate_image_sizes filter to process add_image_size() sizes.
  • #39250 – Undefinded Variable in Media-Modal

Posts, Post Types

  • #39211 – is_page_template could return true on terms


  • #38700 – REST API: Cannot send an empty or no-op comment update
  • #38977 – REST API: `password` is incorrectly included in arguments to get a media item
  • #39010 – REST API: Treat null and other falsy values like `false` in ‘rest_allow_anonymous_comments’
  • #39042 – REST API: Allow sanitization_callback to be set to null to bypass `rest_parse_request_arg()`
  • #39070 – WP-API JS client can’t use getCategories for models returned by collections
  • #39092 – REST API: Add support for filename search in media endpoint
  • #39150 – Empty JSON Payload Causes rest_invalid_json
  • #39293 – WordPress REST API warnings
  • #39300 – REST API Terms Controller Dynamic Filter Bug
  • #39314 – WP-API Backbone Client: buildModelGetter fails to reject deferred on fetch error


  • #39215 – Support for string $args in wp_get_object_terms() broken in 4.7
  • #39328 – Adding terms without AJAX strips “taxonomy” query arg


  • #39246 – Theme deletion has a JS error that prevents multiple themes from being deleted.


  • #39047 – Installer tries to create nonce before options table exists
  • #39057 – FTP credentials form doesn’t display the SSH2 fields on the Updates screen


#4-7, #4-7-1, #maintenance, #release, #security

4.7.1 Bug Scrub

Thursday, January 5th 12:30pm CST has been scheduled for a bug scrub.

The bug scrub focus will be on tickets milestoned for 4.7.1 and the conversation will take place in #core. This will be the final bug scrub for 4.7.1 and any tickets remaining in the milestone after the bug scrub will be punted to 4.7.2 or a future release. Reminder that 4.7.1 is scheduled for release on Tuesday, January 10, 2017.

#4-7-1, #bug-scrub

Dev Chat Agenda for January 4 (4.7.1 week 4)

This is the agenda for the weekly dev meeting on January 4, 2017 at 15:00 CST:

  • Schedule reminder: We need to agree on a timing for a 4.7.1 RC. RC means the list of tickets should be at zero, as a release candidate is supposed to represent software you believe you can release. It is currently at 21. (50 have been closed so far.)
  • Ticket reminder: For any tickets you’ve moved into the milestone, please take action on these in the next week.
  • Getting ready for RC with a 4.7 open ticket scrub

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!

#4-7-1, #agenda, #core, #dev-chat

Dev Chat Summary: December 21st (4.7.1 week 2)

This post summarizes the dev chat meeting from December 21st (Slack archive).

4.7 Retrospective

  • Reviewing comments on 4.7 Retrospective post on Make/Core
  • We will go through comments and discuss if there are changes to our process that we should recommend
  • Goal is not to second-guess decisions that were made, the goal is to figure out if the process can be improved in future releases
  • Things to start doing:
    • “We failed at getting the field guide and email to plugin dev out early enough. We have aimed to have that out around beta 2 and usually end up getting it out around RC the last few releases. This time it came out the day before (field guide) and day after the release (email).”
      • Coming up with some documentation and ensuring that it’s not just owned by one person is a good way to improve it
      • We should also ensure it is included in the release checklist
    • “The posts explaining new features and changes are helpful, but I think that we need more of them. I follow the trac feed, and sometimes I know that as a plugin developer a particular ticket is important for me to take note of, but it can be difficult to unravel exactly what the final decision was just based on the changesets. An example of something that is going on right now is the a11y team’s work on removing excessive content from headings on admin screens. Often API changes get documented and UI changes don’t, but I’m a perfectionist and I like to stay up to date on the latest design/a11y evolutions as well. I can usually figure out what changes I might want to make in my plugins based on the changes in core, but I’m sure that often most plugin developers don’t even know that there was a change, if they don’t read every ticket.”
      • Request here is to have more Dev Notes and explanations about what is changing
      • It would help to spread the load of writing Dev Notes a bit, sometimes they are time consuming, especially if you’re not much for writing this sort of contextual summary
      • Some components generate a component summary dev note which is a good practice
      • Should we also maybe reach out to the docs team to see if they want/can help?
      • Anyone have ideas for how we get people involved with drafting the note even if they aren’t leading developers on a feature/component?
      • We do list out every change in the “this week in core posts” (shout out to the team that works on those!) already, so there isn’t anything that goes unannounced
      • The solution suggested is more posts, but the problem appears to be that people aren’t seeing changes that they think might affect them
      • Getting to Trac and subscribing to whatever feed is a little hidden. Even Slack notifications is hidden. A more public place would be good.
      • The solution could be to push people to the Week in Core posts, they already list every change categorized by components
      • Someone willing to lead a discussion (likely on make/core) on how to improve this?
      • Action Item: wait and see how lack of timed release cycles plays out
    • “We need to collectively review the “feature plugin merge guidelines” listed here. While development in plugins has become less prominent, most of the bigger projects merging into core in 4.7 (I would exclude the REST API since that’s less user-facing) skipped many of the steps here. A lot of the points don’t apply to most projects – to the point that the checklist is often forgotten entirely. But there remains a need for better quality control and an updated checklist or recommended merge considerations for larger projects should be created accordingly. These written guidelines can better inform merge decisions and assess readiness.”
      • Can we reasonably make full test coverage (covering basic use cases at least) a requirement there?
      • This may be null as feature plugins may not play a significant, or any, role in the future
      • More “wait and see how new process/focus shakes out”
      • Action Item: No more feature plugins
    • “On a related note, clearer procedures about backing out merged features are needed. Particularly if a feature goes through an extensive process to demonstrate readiness and is approved for merge, input on removing the feature during beta/RC should be solicited publicly via make/core posts and scheduled meetings, similarly to the initial merge decision. Otherwise, the decision to remove a feature can seem to ignore the value of the opinions that went into making the decision initially and may not be fully informed about the broader implications with respect to related aspects of a component. If work on a feature seems to stagnate as bugs accumulate during beta and a lead is considering pulling it due to lack of attention, contributors working on the feature should be notified so that they can address the issues or recommend removing the feature based on availability. Perhaps putting more trust in the feature teams and component maintainers that are most intimately familiar with a given project could help ensure that decisions are more broadly considered.”
      • Still a question of who really owns final decision/veto power; @matt as product owner likely
      • Whomever is leading the release has final decision. That’s why they’re a lead. That much should be clear.
      • Action Item: continue to communicate changes clearly and early
      • Release leads and core leads need to be trusted to prioritize based on goals for the release
      • When somebody is unable to solicit feedback, we need to have honest conversations about why this is happening
    • “Add automated acceptance testing for the user flows. If we add these for new features added, we can ensure they work across browsers. And in future releases, these tests can ensure that we don’t break existing flows. Run tests on BrowserStack. See #34693.”
      • Any volunteers to help work on this?
      • Anyone think automated acceptance testing for user flows is a bad idea?
      • It could be difficult to maintain
      • This is done at Automattic:
      • Action Item: keep exploring in the ticket
    • “more focus on Trac and tickets, every committer should try to follow Trac on a daily basis. Not to know 100% of the details of each ticket but at least to get a sense of what’s going on. Also, the number of tickets on Trac is increasing more and more, there’s the need of some serious ‘Trac Gardening'”
      • A big ask for every committer following Trac on a daily basis
      • Especially since the vast majority of committers aren’t being donated anywhere near full time (and a large number are 100% volunteer)
      • This is why there’s component maintainers, so that we don’t overburden each person
      • Trac Gardening is something anyone is welcome to do, you don’t need to be a committer
      • Trac Gardening would benefit from some mentorship to be more effective
      • If there could be some mentoring for this – an initial joint meeting to get people started might we get some more interest?
      • We could benefit from improved workflows for managing the resources we do have and to reduce the uncertainty in gardening/contributing in non-code ways
      • Trac Gardening can be a thankless task to a novice who comments on tickets, asks for dev-feedback and then nothing further happens for months. Perhaps the dev-feedback tag needs watching more rather than all tickets.
      • Action Item: generalize 4.7 Bug Scrubs page “to run a bug scrub, announce it here, talk to these people, look at this report in Trac, then ping people on the tickets listed”
  • Things to continue doing:
    • “The combination of a Git startup phase and Slack is excellent. At least for the Twenty Seventeen theme.”
      • GitHub likely helps get new contributors involved, but not sure they stick around
      • GitHub is easier to follow along, post mockups, get feedback, review code
      • GitHub better with searching, labelling, organizing, looking at PRs, realtime updates, making branches and then submitting PRs from branches, plus its app
      • Our current code review process is sub-optimal because there are no workflows to support it (e.g., line-by-line comments on changes)
      • It would be good to separate what is the project management tool vs. version control method
      • GitHub is sub-optimal when iterating on PRs. In Trac, you can make minor changes to a patch and upload it to a ticket. In Github, depending on permissions patch iteration is not straightforward.
    • “Weekly design meetings.”
    • “On the upside, having clear deadlines for when enhancements need to be merged into core is very helpful for prioritizing time and focussing resources. I hope we will continue some form product calendar in the spirit of “deadlines aren’t arbitrary,” even if they take a different rhythm.”
    • “increase the effort to involve different teams in collaborating on features development, where different skills and knowledge are needed, of course.”
  • @jorbin to work on a summary of what was discussed here and post it on Make/Core

General Announcements

  • Uncertain if anyone is planning on running a core dev chat next week (or any weeks going forward), so watch for agendas on Make/Core or other notifications in #core

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

Dev Chat Summary: December 14th (4.7.1 week 1)

This post summarizes the dev chat meeting from December 14th (Slack archive).

4.7 Retrospective

  • Please provide Retrospective feedback on Make/Core
  • We will review the feedback and then present it for discussion during the dev chat on December 21st and agree on action items on how we can improve in the future

General Announcements

  • Discussion on overuse of post meta to make searches in queries
    • Utilization of terms as a potentially better option
    • Data could be stored in meta for precision, terms for searchability
    • Not certain this is something that Core needs to provide
    • Best to prototype and demonstrate use case via plugin first
    • Also dev education to understand problem and available, reasonable solutions
    • @igmoweb to write up idea as blog post or Trac ticket to detail concept, gather input from others via comments, and bring back to a future dev chat
  • Should we start requiring JS for most of WP Admin and thus not providing fallbacks?
    • some things that must always be usable without JS (e.g., changing/updating themes and deactivating/activating/updating plugins)
    • the general attitude of JS support (and some CSS back-compat stuff) is really one of “don’t lock the user out” for the most part
    • It’s nice to also be able to keep no-JS support for some of the most basic tasks, like posting
    • no-js MUST work when it comes to things that could break JS or are 100% vital (plugins/themes/login/logout)
    • no-js SHOULD work for basic tasks (i.e. posting)
    • no-js MAY work everywhere else
    • This needs to be defined more formally and we should define what things like “basic tasks” are
    • Plan to hash out language etc. with a draft and request for comments on Make/Core
  • How do we keep bug fixes and component roadmaps going in conjunction with feature dev?
    • Conversation postponed for a future dev chat

4.7.1 Bug Scrub

  • 4.7.1 open tickets
  • There are 9 tickets that just need merging, everything else is owned by a permanent committer
  • Still no 4.7.1 lead or timeline
  • Could “push” an auto-update to Twenty Seventeen separately from 4.7.1, but that would still need someone to own that process
  • One of the Twenty Seventeen changes relies on a corresponding core change so it would be better for them to go together for 4.7.1

#4-7-1, #core, #dev-chat, #summary

Week in Core, December 7 – 13, 2016

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

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

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

Code Changes


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


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

Build/Test Tools

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



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

External Libraries

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


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

Login and Registration


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


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

Options, Meta APIs

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


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


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


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


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




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

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

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

Bug Scrubs for week of December 5th

The following times have been scheduled for bug scrubs this week:

Thursday, December 8th 10:00am CST. Focus will be on tickets milestoned for 4.7.1 and the conversation will take place in #core.

Friday, December 9th 20:00 UTC. Focus will be on Customize tickets milestoned for 4.7.1 and the conversation will take place in #core-customize.


#4-7-1, #bug-scrub