Media Weekly Meeting Recap (March 2, 2017)

This post is a summary of the latest weekly Media component meeting, which took place in #core-media on Slack, on March 2, 2017 19:00 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Attendees: @joemcgill, @sergeybiryukov, @blobfolio, @adamsilverstein, @mikeschroder, @melchoyce, @karmatosed, @desrosj, @azaozz.

Prioritizing 4.8 tickets

With all Media tickets for 4.7.3 clear, we spent this meeting looking forward at our priorities for 4.8, which already included 12 tickets at the time of the meeting. With the focus for 4.8 being on the editor, customization, and the REST API, we discussed additional tickets that contribute to the goals of those projects or which may prepare for future enhancements in those areas. Here are a list of tickets mentioned during the meeting:

  • #39647: Make media upload “HTTP error.” more user-helpful
  • #15311 and #21295: Which are related to the previous ticket, in that decoupling the intermediate size generation from the upload process will probably be necessary.
  • #36191, #36442, and #21455: all relate to improving responsive/retina image support in the customizer.
  • #39993, #39994, and #39995: Splitting the media widget project into three separate widgets for image, video, and audio. @melchoyce mentioned that image is the priority.
  • #36581: Customizer Header Image Control should extend the cropped image control
  • #21819: Use an image size for custom headers instead of duplicating an attachment
  • #37840: Optimize full size images
  • #24251: Reconsider SVG inclusion to `get_allowed_mime_types` – @blobfolio and @enshrined have renewed interest in working on this. If you’re interested, take a look at this repo and provide testing/feedback.
  • #39963: MIME Alias Handling
  • #39883: Code hooking on `image_downsize` can no longer assume the file is an image (related: #39980). This one is a priority for the next minor release.

In the upcoming weeks, we plan to prioritize these and assign ownership to contributors in order to help people focus efforts and to help new contributors know where to get involved. This list is large, so if you’re interested in helping out, please feel free to jump in on the tickets themselves, ping in #core-media, or leave a comment below.

If there is something you feel should be prioritized that is not included on this list or already on the 4.8 milestone, please leave a comment on this post or bring it up in the #core-media channel on Slack. As always, important bug fixes will be considered as they are presented.

Next Meeting

Due to conference travel, we’ll be skipping next week’s meeting, with the next one scheduled for March 16, 2017 19:00 UTC.

#core-media, #media, #weekly-update

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

Weekly Multisite Bug Scrubs

The multisite team has recently been focussed on figuring out and planning the implementation of REST API support for multisite features, which has been the primary topic during the weekly office hours. Unfortunately discussion about regular bugs and small enhancements has been a bit on hold because of that.

Therefore we would like to start running weekly bug scrubs again, and in Tuesday’s meeting we decided to have these every Monday at 18:00 UTC. We will continue to primarily focus on the REST API during office hours, so there will be a clear separation of concerns.

Please join us in #core-multisite if you’re interested or have a bug to discuss. The initial bug scrub will be on Monday 18:00 UTC.

#bug-scrub, #multisite, #networks-sites

Week in Core, February 22nd – 28th, 2017

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

  • 41 commits
  • 46 contributors
  • 76 tickets created
  • 21 tickets reopened
  • 71 tickets closed

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

Code Changes


Build/Test Tools


  • When commenting on a draft post, display a friendly error message if the user can view the post. [40128] #39650


  • Ensure entities in the site title are decoded when used in the body of the new user email. [40127] #39446



  • Bump the version after the 4.7.3-RC1 packaging. [40141] #
  • Version bump for WordPress 4.7.3-RC1 [40140] #

Networks and Sites

  • Multisite: Use WP_Network_Query in WP_Network::get_by_path(). [40102] #37217

Posts, Post Types

  • Docs: Update the description of is_singular() and WP_Query::is_singular() to be parsed correctly by [40103] #39948



  • Enable browser history support in add new theme screen. [40107] #36613



Thanks to @adamsilverstein, @afercia, @ajoa, @azaozz, @blobfolio, @codegeass, @davidakennedy, @dd32, @desrosj, @Drivingralle, @flixos90, @gitlost, @grapplerulrich, @iandunn, @ipstenu, @iseulde, @jazbek, @jeremyfelt, @jnylen0, @joehoyle, @joemcgill, @johnbillion, @johnjamesjacoby, @JPry, @markoheijnen, @MatheusGimenez, @mayurk, @mikeschroder, @milindmore22, @mnelson4, @netweb, @ocean90, @rachelbaker, @reldev, @ryelle, @sagarprajapati, @sanchothefat, @SergeyBiryukov, @spacedmonkey, @swissspidy, @triplejumper12, @welcher, @westonruter, and @xknown for their contributions!

Dev Chat Agenda for March 1st (4.7.3 week 5)

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

  • 4.7.3 RC & call for testing
  • Core submission for Community Summit
  • Browser support summary from @desrosj
  • Editor team reminder on Gutenberg UI & GitHub
  • General announcements

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, #4-7-3, #agenda, #dev-chat

The New Editor and Browser Support

If you have not already, I encourage you to read through the Editor Technical Overview and check out the great work so far in the initial Gutenberg prototype. Progress on the new editor can also be followed on the GitHub project.

While the technical overview focuses on what obstacles are faced before forming opinions on the correct way to solve them, it does not focus on the actual technology requirements of the deliverables. As contributors start to create a new and improved editor experience, these technical requirements should be clearly defined and agreed upon so that decisions and progress can be made.

Accessibility, for example, is one technical requirement. All new features must pass WCAG 2.0 AA.

Browser support is another technical requirement. A few lengthy discussions have occurred within #core on Slack and within an issue on Gutenberg’s GitHub. The discussions weigh the pros and cons of dropping support for older browsers in order to use features only supported in newer browsers to improve the editor. It is a tough decision to make because the editing experience will become less useful for a small percentage of users.

This post will attempt to summarize the discussions that have taken place so far and provide some data in an effort to elicit more discussion so a stance on this requirement can be determined.

Who Uses Older Browsers and Why?

Many users are still unable to choose which browser they use. Many companies and institutions have specific browser and version restrictions based on their own unique software, technical, and security requirements.

Here are some factors that contribute to older browser versions still existing:

  • IE8 is the highest version a Windows XP user can install.
  • IE9 is the highest version a Windows Vista user can install.
  • Windows 7 users are forced to update to IE11.

To determine how many people are still using these browsers, 3 data sources were considered. The following numbers are from StatCounter’s GlobalStats:

  • IE8: 0.41%
  • IE9: 0.26%
  • IE10: 0.26%
  • IE11: 3.79% numbers are nearly identical to these. W3Counter also shows similar numbers with IE8, IE9, & IE10 slightly higher (but with less precision as no numbers are available).

While these percentages are negligible in some contexts, it is important to remember how many people use WordPress. When these statistics are considered in the context of WordPress, they represent tens (if not hundreds) of thousands of people that could potentially be left behind if support for any of these browser versions is dropped.

Current Established Core Browser Support Policies

According to the design handbook, the current stance in Core for browsers is as follows:

  • Full support back to IE11, partial back to IE8.
  • Firefox, Chrome, Safari: Current – 1.
  • iOS Safari: Current – 1.
  • Android browser: Current major.
  • Chrome/Android: Current.
  • Everything else: Bugs fixed as reported.

Older browsers must continue to be functional, even if the experience does not match that of newer browsers.

Calypso only supports IE11 & Edge, dropping support for older versions.

Microsoft has even dropped support for IE8, 9, and 10 very early in 2016. This means that no bug patches or security updates will be released for any of those versions. Because of this, users should be encouraged to upgrade their browsers whenever possible.

Dropping support

In order to drop support for a browser, there needs to be a specific substantial benefit. Not dropping support for anyone, if possible, is desired.

The argument has been made that since this is an overhaul of a core feature essential to WordPress, it could be the perfect time to raise the minimum browser requirements.

Proposed Fallbacks

If a decision is reached to remove support for any of the browser versions mentioned, a proper fallback must be provided so users being forced to use an outdated browser can continue to enjoy using WordPress.

All potential options will be evaluated with the WordPress project’s core philosophies in mind. Please review them and consider them while brainstorming and discussing.

The following are some potential fallbacks that have been suggested in discussions.

Include two versions of TinyMCE in Core

This approach would be seamless for the user. It would, however, magnify the burden on Core’s editor component by requiring two versions of the library to be maintained. It would also ship code that a large percentage of the user base may not use. Every extra file shipped in core also has potential to reduce auto update reliability.

Move the current implementation of TinyMCE into a plugin.

This approach would allow site administrators to enable the current editor experience if their user base contains a large number of people using older browser versions. From a user perspective, this would be a very poor and frustrating experience, especially if the user is not allowed to install plugins, or does not have enough technical knowledge.

Use a simple textarea.

This is the current approach in the editor for users with JavaScript disabled. However, this may alienate some non-technical users who, for example, may not know that <em> is used for italics. A basic HTML knowledge would be required to effectively use this fallback.

Further Discussion

Do you have additional suggestions for an approach or fallback? Feelings on where the line should be drawn in the sand? Thoughts on why we should continue to maintain support for older browsers? Please mention them below.

#browser-support, #editor

WordPress 4.7.3-RC1 is now available!

Please help test! Here’s the build:

What’s in this release?

We made some improvements to media upload handling after the 4.7.1 release, so this is a good flow to test. Especially if you have the Disable Real MIME Check plugin installed, please remove it and re-test uploading your previously problematic files. See #39550 and #39552 for details.

Many of the changes are REST API-related, in particular fixes to post and comment date handling, the wp-api.js client, and a few other miscellaneous parameters. There’s a full list on the REST API changelog page.

There are also a good number of Customizer fixes and UX improvements, and a few other changes in other components.

You can browse the full list of changes on Trac.

What’s next?

Committers: Please consider the 4.7.3 milestone and the 4.7 branch frozen, barring any major issues with RC1.

The 4.7.3 release is scheduled for Monday, March 6, 2017 (one week from today).

Dev Chat Summary: February 22nd (4.7.3 week 4)

This post summarizes the dev chat meeting from February 22nd (agendaSlack archive).

4.7.3 Schedule

  • Planning to release 4.7.3 on Monday March 6, 2017.
  • This will be a bugfix and maintenance release, nothing major.
  • Latest view of what’s in/coming in 4.7.3: Trac report
  • This date is coming up pretty soon.  Ideally anything going into 4.7.3 would already be in trunk.  So please make your remaining commits ASAP.
  • Aiming for a code freeze and release candidate either Friday, February 24th or Monday, February 27th
  • Bug scrub planned for February 24, 19:00 UTC in #core

Customizer team update

  • Looking for help on testing the Media widget (#32417: Add new core media widget) as well as proposal for a minor release
    • There will be a Translation need for this widget
    • @westonruter: I’ll do final touches on the patch via the GitHub PR to avoid stepping on each other’s toes and to run the builds. If you have anything to add to the patch, please push to the feature branch. Otherwise, I’ll manually re-sync new patch changes to the PR.
    • Additional tasks to see this land in a release:
      • 1) Search for plugins and communicate with them [@ipstenu to help]
      • 2) Test and try to break the patch in it’s current form [@jnylen0 to help]
      • 3) Confirm Forums response to the question: “why didn’t you ‘just’ use {{my existing widget}}”?
      • 4) If you have a widget that does similar things, try out compat and/or extensions [@helen to help]
      • 5) Make sure that it looks good in all default themes [@jnylen0, @melchoyce to help]
      • 6) Consider whether the widget should be extendable for plugin authors to add new types [@helen to help]
    • Likely means this won’t land in 4.7.3, but will target an upcomming minor release

Editor team update

  • Looking to continue discussion on browser support, no need for an urgent decision, but there’s been some discussion that core devs might want to be aware of and review. The current Plan B is to include an old version of TinyMCE for the browsers that will not support the new one.
  • Related post with more detail: A quick guide to browser selection models
  • A lengthy, pro/con discussion ensued. @desrosj is working to summarize everything from the conversation, will add some browser stats, and post to Make/Core for the discussion to continue
  • If you have statistics that you feel will be valuable to look at, please to send it to @desrosj and he will try to include it in the conversation summary for further discussion

REST API team update

  • The REST API team has no significant updates since last week.

Trac tickets

  • set of tickets with patches from @mte90 that are looking for review. If someone out there has some time to go through any of these for review/feedback that would be appreciated.
  • #16778: wordpress is leaking user/blog information during wp_version_check()

Community Summit

  • Between now and next Friday, 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
  • See also: Community Summit 2017: Sign-up Request
  • @jbpaul17 posted to Make/Core request to capture input on the three items above, will capture that input and summarize for review in next week’s dev chat, and then send the Core team response to the Community Summit team by next Friday, March 3rd. Please review the post on Make/Core and respond with your input.

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

REST API changelog since 4.7 release

We’ve published a changelog page for the REST API:

This page can be updated using git logs as follows:

git clone
cd wordpress-develop
# for a previous release
git log --reverse 4.7.1...4.7.2 src/wp-includes/rest-api* src/wp-includes/js/wp-api.js tests/phpunit/tests/rest-api* tests/qunit/wp-includes/js/wp-api.js tests/qunit/fixtures/wp-api*
# for an upcoming release
git log --reverse 4.7.2...origin/4.7 #[paths here]

Many of the changes made so far are pretty clean fixes. Some do have backwards-compatibility implications, which is not ideal, but we’ve recognized since the 4.7 release that there was still more left to do on the API. Long-term, it’s going to be best to make these fixes very early in the history of the REST API, before people start depending on the broken behavior and we have to support it.

In addition to the items already noted on the changelog page, there are a few more fixes coming that we’re aware of. For example:

  • #39933 – correctly parse body parameters for DELETE requests
  • #39701 – remove broken multisite users handling to prepare for full implementation in 4.8 (see also this post)
  • #39256 – multiple issues with setting post and comment dates
  • #38883 – improve date_gmt handling for draft posts
  • #39947sticky handling when listing posts

WordPress 4.7.3 planning and bug scrub

As discussed in yesterday’s dev chat, we’re planning to release WordPress 4.7.3 on Monday, March 6, 2017.

To prepare for this release we will have a 4.7.3-focused bug scrub in #core tomorrow (February 24, 19:00 UTC).