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-2, #4-9-3, #core, #core-editor, #core-restapi, #dev-chat, #gutenberg, #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, #core-media, #core-php, #core-restapi, #design, #dev-chat, #servehappy, #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, #core-editor, #core-restapi, #dev-chat, #gutenberg, #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

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

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

4.8.1 release feedback

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

4.9 goals

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

General announcements

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

New Contributors Meeting Recap – August 2nd

Yesterday, the new weekly 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 @asalce @azerial @chetan200891 @circlecube @clorith @desrosj @dipeshkakadiya @dnavarrojr @e_baker @helen @jdmensing @johnbillion @jorbin @josiahsprague @joyously @kelseyfecho @linsoftware @luckyankit @milindmore22 @mte90 @nabil_kadimi @proscriptsell @punit5658 @stevenkword @t-rave @welcher @zakkath

Discussion Highlights

Before Creating Tickets

  • Before creating a ticket, there are a few things you should do:
    • Ensure you are running the latest version of WordPress (if reporting a bug).
    • Search Trac to make sure a ticket for your bug or enhancement.
  • Creating a duplicate ticket is ok, as long as you did your best to find a pre-existing ticket.

Writing a Title

  • A good ticket title should accurately summarize the problem the ticket addresses.
  • Someone should be able to see the title and get the general idea of what the ticket is trying to solve, not the solution.

Writing a Description

  • A ticket description should include:
    • A description of the behavior you expect and why
    • A description of the behavior you are seeing
    • Steps to reproduce the behavior so other contributors can see it for themselves and track down the source.
    • If an enhancement ticket, describe what it improves upon and why this is beneficial.
  • If it involves something else (like a specific browser, or server type), make sure to detail that as well.
  • If applicable, screenshots are also very helpful.
    • Screenshots are best uploaded directly to Trac. This prevents images from becoming dead links when removed from external image sources.
  • Always try to focus on the problems being solved, even if it’s an enhancement, you are trying to solve a problem of some sort.

Examples of tickets with good titles and descriptions: #41525, #37013.

What is the difference between Core and Meta Trac?

Core Trac is meant for tickets relating to the WordPress software you install and run (including unit tests). Meta Trac is meant for a bunch of other things, but mainly things that are WordPress.org related. There is a full list at the top of the Meta Trac home page.

Security Vulnerabilities

It is very important that any issues with security implications be reported through responsible disclosure privately. For more information on reporting security vulnerabilities, see the WordPress Handbook.

What is considered “enough testing”?

  • This will vary based on the ticket and what problem is being solved.
  • Testing may span multiple releases for complex problems.
  • It also is up to the committer that chooses to take ownership of the ticket. They need to be completely comfortable with the change, and confident that there is little to no potential for issues.
  • Once committed, the testing does not end. Testing continues by using trunk.
  • After that, the alpha, beta, and RC releases are in place to catch anything that might have been missed.

Is there a protocol for old tickets that have become stagnant?

  • Check that the problem or enhancement in the ticket is still relevant.
  • Test any patches on the ticket to ensure they still apply cleanly.
  • Test that the patch still solves the issue.
  • Add the needs-refresh tag if not.
  • Stagnant tickets can be frustrating, but remember, no one is purposefully ignoring your efforts. Most (if not all) of the folks here are volunteers working in their free time.

Tickets discussed

  • #39535 – Canonical redirects disallow tag named comments
  • #37057 – Creation of an esc_html functions for _n(), _nx(), _ex(), and number_format_i18n()
  • #41521 – Menu list with dropdown icon alignment bug in responsive.
  • #41497 – Menu has style problem in listing on admin menu page

Next Week’s Meeting

The next meeting will take place in the #core slack channel on Wednesday, August 9, 19:00 UTC. Please feel free to drop in with any questions or tickets you’d like to discuss!

Thanks to everyone that attended! As always, please feel free to leave a comment below or reach out to any of the moderators (@adamsilverstein, @desrosj, @stevenkword, @welcher) with questions on Slack.

#new-contributors, #summary

Dev Chat Summary: August 2nd (4.9 week 1)

This post summarizes the dev chat meeting from August 2nd (agendaSlack archive).

4.8.1 RC2 feedback & planned release post-devchat

  • 4.8.1 includes fixes for the text widget, delayed yesterday due to performance issues identified
  • 4.8.1RC2 on WordPress.com stable, no longer experiencing the performance issues
  • No noticeable feedback in the forums regarding the text widget changes, Trac has been quiet in the widgets component
  • #41373 reported against 4.8, doesn’t seem to be a new regression introduced by 4.8.1 or a blocker
  • No concerns with the plan to release 4.8.1 after devchat

4.9 kickoff

  • 4.9 release schedule page is available, with particular highlights:
    • WordPress 4.9 will be the second “major” release of 2017 with the theme of editing code, managing plugins and themes, a user-centric way to customize a site, and polishing some recently added features over this last year.
    • October 4, 2017 is Beta 1 and feature project merge deadline.
    • October 30, 2017 is Release candidate and soft string freeze.
    • November 14, 2017 is 🎶 Target date for release of WordPress 4.9. 🎶
    • @melchoyce and @westonruter are co-Release Leads. 🎉
  • Updated set of goals for the 4.9 release and updates to the stale Customize component page coming soon (but first, release 4.8.1)

Editor / Gutenberg updates

Call for Component Maintainers

  • @drewapicture completed annual audit of Component Maintainers, some areas where new maintainers could be useful
  • The list on Make/Core reflects the most current list of maintainers
  • Please reach out if you’re interested in becoming a component maintainer

General announcements

  • @jorbin: submissions open for Kim Parsell Memorial Scholarship for WordCamp US
    • WordPress Foundation gives out a scholarship that covers the cost of hotel, transportation and a ticket for WordCamp US
    • Must be: person who self-identifies as female, active contributor to WordPress via a contributor team or a local meetup or WordCamp organizer, has financial need, and has never attended WordCamp US
    • No age limit on this scholarship, though older women are especially encouraged to apply
    • If you fit the requirements, please apply. If you know someone that qualifies, please encourage them to apply.

#4-8, #4-8-1, #4-9, #components, #core-editor, #core-restapi, #dev-chat, #gutenberg, #maintainership, #summary, #wordcamp

Dev Chat Summary: June 21st (4.8.1 week 1)

This post summarizes the dev chat meeting from June 21st (agendaSlack archive).

4.9 ideas and brainstorm

  • No immediate 4.9 timeframe, but the planned timing for 4.9 will come shortly after we confirm the major focuses of 4.9 and will be closer to 3 months than 9 months in duration
  • @jorbin: Scheduled customizer changesets going live could be a big win
  • @westonruter: adding statuses for changesets: being able to draft a changeset to come back to later, and then to be able to schedule it to go live.
  • @youknowriad: We have some REST API needs in Gutenberg:
    • Retrieving The permalink using the API (making more things available from wp-json/wp/v2/settings)
    • An API endpoint to save/get random settings (we’d use it to save some layout options)
  • @androb: Expanding link boundary behavior in TinyMCE to other inline elements
  • @androb: TinyMCE has a new mobile-optimized UX that will also result in a responsive toolbar, this should land in the 4.9 time frame
  • @androd: tweak the TinyMCE UI to be closer to Gutenberg (e.g. toolbar color, default font) to get users used to the Gutenberg UI before releasing that in WordPress 5.0
  • @saracannon: look at customizer revisions in a way that we might want to look at Gutenberg revisions in the future from a visual standpoint and start making progress there (@melchoyce: see mockup for customizer revisions on #21666)
  • @melchoyce: code editing improvements across core — CSS editing, the plugin/theme code editor, etc. Making it better to use and harder to mess up and break your site (see #31779)
    • @clorith: As soon as we do this, we need to handle the issue of lacking forked plugins, lacking child theming etc
    • @westonruter: add a warning to encourage people to be aware of the dangers of editing code without version control (see #41078)
  • @melchoyce: evisions for everything – Customizer revisions, page/post revisions, code editor revisions…
  • @hugobaeta: reduce the amount of declared colors (namely shades of gray) in the admin, more info on codepen and a little backstory on this flash talk at WCUS last year
  • @melchoyce: some in-progress tickets for improving theme switching: #39692, #39693
  • @melchoyce: also Customizer menu improvement – #40104
  • @melchoyce: automated testing in place for theme switching (@netweb to work on this)
  • @melchoyce: making “page on front” less confusing (again)
    • @westonruter: harmonizing with menus and page hierarchies. Merging those concepts together
  • @melchoyce: finish the gallery widget (@m1tk00 to work on this)

4.8.1 agenda

  • @westonruter: resolve text widget removing code issue (see #40951) alongside implementing HTML code widget (see #40907), three options proposed, one recommended
  • a11y bug-scrub will happen next Monday, will focus on 4.8.1 milestoned tickets
  • approaching 4.8.1 tickets as more traditional regression types of issues
  • Tentative timeline for 4.8.1 last week of July

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