Dev Chat Summary: March 14th (4.9.5 week 6)

This post is a summary of  the latest dev chat meeting which took place on March 14th (agendaSlack archive).

4.9.5 Planning

Planned release schedule:

  • Beta: 03/20
  • RC: 03/27
  • Expected release date: 04/03

Beta scheduled for next Tuesday, March 20th. Beta release process planned to begin after the weekly bug scrub.

An extra bug scrub is planned on Saturday 17th at 15:00 UTC for 4.9.5 triage.


  • Some 5.0 good-first-bug labelled tickets have been moved back to 4.9.5.
  • All tickets slated in 4.9.5 that are not 100% OK before beta release process will land in future release. @pento added 4.9.6 milestone to handle this.

Release planning: Gutenberg, GDPR, serve happy and other projects

There are a couple items that would be good to ship ahead of Gutenberg's release. How can WordPress best supports getting GDPR updates out ahead of its May deadline? Similarly for other non-Gutenberg projects (e.g., serve happy, debug screen, on-boarding improvements), how can WordPress best supports getting them out ahead of Gutenberg?

Now for Gutenberg, and as discussed last week there are various "Gutentasks" that could use some "Gutenhelp":

  • Various REST API tasks that can be done now in parallel
  • Core changes
  • New endpoints and infrastructure plans
  • How would inclusion of Gutenberg/JS packages work


  • @pento: about GDPR, there may be some smaller things ready for 4.9.5, but it will probably needs a 4.9.6/7 release towards the end of April or early May to add all the bits and pieces.
  • @audrasjb: question about new files or big changes like GDPR in a minor release.
  • @pento: new files can't be added in point releases, as a general rule, but there is no problem adding features (like GDPR) in 4.9.x releases, and there won't be a 4.10 release.
  • @pento: Serve happy needs some polish, but should be ready for 4.9.5. Unfortunately, it was merged to trunk early: There was design feedback on it which wasn't implemented.
  • Discussion about design in WordPress: @pento, @afercia, other contributors & core-committers to talk about design decisions in Trac workflow and in WordPress development in general. This topic will be discussed separately of this dev chat but it seems really fundamental.
  • @Krizzy: question about some good-first-bug tickets status while Gutenberg is being developed. @melchoyce answered if it’s something small and contained, it’s good to push that forward into a point release. And as a reminder, everybody is always welcome to contribute to the discussion, even if the ticket is already marked as "claimed".
  • @aduth: inclusion of Gutenberg/JS packages was a topic of the JS meeting this week. Conversation already started in core-js slack channel.
  • @pento: There have been some small core changes for Gutenberg that have landed in trunk already, mostly REST API tweaks. That process can continue. The larger REST API changes probably won't come until around when the merge proposal comes.
  • @kadamwhite announced REST API meeting is still 17:00 UTC post-daylight-savings, so that's an hour later than last week.


  • @matveb: 2.4 of Gutenberg was released today.
  • @sergeybiryukov: question about the right time for #41316 – Introduce "try Gutenberg" callout –, or still too early.
  • @pento: 4.9.5 release being in 3 weeks is good time for the callout to be added, so it should be kept in the milestone.

Various questions

  • @benoitchantre asked if #36455 should be milestoned for 4.9.5 to prevent OPcache issues to users invited to upgrade their PHP version.
  • @mikeschroder: that particular ticket needs a new patch.

Next meeting

The next meeting will take place on March 21st, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

Dev Chat Summary: February 28th (4.9.5 week 4)

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

4.9.5 planning

Updates from focus leads and component maintainers

WCEU Contributor Day

  • @flixos90 looking for volunteers for the core team to lead WordCamp Europe contributor day.
  • @getsource will be there, but helping with Hosting Community
  • @kadamwhite will be there, but his experience from WCUS shows it may be better for REST API folks to embed with another team and support their efforts (e.g., the Editor team)
  • @antpb willing to talk on setting up a local for Gutenberg and Core development
  • @sergey will be there helping with Meta team, but open to helping with Core during afternoon
  • Also, please keep your eyes out on tickets that would be good to be tackled at WCEU contributor day
  • If you’re attending WCEU and interested in leading the core team or targeted sub-teams (JavaScript, REST API, etc.), then please reach out to @flixos90.

General announcements

  • Progress on implementing a way to catch the issue from the 4.9.3 release is being tracked in #43395
  • @mte90 looking for review on eight tickets:
    • #40810: patch has been refreshed including unit tests, needs review
    • #34706: needs review on whether work is required or not as the desired enhancement may already exist; @danieltj to take a look
    • #14148: needs review to see if a refresh is needed, otherwise needs testing
    • #17025: needs review before another likely refresh
    • #28112: needs review and docs; @audrasjb to test the patch
    • #36661: needs review
    • #15145: needs review
    • #17019: needs testing
  • @helgatheviking looking for review on #18584, but likely wait on this for now until Gutenberg lands as nav menus might get a bit of an overhaul

Next meeting

The next meeting will take place on March 7, 2018 at 21:00 UTC / March 7, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-5, #authentication, #contributor-day, #core, #core-php, #core-restapi, #dev-chat, #gdpr-compliance, #summary, #two-factor

Dev Chat Summary: January 24th (4.9.3 week 2)

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

4.9.3 planning

  • 4.9.3 beta was supposed to be built on Tuesday, but some tickets were still actively being worked on, so it will be done after dev chat
  • @sergey to post on Make/Core with notable fixes, things to test, and link to JSHint dev note
  • RC and release are still planned for 29th and 30th, respectively
  • Note: 4.9.3-beta1 is out, post is still pending

JSDoc initiative

  • @atimmer prepared a Make/Core post to announce the JSDoc initiative
  • Feedback on the draft is welcomed, send Slack DM to @atimmer with updates
  • It looks a lot like the inline hook documentation and the setup is the same: file by file, everyone can claim a file, at the end all files will be documented
  • @kadamwhite to publish post when its ready

General announcements

Next meeting

The next meeting will take place on January 31, 2018 at 21:00 UTC / January 31, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-3, #core, #dev-chat, #documentation, #js, #jshint, #summary

Dev Chat Summary: December 6th (4.9.2 week 1)

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

4.9.2 ticket triage + timing

  • 41 tickets already marked for 4.9.2, minus fixed-major there are 39 tickets
  • #42586 is the only high priority ticket in the milestone
  • Aiming for 4.9.2 release toward the end of January 2018

Plan for 4.9.x minor releases

  • Will look to do 6-8 weeks for a release window with 4-6 weeks of work, week and a half of beta, half week of RC
  • From past experience, its best to have someone who isn’t the major release lead handle a minor release as it (1) gets the major release leads some rest and (2) gets more folks familiar with the release process
  • @kadamwhite @joemcgill @desrosj interested in helping as a minor release lead, but unavailable in January. @obenland available to lead a minor release, @sergey available as a backup lead.
  • If you have interest in being a minor release lead, please ping @jbpaul17 or mention in #core. Self-nominations are accepted and encouraged, you don't have to be an engineer, and commit access is not required but helpful.
  • We need to make sure we have people with access available for the builds, but anyone with the knowledge can organize/follow up on tickets in the lead up to a release and be a decision maker.
  • No rush to find someone with access to package a release until the week leading up to a release
  • Would be good to add a “next-minor” milestone to Trac so we could pull things into the 4.9.x milestone once they are actually resolved instead of mass punting

Definition of "minor" release

  • Bugfixes and minor enhancements/features that do not add new deployed files and are at the discretion of the release lead with suggestions/input from component maintainers.

Weekly updates from leads

  • Focus leads to provide weekly updates including:
    • what big things happened this week?
    • what needs eyes/testing?
    • what big challenges could the team use help with?
    • what decisions need feedback before being made?
  • Component leads to provide updates as necessary, though not required weekly, and focused mainly on big things or areas where we need coordination

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

Dev Chat Summary: September 27th (4.9 week 9)

This post summarizes the dev chat meeting from September 20th (agendaSlack archive).

4.9 schedule

  • Today is the feature project merge deadline
  • Bulk of the code editor improvements already merged into core, along with the Gallery widget
  • Theme browsing in the Customizer and drafting & scheduling in the Customizer to be merged tonight or tomorrow at the latest
  • Beta 1 in next Wednesday, enhancement tickets due by then
  • Bug scrubs scheduled over next week
  • @joemcgill: Anyone wanting to rubber duck #21819 over approaches in the media meeting tomorrow would be good
    • trying to solve a UX issue with a broadly defined outcome and different possibilities include varying levels of tech complexity
  • @danieltj: recommend putting version info into At A Glance metabox #35554
    • @melchoyce: let's get feedback on this and work to a decision in the next couple days

General announcements

  • @azaozz: removal of SWFUpload #41752 needs more testing in the affected plugins
    • would be great to see how the fallback works in all of them, so please help test
  • @kadamwhite: The REST API team is having a bug scrub on Friday at 15:00 UTC, and likely another the start of next week (time TBD). We’ve got a lot of tickets sitting with patches that are pretty close, so if you’ve got outstanding REST patches to discuss hope to see y’all then in #core-restapi!
  • @johnbillion: if anyone is running PHP 7.2 (currently in beta) it'd be great to test trunk. Some fixes will be going in shortly to remove deprecated notices, apart from that it should be bug free.
  • @obenland: Since [41594], orphaned widgets will get merged into the inactive widgets sidebar on theme switch, instead of becoming orphaned. what your opinions are on removing the concept of orphaned widgets entirely, and just have them be part of the inactive sidebar?
    • pre-41594 they would be shown in separate Orphaned Widgets sidebars above inactive widgets
    • @melchoyce: Looking for someone to take screenshots or a video of this in action on 4.8 and on trunk, so we can compare them visually

#4-9, #bug-scrub, #core, #dev-chat, #media-widgets, #php7, #summary

Dev Chat Summary: August 9th (4.9 week 2)

This post summarizes the dev chat meeting from August 9th (agendaSlack archive).

4.8.1 release feedback

  • Forums team hasn’t had to update the “4.8 Master List” post with any problems, a relatively smooth release altogether
  • No concerns identified that would require a subsequent immediate minor release

4.9 goals

  • @melchoyce and @westonruter have assembled a list 4.9 goals
  • @kadamwhite would like to see movement on REST API backlog tickets, specifically meta registration for object subtypes (#38323) and media permissions (#41445)
  • REST API roadmap document still being assembled, but not yet published
  • “Updating a plugin or theme via a ZIP file” and “drag and drop uploading of themes and plugins” are going to need support from contributors to the Upgrade/Install component
  • If you have interest in helping maintain the Upgrade/Install component (or any others) please reach out to @drewapicture

General announcements

#4-8, #4-8-1, #4-9, #dev-chat, #summary, #translation

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

Dev Chat Summary: February 15th (4.7.3 week 3)

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

4.7.3 Schedule

  • Completed first pass on all tickets in the 4.7.3 milestone, @jnylen0 is reviewing those that “need” to land in 4.7.3, and identifying a release date for 4.7.3 in the coming week

Customizer team update

  • #23601 (Use ACE Code Editor for Theme and Plugin editors) and #12423 (Include Ace (or similar) as default code editor)
    • Topic of discussion is a code editor library to be used in Custom CSS, WP content editor HTML view, file editor, and any other place that code is modified
    • Had planned to go ahead with CodeMirror since it is what Jetpack uses in its Custom CSS module, but @afercia pointed out accessibility problems
    • So we’re looking for insights into best of breed accessible code editor libraries
    • @afercia: looking to to understand if (1.) there’s consensus about introducing some sort of syntax highlighter library (plus other functionalities) and (2.) if it is going to completely replace the current WP content editor HTML view
    • @jorbin: Once one is decided upon, would like to encourage reaching out to the project maintainers and opening a dialogue about things like security and backwards compatibility
    • @helen: each area (Custom CSS, WP content editor HTML view, file editor) needs individual consideration and rationale
    • Goal is to provide a better user experience for when users edit code in WP
    • Custom CSS:
      • #38707: Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out
      • @westonruter this is what #core-customize is most interested in, but picking a code editor library should be done ensuring that it doesn’t cause headaches if code editors are implemented for HTML view and file editor. i.e. the same library should be used throughout core.
    • WP content editor HTML view:
      • @joemcgill: the text editor now is not technically an HTML view, but is a plain text editor that is parsed into HTML. For instance, breaks are turned into `<p>` tags, shortcodes can be typed, etc., so a “code editor” is something slightly different.
      • @helen: per @iseulde and lots of discussions over time, is a little more complicated in that it’s not an actual HTML editor, so is getting rid of wpautop() is a requirement
      • @mike: I’d love to see code highlighting in the HTML view.
      • @afercia: If both the visual editor and the text editor are going to be replaced by Gutenberg and some sort of CodeMirror-like, well the level of accessibility for both is still uncertain and there’s the danger to introduce an accessibility barrier for the main scope of WordPress: entering content.
    • File editor:
      • @jorbin: I seem to remember that having been replaced with something fancier than what is in place now, but that having been ripped out
      • @helen: File editors really raise the question of whether users should be made more comfortable in them vs. being encouraged to use something else.
      • @brechtryckaert: security-wise I’m not a fan of the ability to edit files from the backend, people who are comfortable enough to edit code usually have a prefered editor
    • @jorbin: We already have our agreed upon accessibility coding standards that state:
      • All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA

    •  @westonruter: if CodeMirror fails this test, as it seems to, then we need input on GPL-compatible code editors that are accessible.
    • @afercia: I propose to discuss this at the next accessibility meeting on Monday, invite people to do research, and possibly involve the testers group.
  • #38900 (Customize: Add REST API endpoints for changesets) and #39634 (Customize: Add REST API endpoints for panels, sections, controls, settings, and partials)
    • Thanks to @kadamwhite we have an initial (empty) feature plugin repo for the REST API endpoints for customization
    • Feel free to watch that repo and be apprised of developments
    • Next steps are to design the endpoints, write the failing tests for them, and then  go about writing the endpoint controllers
    • @kadamwhite: this is the first major effort within other areas of core that are turning up inconsistencies like #39805 (Expose featured_media property on post resources in “embed” context) so I’m excited to see what other improvements we can make as this work continues

Editor team update

  • Working full steam on prototypes, notably the Gutenberg UI prototype
  • The related GitHub repo has quickly become wonderfully active
  • Looking to discuss browser support for the new editor
    • @georgestephanis: So long as it can fall back to something that doesn’t utterly die, it should probably be fine.
    • WP Admin currently supports IE 8
    • Current browser market share
    • @jorbin: I would love to see us not drop support for anyone if possible
    • @joemcgill: Alternately, if we’re going to bump the browser requirements at any point, now is probably the time.
    • @joen: flexbox was mentioned as being nice to use in context of editor UI
    • flexbox support
  • The agenda for the Editor chat today was to discuss how using the UI prototype felt in the past week, and deciding where to take it next
  • We are looking for people to use and provide feedback the prototype, so please take a look if you can!

REST API team update

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

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

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