Dev Chat Summary: March 22nd (4.7.4 week 3)

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

4.7.4 Planning

  • Moving dev chat back an hour to 20:00 UTC starting with next week’s chat (due to DST)
  • That makes next week’s meeting at Wednesday, March 29, 20:00 UTC
  • Bug scrub planned for Thursday, March 23, 15:00 UTC to review tickets in 4.7.4 milestone, likely tackling needs-patch tickets first
  • Tentatively aiming for first week of May for 4.7.4 release, but will adjust as bug scrubs determine what needs to / should land in 4.7.4

Core team reps

  • Still looking for nominations for a Core team rep
  • Core team reps need to plan to be at the Community Summit and can take on organizing topics and people
  • @logankipp planning to be at the summit, open to helping; will tag him as Core team rep, but would like to find one more person to help
  • Please comment or contact @jbpaul17 directly if you’re planning to attend the summit and can help organize topics/people for Core

Editor team

  • Moving into feature plugin phase with Gutenberg, looking for and greatly appreciate contributions and feedback to the GitHub repo
  • Lots of discussion ongoing in the GitHub repo (e.g., Plugin: Implement block registering API), so please follow along and chime in
  • Will proceed on Gutenberg without support for older browsers
  • Will start surfacing things that may need broader discussion in how we use JS, what tools we develop, etc.

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

Dev Chat Summary: March 15th (4.7.4 week 2)

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

4.7.4 Planning

Browser support

  • Additional dev chat earlier today on topic of Browser support (Slack archive)
  • After some discussion, we arrived at the following strategy.
    • A “text” editor available to everyone is the best fallback – the new visual editor will leave old browsers behind.
    • Some form of the current version of the editor can be packaged into a plugin. Sites with users requiring a more advanced editor experience for older browsers can install this plugin.
    • The WordPress admin screen will display a notice of some sort to users with older browsers explaining the changes and how they can install the plugin for the experience they were used to (possibly utilizing BrowseHappy).
    • The editor team will use their research for the new editor to determine which buttons need to remain in the “text” editor with support for older browsers.
    • A more general discussion about browser support policies is slated to be had at the Community Summit before WordCamp EU. But this discussion can start before that (@jorbin is working on a Make post to start that conversation).
  • Any additional feedback from anyone who could not attend then is welcomed!

Core team reps

  • Last week we had nominations for @jorbin and @afercia.
  • Core team reps need to plan to be at the Community Summit and can take on organizing topics and people
  • @afercia not currently scheduled to be at summit, but would like to
  • Please comment or contact @jbpaul17 directly if you’re planning to attend the summit and can help organize topics/people for Core

Customize team

REST API team

  • Day of REST event was successful, but delayed continuing bug triage, will pick back up on 4.7.4 to make sure we keep solving the critical pieces
  • @jnylen0 & others resolved issue with tests & daylight savings time
  • due to bandwidth the existing REST API contributor group is fully occupied with the API itself
  • existing REST API contributor group have neither the bandwidth nor the domain expertise to also be leading the WP Admin implementations that will consume the REST API
  • @adamsilverstein lead the charge with Quick Draft, and work has begun in several parallel channels, but as of right now there’s nothing that appears to have momentum
  • We need help to drive adoption of the REST API within WP Admin, please come chat in #core-restapi any time
  • We need more explicit awareness of how the other feature teams want to use the REST API, or volunteers to lead separate implementations to move away from admin-ajax where it introduces inconsistency
  • If you’re not able to lead the separate implementations, then please chime in on component tickets as they’re opened to help us triage the pain points

General announcements

  • PHPunit tests (#39265: Missing @covers and @uses in the comments block in phpunt test for wordpress)
    • @pbearne: I am trying to do is get support to have @cover and @uses required for PHPunint tests
    • @pbearne: Willing to work through the old tests to add the missing comments
    • @pbearne: I would like to propose that we require for all new / updated tests and that the code committers commit updates with these added ASAP
    • How would we use that information going forward?
    • @pbearne: add to WordPress.org as way of show code quality and tell how well we are doing
    • What would be a realistic number we’d want to achieve?
    • @pbearne: anything over 80%
  • If you use the editor, please look to complete the Editor Experience Survey.

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

Dev Chat Summary: March 8th (4.7.4 week 1)

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

4.7.3 Update

4.7.4 Planning

  • The release lead for the next regularly-scheduled minor release (currently versioned as 4.7.4) will be @swissspidy.
  • Timeline tentatively set for April-May 2017, but we’ll have to get into bug scrubs and work with @swissspidy on an actual timeline for 4.7.4 as time goes by.
  • Just like 4.7.3, the timeline may change and will be highly dependent on how triage get tickets goes.

Browser support

  • @desrosj graciously compiled a summary of the discussion along with stats –> The New Editor and Browser Support
    • The overwhelming developer sentiment in the comments was for dropping support. A handful of people expressed that we did not have a full list of pros for dropping support.
    • But there was not as much discussion as I would have liked comparing the three potential fallbacks mentioned in the post, and no new potential fallbacks were mentioned.
    • I think if a solid, workable fallback that everyone is comfortable with can be decided on, then making the decision to drop support would be made a lot easier.
    • Dropping support for lower versions of IE could impact up to 2m WordPress users on the high end.
  • Discussion continues on a follow-up post –> Continued Discussion on Browser Support
  • There will be an additional dev chat this week to further discuss the fallback strategy to be used if support is dropped for older browsers. This chat will take place on March 15, 2017 at 12:00 EDT.

Core team reps

General announcements

  • A11y: #35566 to replace widget, create new widget, or other option from @afercia
    • A couple proposals on the ticket. Some work was done on them also at WC Europe.
    • We’ve discussed this issue during last accessibility bug-scrub on Monday and thought to bring it to everyone’s attention.
    • Before moving on, we’d like to:
      • see if there’s consensus in removing the title attributes there
      • and most of all, get feedback and recommendations about the best path forward, especially from people who have more experience than the a11y team has in managing backwards compatibility issues
    • As “tooltips” can be a controversial topic so the second proposal doesn’t use them
    • Looking for input on the best option: Deprecating the old widget and introduce a new one? Just replace the current widget? Or something else?
  • #39377: wpautop adds a extra </p>
    • @pbearne looking for dev-feedback, input from @azaozz
  • In a minor release we can consider string changes in moderation and for core focuses only, but we’d need a string freeze two weeks prior.

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

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

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

4.7.3 Schedule

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

Community Summit

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

Browser support

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

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

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

Rescheduling REST API meeting for this week

We’re rescheduling the REST API weekly meeting from February 20 (February 20, 21:00 UTC) to February 21 (February 21, 21:00 UTC). See you in #core-restapi!

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