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

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

4.7.3 Schedule

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

Customizer team update

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

Editor team update

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

REST API team update

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

Trac tickets

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

Community Summit

  • Between now and next Friday, the Core team needs to come up with:
    • 1) a list of topics for the summit
    • 2) A list of representatives to attend the Community Summit
    • 3) One or two contributors who are willing to help with the organization of the event
  • See also: Community Summit 2017: Sign-up Request
  • @jbpaul17 posted to Make/Core request to capture input on the three items above, will capture that input and summarize for review in next week’s dev chat, and then send the Core team response to the Community Summit team by next Friday, March 3rd. Please review the post on Make/Core and respond with your input.

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

REST API changelog since 4.7 release

We’ve published a changelog page for the REST API: https://developer.wordpress.org/rest-api/changelog/

This page can be updated using git logs as follows:

git clone https://github.com/WordPress/wordpress-develop
cd wordpress-develop
# for a previous release
git log --reverse 4.7.1...4.7.2 src/wp-includes/rest-api*
# for an upcoming release
git log --reverse 4.7.2...origin/4.7 src/wp-includes/rest-api*

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

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

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

WordPress 4.7.3 planning and bug scrub

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

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

Week in Core, February 15th – 21st, 2017

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

  • 42 commits
  • 35 contributors
  • 64 tickets created
  • 14 tickets reopened
  • 75 tickets closed

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

Code Changes

Administration

  • JavaScript: when starting Backbone history, stop if previously started. [40076] #39612

Customize

  • Prevent vertical clipping of thumbnail in header image customizer control. [40100], [40082] #21785, #38559
  • Extend auto-draft life of a customize_changeset post whenever modified. [40099] #30937, #39713
  • Allow custom post types to be used in starter content. [40098] #38615, #38114, #39610
  • Ensure edit shortcuts get re-created for nested partials when a parent partial is refreshed. [40097] #39101, #39353
  • Skip intercepting non-HTTP(S) links in customizer preview just as jump links are ignored. [40096], [40064] #39797
  • Always enqueue customize-preview stylesheet in the customizer preview to style selective refresh and visual edit shortcuts. [40095] #27403, #39498
  • Trim whitespace from nav menu item titles so that the underlying object’s original title appears as input placeholder and in the control’s title. [40094] #38015, #39600
  • Update customize.php URL with changeset_uuid param the instant a change is made instead of deferring until the changeset update request responds. [40093] #39227
  • Ensure root values are accessible in multidimensional custom setting types. [40088] #32103, #36952
  • Introduce get_header_video_url filter for the return value of get_header_video_url(). [40087] #39512
  • Update the introduced version in the docs for the get_header_video_url filter to 4.7.3. [40086] #39512

Feeds

Formatting

  • Fix wpautop() to stop adding paragraph tags around <figcaption>. [40091] #39307

HTTP API

  • Restore backwards compatibility with the http_api_curl filter – it expects that the handle parameter is passed as a reference, however [39212] missed that. [40068-40069] #39783

Help/About

  • About page: Remove autoplay and loop attributes on “Theme Starter Content”, “Edit Shortcuts”, and “Video Headers” videos, originally added as a part of [39512]. [40089-40090] #39560

I18N

Media

  • Avoid PHP Warnings in get_post_galleries() when processing empty

    shortcodes and avoid returning the incorrect results when the global $post does not match the provided post ID. [40070] #39277, #39304

  • Debounce the media grid search, avoiding duplicate requests. [40060] #38911

Menus

  • Prevent notice thrown in class-walker-page.php. [40092] #39564
  • Docs: Correct @return value type for wp_nav_menu(). [40062] #39890

Options, Meta APIs

REST API

  • Fix multiple issues with setting dates of posts and comments. [40101] #39256
  • JavaScript client should use _.extend when merging objects. [40084] #39341
  • Include the status property in view context responses from the Posts endpoints. [40080-40081] #39466
  • Correctly serve the index with PATH_INFO [40079] #39432
  • Cast revision author ID to int. [40078], [40063] #39871
  • JavaScript client – improve route discovery for custom namespaces. [40074] #39561
  • Skip generating the client test fixtures in PHP 5.2 and 5.3. [40066] #39264
  • Fix the client test fixture generation in PHP 5.2 and 5.3. [40065] #39264
  • Improve test fixture generation, normalizing data. [40061] #39264

Shortcodes

  • Avoid PHP Warnings in get_post_galleries() when processing empty

    shortcodes and avoid returning the incorrect results when the global $post does not match the provided post ID. [40071] #39277, #39304

Taxonomy

  • Disallow overriding the name property when registering a taxonomy. [40083] #39308

Upload

  • Media: In wp_unique_filename(), use explicit type casting when incrementing $number. [40075] #39774

Thanks to @adamsilverstein, @asalce, @azaozz, @batmoo, @bhargavbhandari90, @bor0, @bradyvercher, @ccprog, @celloexpressions, @certainstrings, @chesio, @dd32, @dhanendran, @dlh, @drrobotnik for initial patch, @jazbek, @jnylen0, @joemcgill, @Kelderic, @ketuchetan, @netweb, @ocean90, @pavelevap for reporting, @pbearne for tests, @pento, @peterwilsoncc, @rachelbaker, @sanket.parmar, @seanchayes, @SergeyBiryukov, @stevenkword for initial patch, @swissspidy, @tfrommen, @westonruter, and @wpfo for initial patch for their contributions!

#4-8, #week-in-core

Planning for Community Summit 2017

In preparation for the 2017 WordPress Community Summit (“CS”) on June 13th-14th before WordCamp Europe in Paris, France we’ve been asked to provide the following (in summary):

  1. A list of topics for the CS
  2. A list of representatives to attend the CS
  3. One or two contributors who are willing to help with the organization of the CS

This post serves as a request for input for the above three areas. Note that these three requests are detailed further with some clarifying notes on Make/Summit.

I will capture and summarize comments on this post ahead of next week’s Core dev chat, will present them for review in next week’s Core dev chat, and then send our responses back to the Community Summit team by next Friday, March 3rd.

#community-summit

Nextgen Bootstrap/Load Feature Project

The bootstrapping process of WordPress Core (affectionately called the “Bootstrap/Load” component around here) is a critical piece of the system, and everything else depends on it being reliable and performant. However, developers and system administrators also need it to be flexible enough to adapt to the requirements of their differing projects or environments. Large-scale WordPress installations often require substantial customizations to adjust for scalability and redundancy.

Considering the importance of this component, the documentation is not adequate, and very few people actually know what the exact flow is. More importantly, there isn’t a wide understanding of why specific decisions had been taken, and how later code depends on the bootstrap process.

This proposal aims to launch a feature project to work on the next iteration of the bootstrap component with a set of specific goals in mind.

Goals

To be able to guide the design process and have measurable success metrics, clear goals need to be defined.

Here’s an overview of what specific goals the project should aim for:

  1. The component has proper documentation for every step of the process.
    Documentation will include both clear comments in the source as well as an external documentation space that includes reference material, execution flow diagrams, best practices and examples of usage.
  2. The component models a modernized flow which still provides same sane defaults, but enables advanced use cases in a supported way.
    Customizing high-volume sites or specialized applications should be less “hacky”, and all of the major subsystems should provide reliable means of configuration/extension.
  3. The component adapts to differing contexts to optimize both performance and memory consumption where possible.
    The system should be able to intelligently load only the parts of the code that are strictly necessary for the current requests, through means of conditional execution flows, smart routing, proxy objects and autoloading. Special consideration should be given to the WP REST API endpoints to make them as fast and efficient as possible.
  4. The component offers a coherent way of supporting all versions of multisite (networks), reducing some of the idiosyncrasies that currently exist.
    The difference between single sites, networks of sites and networks of networks should be kept as small as possible so that less care needs to be taken to have the code work reliably with all of them.
  5. The component considers both backward compatibility as well as forward compatibility.
    It is of paramount importance that existing sites do not break due to the changes that will be proposed with this project. However, forward compatibility needs to be taken into account just as well, to create a next version of the bootstrap component that can easily grow with future requirements in a controlled way.

Project Phases

The project will have four different phases: Discovery, Design, Execution and Merge Proposal.

1. Discovery

The Discovery Phase aims to properly research and document the status quo. It will be a thorough analysis of source code, trac tickets and contributor discussions to decipher the reasoning behind the current implementation and what the requirements, strengths and weaknesses are. Documentation will be written in parallel, logging all findings and producing a better onboarding process for this component. Characterization tests will be written to be able to detect regressions when making changes in phase 3 later on.

2. Design

The Design phase will examine all the findings from phase one to design a new version of the bootstrap component that meets all the requirements and strengths while reducing some or all of the weaknesses and improving reliability, flexibility and performance.

We want to avoid having yet another component update that just grows organically. There should be strong principles in place that make sure that the new version is not only backward compatible but also forward compatible.

3. Execution

The Execution phase will create a modified fork/branch of WordPress Core, to allow for collaborative work on this new iteration of the bootstrap component.

Through automated tests, refactoring will be guided to implement the design from phase 2. The characterization tests from phase 1 will make sure that compatibility remains a given, even for “compatibility-enforced bugs”. Optional mechanisms to get saner results in such cases will be discussed on a case-by-case basis.

4. Merge Proposal

The Merge Proposal phase will be the final phase of the project, identifying a clean merge process and a proper migration path to merge the new version of the component into Core.

Metrics will need to be defined to have measurable and achievable goals that can objectively tell whether the Component is ready to be merged.

Contributions

During the initial Discovery Phase, contributions in the following areas will prove to be useful:

Advanced Use Cases

We need lots of data about the types of customizations that people use for their projects: bootstrap modifications (WP-CLI), complex network hierarchies, folder rearrangements, specialized caches, etc.

Problems With Current Code

We need to know about all and any challenges and limitations that you have been experiencing with the current bootstrapping flow: setups that were difficult or impossible to achieve, settings that didn’t yield the expected results, etc.

Documentation

Documentation will not only need to be written for the way the current code works, but also for all deprecated functionality, buggy behavior and unexpected side-effects. We are going for completeness, not ease-of-use here. Documentation should also cover best practices for modifying the bootstrap process.

Join us in #core-bootstrap to start contributing!

Thanks to Helen Hou-Sandì (@helen), Jeremy Felt (@jeremyfelt) and Aaron Jorbin (@jorbin) for their help in shaping this proposal.

#bootstrap-load, #core

Dev Chat Agenda for February 22nd (4.7.3 week 4)

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

  • 4.7.3 Timing
  • Customizer team (Media widget review/testing, proposal for a minor release)
  • Editor team continued discussion on browser support (see: Gutenberg issue #93)
  • 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

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!

Media Weekly Meeting Recap (Feb 17, 2017)

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

Attendees: @joemcgill, @sergeybiryukov, @dnavarrojr, @adamsilverstein, @pputzer, @mikeschroder, @desrosj, @gitlost.

Meeting Time Change

The group decided to move the weekly meeting to Thursdays at 1900 UTC, which is more convenient for participants.

Tickets discussed

We spent this meeting doing a bug scrub for tickets on the 4.7.3 milestone.
Start: [https://wordpress.slack.com/archives/core-media/p1487361876001149]

  • #39883 image_downsize assumption changes: Added to 4.7.3 milestone for prioritized discussion.
  • #39774: PHP 7.1 warning during upload of file with the same name: 
Approved for merge from 4.8 to 4.7.3. @sergeybiryukov to handle it.
  • #37140: Reset of rotation orientation when image is rotated:
 @mikeschroder tested, found fix for issue in tests. Reached out to @sanchothefat re: whether the current number of images being tested can be reduced to not slow down the tests. Otherwise, this looks ready.
  • #39516: Media grid upload errors display below the grid:
 Still needs testing. @joemcgill would appreciate additional eyes here.
  • #39550/#39552: Some Non-image files fail to upload after 4.7.1: 
@joemcgill to write up two possible solutions for the problem to address image files not properly validated with GD so that we can profile appropriately. There are performance concerns around adding ⁠⁠⁠⁠finfo_file() to all files uploaded.
  • #39875: PDF previews overwrite existing images with the same name:
 Worked through this in chat. @gitlost uploaded one approach to the ticket, with @desroj writing up another one based on our conversation in the meeting. Decision being that the filename saves should be handled in the same way that saves happen in the Media Gallery’s image editor. The problem is in https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/image.php#L254, with pre-existing method in https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/image-edit.php#L779.

Our next meeting is scheduled at the new day/time of February 23, 2017 at 1900 UTC.

#media, #weekly-update

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