Dev Chat Summary: April 18th (4.9.6 week 3)

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

4.9.6 planning

Updates from focus leads and component maintainers

  • The Editor / Gutenberg Team released v2.7 and published information on how they’re organizing component-specific issues in their GitHub repo. Component Maintainers will benefit from utilizing the specific milestone setup for their component when trying to identify areas that would best benefit Gutenberg. There are also additional milestones for a11y and docs.
  • The GDPR Compliance Team published notes from their recent meeting covering recent deployments, available resources, plugin dev guidelines, and the addition of a privacy section to the readme.txt file
  • The PHP Team published notes from their recent meeting
  • The Media Team published notes from their recent meeting covering a time change for their meeting (to Thursday’s at 20:00 UTC) and their main focus on a Gutenberg Media triage
  • @jorbin looking for a proposal on Make/Core post from team working on the JS reorg / no longer using srcwith a summary and proposed timeline; majority of current info is in #43055

Next meeting

The next meeting will take place on April 25, 2018 at 20:00 UTC / April 25, 2018 at 20: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-6, #core, #dev-chat, #summary

Dev Chat Summary: February 21st (4.9.5 week 3)

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

4.9.5 planning

  • @danieltj self-nominated to lead this minor release, but as a first time lead we’d like someone who already led one to be deputy. Please reach out to @jbpaul17 (@jeffpaulon Slack) or comment on this post with nominations.
  • @audrasjb able to assist with bug scrubs, testing, and triage
  • 4.9.5 timeline is still dependent on reducing the number of sites stuck on 4.9.3
  • Auto-update needs automated end to end tests, @jorbin to look into specifying what’s needed and @joostdevalk on getting implementation assistance
  • @schlessera to investigate why the update via WP-CLI didn’t fatal whereas the cron update did

Updates from focus leads and component maintainers

General announcements

  • @iandunn ready to commit the following tickets, but would like a quick review from another committer first:
    • #41112 – Show WordCamps higher up in the News Dashboard widget – @sergey to review and mark for commit
    • #42282 – Provide means of executing PHPUnit continuously over watched files in local environments
    • #43101 – Test to ensure MediaElement SWFs aren’t accidentally added to build
  • @benoitchantre looking for review on four tickets:
    • #36455 – Call opcache_reset() after plug-in, theme or core update
    • #14877 – Ability to create exclusive custom taxonomies
    • #27111 – Turning off global comments should include existing content
    • #42645 – Support passing version number to add_editor_style() – @danieltj has a patch for this but it needs testing
  • @mte90 looking for review on four tickets:
    • #40810 – wp_mail fails to send email on WP auto update when wp-cron is called directly by php
    • #30991 – Post type object capability ‘delete_posts’ is referenced in the posts list table but does not exist unless ‘map_meta_cap’ is set to true for post type
    • #20037 – Introduce ‘noindex’ filter for robots meta tag
    • #14148 – wp_get_attachment_url() is not url encoding

Next meeting

The next meeting will take place on February 28, 2018 at 21:00 UTC / February 28, 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, #core, #dev-chat, #summary

New Contributors Meeting Recap – February 14th

On Wednesday, February 14th, the weekly new contributor meeting was held in the #core Slack room. Here is a recap of the meeting. A full chat log is also available.

Participants: @adamsilverstein @abdullahramzan @aduth @chetan200891 @clorith @desrosj @dougvanslembrouck @jorbin @joyously @lakenh @notnownikki @thrijith @welcher @williampatton @xkon

Discussion Highlights

Contributing with Git

Even though every change to WordPress core must pass through Trac/SVN eventually, SVN is not the only option for creating patches.

See these articles for more intofmation on creating patches with Git:

Coding standards

An easy way to make your IDE/editor aware of the WordPress coding standards regarding whitespace usage is to use the .editorconfig file that trunk contains. This file uses a common standard, and there are plugins available for almost all popular environments that automatically parse the file and adjust the whitespace settings for the project.

Extensions can be found on the website of the project. Some IDEs like PHPStorm already come with built-in tools for the WordPress coding standards.

Refreshing a patch

Older tickets often have attached patches that no longer apply to the current codebase. The older the ticket, the lower the likelihood that the associated patch will apply cleanly. If you find a ticket with a patch that does not apply, add the needs-refresh keyword to indicate this.

Over time, code shifts around and sometimes these patches only need a bit of reorganization to apply. Other times, you may find code that has been refactored and needs an alternative solution for the proposed bug/enhancement. Once this has been done, create a new patch with the clean code and submit it to the ticket.

While refreshing a patch, it’s also a good idea to make sure the patch is what you would consider the best approach and to verify that it follows the style guide.

See Contribute with Code handbook article for more information.

Ticket ownership

Ticket owner is generally responsible for moving the ticket forward. From the handbook:

When working on a ticket, the Owner field is typically left blank, even if you have contributed a patch. Committers utilize the field to offer traction for a ticket, to identify they are investigating, committing, or otherwise following a ticket, or to tentatively accept the bug or enhancement for core inclusion. It is also common during the feature development phase for developers to accept tasks in the area of responsibility for which they have volunteered, as well as related bug reports. Trusted contributors may assign tickets to others based on an inside knowledge of who should be responsible for reviewing it.

For good-first-bugs, the person who submitted the patch is assigned as an owner so that the ticket shows as “claimed” in the queue.

It’s OK to drop ownership if the ticket is no longer relevant for you, just reassign it to an empty field.

See The Bug Tracker (Trac) handbook article for more information.

Tickets brought up

  • @notnownikki has been working with @iseulde and @azaozz on #43187, which comes from an issue in Gutenberg.
  • @williampatton asked for feedback on #42057, specifically opinions on introducing an additional parameter for a function in a minor release, and more eyes on back compat to make sure nothing is broken by the change.

Thanks to everyone who attended! As always, please feel free to leave a comment below or reach out to any of the moderators (@adamsilverstein, @desrosj, @flixos90, @sergeybiryukov, @stevenkword, @welcher) with questions on Slack. Or, feel free to reach out to any core developer or component maintainer with questions specific to certain core areas.

#core, #new-contributors, #summary

Dev Chat Summary: February 14th (4.9.5 week 2)

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

4.9.5 planning

  • We’re looking for nominations for people to lead this minor release, self-nominations are very much welcome. Please reach out to @jbpaul17 (@jeffpaulon Slack) or comment on this post with nominations.
  • No timeline set for 4.9.5, but minor releases tend to run 6-8 weeks so we’ll go with what fits with the release leads’ schedule
  • Potential focus for 4.9.5 could be support of foundational work needed to support Gutenberg

Updates from focus leads and component maintainers

  • The PHP team shared a recap from their recent meeting, thanks again to them for documenting that discussion
  • The GDPR compliance team met earlier today, so if you missed the meeting but have interest in the topic you can follow along in the #gdpr-compliance channel.
  • The New Contributor meeting has resumed, thanks to @desrosj for getting that going again

“good-first-bug” claiming process

  • Topic primer from @drewapicture: Gardeners have (mostly) been updating patch-related keywords on `good-first-bug` tickets, but not assigning the tickets which is what actually moves a `good-first-bug` ticket from the unclaimed to the claimed list. I just went through and assigned maybe 40 tickets, which puts the unclaimed list at a much more realistic 4 tickets. It might be worth a discussion about whether we should change the “claiming” behavior to trigger off of adding the `has-patch` keyword vs being assigned. It’s one thing to ask people to just do what needs to be done in the current workflow, but that doesn’t seem to be working, so maybe the better option is to just change how it works so it can be more automagical.
  • Agreement that adding a patch equates to claiming a ticket, conceptually auto-claiming could work
  • Meta#3459 created to track this work

General announcements

Next meeting

The next meeting will take place on February 21, 2018 at 21:00 UTC / February 21, 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, #core, #dev-chat, #summary

Dev Chat Summary: January 17th (4.9.3 week 1)

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

4.9.2 release

  • 4.9.2 was released yesterday.
  • This is a security and maintenance release for all versions since WordPress 3.7. We strongly encourage you to update your sites immediately.

4.9.3 planning

  • Updated timeline is 4.9.3-beta1 on Tuesday, January 23rd; RC on Monday, January 29th; and still aim for Tuesday, January 30th for release.
  • Currently no major bugs, so planning for a regular maintenance release.
  • Bug scrub times will be announced on Make/Core.
  • 4.9.3 beta will get a Make/Core post to help get people's attention on it.

Updates from focus leads and component maintainers

  • The Editor team recently released Gutenberg v2.0 and will begin regular Gutenberg bug scrubs at 17:00 UTC on Thursdays separately from their weekly meeting. Please ping @jbpaul17 (@jeffpaul on Slack) if you have interest in assisting with bug scrubs.
  • The REST API team wants to get dev opinions on a register_meta change proposal that will becoming to a Make/Core post soon.

General announcements

  • @jorbin: Reminder that breaking changes (even if they are only breaking code that was publicly released for a few months) should always have a Dev Note published on Make/Core.
    • 4.8 and 4.9 had shorter beta/RC windows. It would be interesting to analyze and see how that affected bugs reported during those windows and in the near term after release. It would also be interesting to see how that affected the number of reverts. That data might show longer beta/RC windows are necessary, but we should not rush a decision without numbers backing up the analysis.
    • Note that @jbpaul17 added a step to check for dev notes to the Releasing Minor Versions handbook page.

Next meeting

The next meeting will take place on January 24, 2018 at 21:00 UTC / January 24, 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, #summary

Dev Chat Summary: January 10th (4.9.2 week 6)

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

4.9.2 planning

  • Tentative release timing of 1/16 for beta, 1/23 for RC, and 1/30 for release
  • 57 tickets currently on the milestone, @sergey will be reviewing them during a bug scrub on Friday (Jan 12th) at 19:00 UTC
  • Bug scrubs for future weeks will be scheduled around 19:00 UTC on Mondays, Wednesdays, and/or Fridays by @sergey and @desrosj

Updates from focus leads and component maintainers

  • Design team would like to check in with the other teams and see if anyone has projects they need designers for in the next couple months. If you have needs then please reach out in the #design channel.
  • REST API team would like to know if your work would be aided by API improvements or is blocked by API issues; if so, please come see them in #core-restapi.
  • Media and PHP teams have posted their meeting recaps from the past week for review.

Servehappy project

  • @schlessera: posted a Servehappy project overview
  • Our goal is to have a positive impact on PHP version distributions, to get a higher percentage of servers to run on supported PHP versions.
  • We have 3 main building blocks right now:
    • 1. information page about PHP, its versions, and upgrading them (see: draft)
    • 2. admin notices letting site owners know they run an old version
    • 3. plugin/theme requirements that prevent installation/updates when PHP version requirements are not met
  • @flixos90: Regarding #1, we have a Trac ticket in place. The page itself has two goals: Convince site owners that it's worth their time to take action, and then explain how they can proceed.
  • How and who do we approach to get it on wordpress.org infrastructure? Should it be hosted as an area inside .org or as a separate site with separate domain (if yes, which one)?
  • Plan to collaborate with Tide, in terms of preparing the PHP upgrade as users could check for their plugins and themes compatibility.
  • @stevenkword: We are also considering making the PHP Compatibility Checker plugin a consumer of Tide when it's production ready. Leveraging the cached results would really speed it up. We're pushing an update for 5.2 support this afternoon, and it will contain 7.1 and 7.2 checks
  • Anyone who's interested in helping out, please join our weekly meetings on Monday 16:00 UTC, and of course feel free to review what we currently have.

General announcements

  • @jorbin: I want to draw some early attention to a ticket that has the potential to impact all core contributions, especially related to JavaScript. Please take a read of #43055 and after reading it all, comment with any thoughts or concerns.
  • @audrasjb: when will we have a chance to know WP 5.0 delivery roadmap?
    • @jbpaul17: I’m not aware of any pending updates, so I’d suggest for now joining the conversation in #core-editor and helping with Gutenberg as any roadmap or timeline will come from the progress of development there.

Next meeting

The next meeting will take place on January 17, 2018 at 21:00 UTC / January 17, 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-2, #core, #dev-chat, #summary

PHP Meeting Recap – December 11th

This recap is a summary of this week’s PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

The meeting’s chat log.

Attendees: @afercia @clorith @drewapicture @drivingralle @flixos90 @jdgrimes @joostdevalk @jorbin @ottok @overclokk @paulstonier @pross @ptasker @spacedmonkey @vizkr

Chat Summary

The main agenda for this week was to review the copy the marketing team has been working on in regards to the “Before Upgrading PHP” document.

Here is the discussion summary:

  • As WordPress recommends a specific PHP version on the requirements page, it was decided that that same version should be used on the Servehappy page (currently 7.2). Vague version terminology like “PHP 7+” or similar should be replaced accordingly.
  • A few minor changes to the copy were suggested and added to the Google document as a comment.
  • The part about the backup not including the PHP version might need to be clarified, but on the other hand it might unnecessarily scare away site owners from proceeding. This is something that still needs to be figured out.
  • On a side note, the PHP Compatibility Checker plugin should make it easier to run the check after the installation. Currently there’s simply a submenu item added in the admin, but no link or anything to it, so the user has to search for it which is bad UX.
  • There was a discussion regarding the proposal in #42858, to bump the minimum version requirement in PHP 5.0 and make 4.9 some kind of LTS version. The gist of the discussion was that this would be a problematic move as it would leave deliberately leave users behind which is against WordPress’ principles. An eventual version bump should be announced well in advance, and there should be enough time to educate site owners on the topic and prepare them for the upgrade instead of forcing them to either upgrade immediately or be left behind. The Servehappy page should be a major contributor to that education, but before it is in place, no measures in regards to a minimum version bump should be taken. Once it is live, #40934 and #41191 will be the two main tickets that need to be worked on for core so that site owners can actually be made aware of the problem.

The rest of the meeting focused on a few organizational items:

  • Writing the weekly recap posts is an extra maintenance burden that may possibly not be worth the effort. A regular update would still be valuable though, so a good alternative would be to write a monthly update post or just an update post when something major was decided. If you have been reading these weekly recaps and find them particularly useful, please leave a comment on this post, otherwise the team will move over to writing decision-dependent update posts.
  • Once Servehappy is set in stone, one of the next major goals of the initiative will be to discuss and come up with more patterns and standards in core, in order to at least in the future prevent rather random decisions by individual developers, causing an inconsistent codebase. As of now however, Servehappy is the sole priority.

Next week’s meeting

The next meeting will take place on December 18th, 2017, 16:00 UTC as always in #core-php. The agenda will be to plan spreading the word more, particularly by asking for more feedback in the weekly development chat. If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account. See you next week!

#core-php, #php, #summary

New Features and Enhancements with Customizer Changesets in 4.9

In WordPress 4.7 the concept of changesets was introduced in the Customizer (#30937). To understand the new Customizer improvements in 4.9, you must first go back and review what was proposed and implemented a year ago:

Customize Changesets Technical Design Decisions

Changesets are a way to persistently store changes made via the Customizer framework. Changesets contain the pending changes for any number of settings, and a setting can model any object in WordPress—whether options, theme mods, nav menu items, widgets, or even posts/pages and their postmeta. Changesets are identified by UUID (which is the post_name for the customize_changeset post type that stores the data as JSON in post_content). When a request is made to WordPress with the customize_changeset_uuid request param—whether to the frontend or to the REST API—the Customizer framework will bootstrap and all of the values from the changeset will be read and applied to the response via WordPress filters added by the settings’ respective WP_Customize_Setting::preview() methods.

Only an authorized user can write changes into a changeset for a given setting (according to its respective capability). But once it has been written then anyone can preview the site with the changes in the changeset applied: all that is needed is the UUID. Since previewing a changeset is now a readonly operation (whereas before 4.7 it was always a POST request), a changeset can be previewed on a site by authenticated and unauthenticated users alike. With the changeset UUID supplied when opening the Customizer, a user can keep iterating on a set of changes over several days or longer and only publish them once stakeholders are satisfied. Now, freelancers and agencies will be better able to communicate and collaborate on site changes with clients.

Once a customize_changeset post transitions to the publish status then all of the values in the changeset will be passed into their respective WP_Customize_Setting::update() methods to publish (“go live”) on the site: in version control terminology, the staged values from the changeset get committed and pushed. All of the changes go live together in a batch save operation (originally changesets were termed “transactions”).

As noted in the 4.7 merge proposal:

For the initial core merge, no UI changes are being proposed. The feature will only be exposed as the new query parameter on the URL. Adding a UI to this feature will happen in a future release.

The future [release] is now. Where the infrastructure of changesets was merged from the Customize Changesets feature plugin in 4.7, the key UI features from the plugin are now being merged in 4.9 after a significant number of design iterations.

This dev note contains sections on the following:

Continue reading

#4-9, #customize, #dev-notes

Dev Chat Summary: August 23rd (4.9 week 4)

This post summarizes the dev chat meeting from August 23rd (agendaSlack archive).

Review 4.9-early tickets

  • Items in Trac all seem to need owners, especially since they were all tagged 4.8-early as well
  • Should also include work on CodeMirror which needs more testing and contributions
    • Can currently be downloaded from the latest tagged release
    • Feedback is best on GitHub Issues for now, until the plugin is merged
    • Will work to get it into the w.org repo for easier installation
  • #39693 could use a review from another committer

Gutenberg testing

  • Gutenberg just released v0.9.0 and if you haven’t tested in a while this would be a good release to get into testing and provide feedback
  • Development is progressing and feedback is really important
  • Two tests are described in the handbook, you can also give your feedback via the plugin forum

Future support for ancient versions of WordPress

  • Discussion started previously in #core
  • @jorbin: is it time for us to stop backporting so far? Does anyone object? If not, Does anyone have ideas for how to go about it, or suggestions for me to put together a proposal on it?
  • @joemcgill: I would like to see a published proposal outlining reasons, usage data, and any tradeoffs/considerations and leave a bit of time for feedback before definitely doing this.
  • W.org Stats shows 3.7 is about 0.4%
  • @mikeschroder: We chatted about this at the summit, and about enabling protections for upgrades for major versions like we do for minor ones.
  • @ocean90: We should start with 3.7.z to 3.8.z. Note that this is already a huge step because 3.8 includes the new admin design.
  • @jorbin: I will work on the proposal. I’ll ping some of the committers and other active contributors who have contributed to this conversation to review it before publishing.

General announcements

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

Revised suggested roadmap for Gutenberg and Customization

Gutenberg is about to reach a milestone of having the technical and design vision in place. I know that we’re a little off from the existing roadmap, so I’d like to suggest an update to the milestones going forward.

The milestones below are based on information from the focus leads about who will be available and when. As with all things in open source, these are best guesses and I encourage everyone to join us in being flexible as we keep creating:

  • Aug 2017 (late): Technical and design vision complete, iteration begins. This is in progress.
  • Aug 2017 (late): Testing plan begins: this will start with a public meeting.
  • Aug 2017 (late): Promotional page goes live for Gutenberg. This is in progress.
  • Sep 2017: Potential *.1 release with banner to encourage use of and feedback for Gutenberg
  • Nov 2017: 4.9 release
  • Dec 2017: Begin merge proposal for Gutenberg
  • Jan 2018: Gutenberg —> Customizer crossover (switching the focus)

It should be clear this is not set in stone. Gutenberg is not ready to merge and as a result giving it this time is important to iterate and respond to feedback. Beyond the merge proposal it’s also difficult to predict, so the roadmap to 5.0 isn’t being predicted here, that will depend on the proposal.

#gutenberg