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 Agenda for February 15th (4.7.3 week 3)

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

  • 4.7.3 Scheduling
  • Customizer team update (including discussion on CodeMirror as code editor & related accessibility questions)
  • Editor team recap
  • 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

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 Agenda for February 8th (4.7.3 week 2)

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

  • 4.7.3 Scheduling
  • Bug Scrub: 4.7.3 scrub through tickets with no owners on February 13, 2017 at 10:00 CST
  • Editor team recap
  • REST API team update
  • 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

Dev Chat Summary: February 1st (4.7.3 week 1)

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

4.7.2 Update

4.7.3 Schedule

Customizer team update

  • Still 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 release
  • We’re in need of patch contributors.
  • Tickets currently in the 4.7.3 milestone: should be read as “next minor release” and tickets are prone to punting.

Editor team update

  • The Editor team is working on a prototype, but otherwise has no other urgent updates.

REST API team update

  • The REST API team is also quiet this week, but will be meeting in-person next week.

Trac Ticket(s)

  • #39701: Do not allow editing users from a different site in REST API
    • related to multisite users handling
    • Discussed adding a ?global parameter to the API to enable managing multisite users, in 4.8 or later
    • REST API currently is essentially a single-site API, this ticket is one of the ways it behaves inconsistently regarding user management
    • @jnylen0 would like to make it behave more consistently like a single-site API for now, until we can thoughtfully and carefully add support for multisite
  • #39256: REST API: Multiple issues with setting dates of posts
    • Really needs more eyes, ideally in the form of failing/passing unit tests and patches
    • @jnylen0: These two issues are backwards-incompatible and the penalty of fixing them now, while not many people are using the API yet, far outweighs the pain of having to support and work around them in the future, essentially forever
  • #39696: REST API: Filter which links get embedded when passing the ?_embed query parameter
    • coming along nicely, but probably not as important for a point release

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

Dev Chat Agenda for February 1st (4.7.3 week 1)

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

  • Schedule: no release date scheduled for 4.7.3, will begin to assess tickets this week and plan for release timing
  • Bug Scrub: 4.7.3 scrub on February 6, 2017 at 14:00 EST
  • Customizer team update
  • 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

Disclosure of Additional Security Fix in WordPress 4.7.2

WordPress 4.7.2 was released last Thursday, January 26th. If you have not already updated, please do so immediately.

In addition to the three security vulnerabilities mentioned in the original release post, WordPress 4.7 and 4.7.1 had one additional vulnerability for which disclosure was delayed. There was an Unauthenticated Privilege Escalation Vulnerability in a REST API Endpoint. Previous versions of WordPress, even with the REST API Plugin, were never vulnerable to this.

We believe transparency is in the public’s best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.

On January 20th, Sucuri alerted us to a vulnerability discovered by one of their security researchers, Marc-Alexandre Montpas. The security team began assessing the issue and working on solutions. While a first iteration of a fix was created early on, the team felt that more testing was needed.

Meanwhile, Sucuri added rules to their Web Application Firewall (WAF) to block exploit attempts against their clients. This issue was found internally and no outside attempts were discovered by Sucuri.

Over the weekend, we reached out to several other companies with WAFs including SiteLock, Cloudflare, and Incapsula and worked with them to create a set of rules that could protect more users. By Monday, they had put rules in place and were regularly checking for exploit attempts in the wild.

On Monday, while we continued to test and refine the fix, our focus shifted to WordPress hosts. We contacted them privately with information on the vulnerability and ways to protect users. Hosts worked closely with the security team to implement protections and regularly checked for exploit attempts against their users.

By Wednesday afternoon, most of the hosts we worked with had protections in place. Data from all four WAFs and WordPress hosts showed no indication that the vulnerability had been exploited in the wild. As a result, we made the decision to delay disclosure of this particular issue to give time for automatic updates to run and ensure as many users as possible were protected before the issue was made public.

On Thursday, January 26, we released WordPress 4.7.2 to the world. The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all.

We’d like to thank Sucuri for their responsible disclosure, as well as working with us to delay disclosure until we were confident that as many WordPress sites were updated to 4.7.2 as possible. We’d also like to thank the WAFs and hosts who worked closely with us to add additional protections and monitored their systems for attempts to use this exploit in the wild. As of today, to our knowledge, there have been no attempts to exploit this vulnerability in the wild.

#4-7, #release, #security

Dev Chat Summary: January 25th (4.7.2 week 2)

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

4.7.2 Schedule

  • Reminder that no release date has been scheduled for 4.7.2 yet, we will assess tickets milestoned in Trac next week and begin planning for timing then.

Customizer team update

  • Please read two most recent posts: Customization in 2017 and Meeting Notes from January 23
  • Began scrubbing 198 tickets in customize component backlog to evaluate their priorities against the goals for the year, closing the ones that are no longer valid
  • We’re assigning tickets to the next minor release when they are defects or small enhancements that can be tackled in the next month
  • Larger enhancements that are aligned with the year’s goals which are not suitable for the next few weeks will be assigned to 4.8
  • The Future Release milestone is for tickets that should be done but which aren’t a priority for the goals of customizer this year
  • Looking for input on #39692 (Fix missing assignment of menus on theme switch), #39693 (Fix missing assignment of widgets on theme switch), and #35243 (Extending the text widget to also allow visual mode)
  • Big effort around #35760 (Provide API for TinyMCE editor to be dynamically instantiated via JS), so if you’re well-versed in TinyMCE please help
    • In summary, this will provide basic text formatting, links, and media embedding capabilities
  • If you’re looking for patches to contribute, please look at the defects milestoned for 4.7.2 that need patches
  • Continuing big picture design discussions about what the customizer should look like in light of conversations also happening with the editor

Editor team update

  • Please review the What Are Little Blocks Made Of? post and subsequent comments to get some insight into their approach on “blocks” as the focus this year

Trac Ticket(s)

  • #39256: REST API: Multiple issues with setting dates of posts
    • Not really possible to use the REST API to manipulate dates in a reasonable fashion
    • This is something we should fix ASAP before people start relying on the current, broken behavior
    • Please take a look, especially if you have experience with date handling in other parts of WP
  • #39466: Get list of post API request missing status
    • Should be a pretty easy win in 4.7.2
  • #39264: Add WP-API JS Client unit tests to core
    • Could use a review
    • Would love help automating the generation of the mocked data, ideally as a grunt task
  • #39072: Add gmt_offset as a REST API setting
    • Sort of related to date handling, a bit involved, doing it later isn’t so bad because it’s an addition rather than a change
  • #36574: Redesign term pages
    • Patch needs testing from Taxonomy team

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

Dev Chat Agenda for January 25th (4.7.2 week 2)

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

  • Schedule reminder: no release date scheduled for 4.7.2, will assess tickets next week and begin planning for timing then
  • Customizer team update
  • Editor chat summary / visuals update
  • Review on #39256 (REST API: Multiple issues with setting dates of posts)
  • 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-2, #agenda, #dev-chat

Dev Chat Summary: January 18th (4.7.2 week 1)

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

4.7.x Releases

  • Moving to monthly checkins for 4.7.x releases
  • A few people stepped up to lead a future 4.7.x releases, a great way to get involved in the release process. If you’re interested in leading a future minor release, ping @samuelsidler anytime.
  • For 4.7.2, we haven’t set a schedule yet, but we’ll be checking tickets and commits in early February to decide if we should release. @jnylen0 will be the release lead.
  • Reminder for those who helped get 4.7.1 out, please check the handbook to see if updates are needed to help @jnylen0 on 4.7.2.
  • @jnylen0: some API stuff I want to get into a potential 4.7.2, but let me know about other tickets you’d like to milestone
  • Outside pressure on MIME issues not as horrific as one might have expected (ticket #39550: Some Non-image files fail to upload after 4.7.1)
  • Potential that since people using special MIME types (which are the most likely to get caught by this bug) are already aware of having to add in custom mimes, adding in the “unbreak” plugin to fix the problem right now isn’t seen as insurmountable.

REST API team update

  • kicking off the new year by defining the scope of our activities, and prioritizing what is most critical to do first
  • @kadamwhite, @jnylen0, @tharsheblows, @kenshino, & others working on expanding the documentation
  • As we’ve moved the support for the REST API from the “WP-API” github repo, we’re seeing a few repeat questions that can be clarified with better docs & docs organization
  • Today we finished grouping existing docs from the old wp-api.org site into “Using” and “extending” buckets, which are reflected in the left nav; next up, we’ll be adding more docs for using the basics of what’s there
  • @rmccue leading the technical investigations into what to prioritize from an implementation standpoint (see: January 9th 4.8 kickoff meeting notes)
  • a lot that could be converted to use the API within WP-Admin, but change for the sake of change has never been a core value of this project
  • Whereas for something like list table actions, there’s a lot of inconsistency within the admin and converting some of those areas of functionality to use the REST API endpoints would be a clear win
  • We’re using a Trello board to track the areas of investigation
  • the Multisite and BuddyPress teams are both investigating how best to improve or create API endpoints tailored to those use cases
  • @flixos90 did an excellent writeup of our users endpoint discussion
  • We are sorting out how user and site membership management and display should work for the users endpoint.
  • master ticket #39544: REST API: Improve users endpoint in multisite
  • the REST API team intends to continue using the feature projects model to structure proposed API enhancements (such as menu support), with the added requirements of starting from a design document, and checking in with a core committer for periodic review to avoid the feature project from becoming silo’d
  • Multi-site is the first such feature project that’s officially under way.
  • For 4.7.2 we should be looking for related bugs around the existing functionality
  • @jnylen0: propose that we continually evaluate test and documentation coverage for new additions, as an excellent way to find bugs before they ship and we are stuck with them
  • Regarding bugs, to all: when (not if) you find a documentation issue or omission, or find an area where the API does not behave as expected, you are all welcome in #core-restapi at any time and we welcome the feedback.
  • We’re glad to see that the support questions so far tend to fall in a few specific buckets, but this is a new thing and the more eyes on it, the more likely that we’ll be able to identify the key areas where improvement will really drive admin or customizer improvements.
  • REST API team meeting is weekly at Monday 14:00 UTC in #core-restapi, and we welcome one and all to come chime in about how you’d like to see this used

Customizer team update

  • Please read and contribute to the discussion happening on the “What makes a great customization experience?” post
  • Also recommend reading through the meeting that happened earlier today in #core-editor. There’s going to be a lot of overlap, especially as the editor team starts working on content blocks. Lots of discussions have been happening there and in #core-customize related to what we focus on for customizer in the immediate term.
  • We’re identifying some smaller, quick wins we can do to improve the customization experience while content blocks are being built.
  • Update coming on Make/Core soon for more ways to get involved and a separate post from @karmatosed on Make/Design for some ways to help us test the existing customization flow
  • Customize team meeting is weekly at Monday 17:00 UTC in #core-customize, please do join us for general brainstorming and ticket triage (see also: prior meeting notes)

Editor team update

  • Please read and comment on the “Editor Technical Overview” post
  • Recap of #core-editor meeting on a target of a prototype plugin for exploring these concepts from @matveb: Yes, target could be:
    • Data structure.
    • Parsing mechanism.
    • General UI for block display / controls.

Trac Ticket(s)

  • #39535: Canonical redirects disallow tag named comments
    • @asalce: looking to get owner on the ticket and review of patch
    • will ping @markjaquith or @dd32 as maintainers of Canonical component

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