PHP Meeting Recap – July 23th

This recap is a summary of our previous 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.

You can find this meeting’s chat log here.

Chat Summary

Update PHP Page

We first discussed the “Update PHP” page content/layout.

@AlexDenning confirmed that work is being done on the page by @Jayman and him. He’ll send updates as they happen.

WSOD Protection

We then moved on to discuss progress on #44458 – Catch WSODs and provide a means for recovery for end users.

  • We collected thoughts about reframing the project from “Servehappy” to “Health Check Project”. This led to a lot of questions about what further changes this would allow that wouldn’t be covered by the “Servehappy” name. We could come up with a few examples, like:
    • helping people update their plugins & themes
    • keeping Core up-to-date
    • keeping MySQL up-to-date
    • organizing “Update Bars” at WordCamps & meetups
  • Then we discussed timing and whether we’re on track for 5.0. Basically, our changes can be merged/backported as soon as possible with the caveat that the following requirements need to be met first:
    • the “Update PHP” page needs to be reworked
    • the WSOD protection needs to be in place
  • We discussed the types of errors that the WSOD protection catches. The current proof-of-concept only catches PHP parse errors, but we can certainly catch other types of errors, provided we know without fail how to deal with them. @schlessera will set up a document to examine the possible errors and determine which ones to catch.
    We cannot simply catch all fatals unconditionally, as we wouldn’t know what to filter from load to make the site work again.
  • @flixos90 has created tickets to port the “Requires PHP:” header tag to themes: #44592 & #meta3718.

Post-Meeting

Link to the document discussing the different types of PHP errors to catch: https://www.notion.so/brightnucleus/WP-Sandbox-88738b62e9e947a7aeb8271d958a5497

Next week’s meeting

  • Next meeting will take place on Monday, July 30th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion on the avoiding WSODs in PHP.
  • 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.

#core-php, #meta3718, #php, #servehappy, #summary

PHP Meeting Recap – June 25th

This recap is a summary of our previous 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.

You can find this meeting’s chat log here.

Chat Summary

  • We first discussed terminology: are we talking about “PHP upgrades” or “PHP updates“? We are currently mixing both of these in a rather random fashion. We then decided that we’ll stick to “PHP updates” and “updating PHP” from now on, because:
    • The distinction between “update” and “upgrade” is lost on most users anyway, so we should only use one in user communication.
    • “Upgrade” implies an improvement. An “update” means getting it to the latest state. While it will provide improvements, doing an “update” is actually what we’re after, even if no improvements are to be had.
    • “Update” better fits with the rest of WP communication as well.
  • The following changes will be made to make all project deliverables consistent with the above decision:
    • Patches in #43986, #43987 and #44350 will be changed to only refer to “updates”.
    • The core capability upgrade_php will be renamed into update_php.
    • The support page will be renamed from Upgrading PHP to Updating PHP, and the page’s content will be adapted accordingly.
    • The support page’s URL will be changed to https://wordpress.org/support/upgrade-php/ to https://wordpress.org/support/update-php/.
    • A redirect will be done from https://wordpress.org/support/upgrade-php/ to https://wordpress.org/support/update-php/.
  • Then we quickly discussed the #design <=> #marketing collaboration with @jaymanpandya and @alexdenning. They have already made contact and will keep us updated on their collaboration progress.
  • Finally, we discussed our new goal of “sandboxing” the plugin/theme’s PHP code in some way to make sure users cannot be locked out of their site through a white-screen-of-death (WSOD).
  • Current observations:
    • Exceptions don’t help, as they are not fully integrated into the error handling at PHP 5.2.
    • We can use a shutdown handler to detect fatal errors and know where they were triggered: https://3v4l.org/4jWAs .
    • Such a shutdown handler could record a fatal error, and the next page request could then detect a recorded fatal error and decide based on some heuristics whether to initiate “safe mode”
    • We cannot just act on plugin activation/deactivation, as this will still take the site down if we update PHP.
    • We cannot disable a single plugin, as we cannot reliably detect who the actual culprit is in all cases.
    • We might be able to disable a single plugin in those cases where we hit a parse error in a file of a plugin.
  • A Trac ticket was created for this: #44458 – Catch WSODs and provide a means for recovery for end users

Next week’s meeting

  • Next meeting will take place on Monday, July 2nd, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion on the avoiding WSODs in PHP.
  • 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.

#core-php, #php, #servehappy

Dev Chat Summary: June 13th (4.9.7 week 4)

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

4.9.7 planning

Updates from focus leads and component maintainers

  • The PHP team posted summaries from their last two meetings covering progress and decisions on #43986 and #44350 as well as the approach for #43987. Join them next week on Monday, June 18th at 15:00 UTC in #core-php as they continue the discussion on these two tickets.
  • The REST API team would like a core committer’s review on #38323, so if you’ve got some time then please help out there.
  • And a reminder for those heading to WCEU that Contributor Day is tomorrow, Thursday, June 14th. If you’re in town, then please consider attending… thanks!
  • No design lead for Customize focus while @melchoyce is on sabbatical until September 10th

Devchat coordination

  • @jeffpaul will be offline most of July, so we’ll need someone to help coordinate/run devchats.
  • If you’re open to collecting agenda items and publishing an agenda, running the actual devchat meeting, and/or publishing a devchat summary then please comment here or ping @jeffpaul if you’re able to help out… thanks!

Next meeting

The next meeting will take place on June 20, 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-7, #core, #core-customize, #core-restapi, #dev-chat, #summary

PHP Meeting Recap – June 11th

This recap is a summary of our last 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.

You can find this meeting’s chat log here.

Chat Summary

  • A final decision on both the design and the copy for preventing installation of incompatible plugins was made (see #43986).
  • It was agreed to use a mock-up presented by @melchoyce outside of the regular chat at the end of last week. It displays the notice on top of the plugin card, thus addresses the concerns about the notice being too far away from the disabled button and about currently present information being hidden by the notice.
  • For the copy, it was decided to go with the following, for the three possible circumstances:

    This plugin doesn’t work with your version of WordPress. [Please update WordPress].

    This plugin doesn’t work with your version of PHP. [Learn more about updating PHP].

    This plugin doesn’t work with your versions of WordPress and PHP. [Please update WordPress], and then [learn more about updating PHP].

  • @afragen already created an updated patch that implements the above. The patch needs to be thoroughly reviewed and can hopefully be committed some time next week. Here is a screenshot of what the final result will look like:

Plugin Card Incompatible Notice

  • In the second half of the meeting, discussion started about how to approach preventing plugin updates in case of incompatible PHP or WordPress versions (see #43987).
  • It was decided that, in the plugins list table, each row with an incompatible version should show a notice almost like it currently does for a regular plugin update. However, the notice should use the error color instead of the warning color, and also show an error icon.
  • A challenge with the copy in that notice is that it also needs to include a link to view details of the new version. A first draft was suggested, following closely what has been decided on for the plugin installations (see above). Here is the current state of the copy, again for the three possible circumstances:

    There is a new version of %1$s available, but it doesn’t work with your version of WordPress. [Please update WordPress], or [view version %2$s details].

    There is a new version of %1$s available, but it doesn’t work with your version of PHP. [Learn more about updating PHP], or [view version %2$s details].

    There is a new version of %1$s available, but it doesn’t work with your versions of WordPress and PHP. [Please update WordPress], and then [learn more about updating PHP]. You can also [view version %2$s details].

  • It was remarked that plugins with a WordPress version that is incompatible are not made available already. This possibly means that it will only be necessary to implement notices and restrictions specific to the PHP version, however no decision has been made on that yet.
  • At the time of the meeting, the patch on #43987 also included adjustments for the general “Updates” admin screen, preventing plugin updates from there as necessary. To narrow down the scope of the ticket and make the discussions more straightforward, it was decided to implement that part in a separate ticket. #44350 was then opened for that purpose.

Next week’s meeting

  • Next meeting will take place on Monday, June 18, 2018 at 15:00 UTC in #core-php.
  • Agenda: Check whether there are any blockers that have come up with #43986, and otherwise focus on continuing the discussion about #43987.
  • 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.

#core-php, #php, #summary

Dev Chat Summary: June 6th (4.9.7 week 3)

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

4.9.7 planning

  • Leads nominated so far: @sergeybiryukov able to help as deputy (e.g., committing, backporting); @danieltj, @desrosj, @tristangemus, @pbiron open to help contribute during 4.9.7
  • Waiting until after WCEU to confirm release leads and any potential focus for 4.9.7
  • Aiming to get someone who hasn’t lead a recent release and (who has prior experience contributing or has institutional backing to contribute to a release) to be nominated to lead or co-lead 4.9.7. Pairing that with assuming we’d get a more precise focus for 4.9.7 would mean we’d try and confirm leads in ~two weeks.
  • Working to communicate with other team reps and component maintainers to increase diversity in release leads by asking for nominations or suggestions in their next meeting/update, please share any ideas you have on this… thanks!

Updates from focus leads and component maintainers

WCEU preparation

  • Asking everyone to keep their eyes out for tickets that would be worth tackling at WCEU Contributor Day, please add good-first-bug keyword in Trac
  • Also looking for issues that need testing as that can provide another option for introduction to contributing
  • Code reviewing Gutenberg PRs, even just parts of PRs, could be a good chance for folks to wade into contributing
  • When reviewing a PR or Trac ticket, even leaving a comment like “I don’t understand what’s happening here, can you add documentation?” would be tremendously valuable
  • If there are patches that need refreshing, those can be useful to new contributors (if the refresh is easy) because it familiarizes them with the workflow of creating/submitting patches
  • Fixing coding standards issues are another good option for new contributors to learn coding standards while fixing them
  • Contact @flixos90 or @antpb if you have more pressing tickets that should be worked on during WCEU
  • Reminder to document any discussions about big changes (such as to coding standards) in a Make/Core post to share with everyone as not everyone can travel to WCEU

General announcements

  • @jeffpaul will be offline most of July, so we’ll need someone to help coordinate/run devchats. Please comment here or ping @jeffpaul if you’re able to help out… thanks!

Next meeting

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

PHP Meeting Recap – June 4th

This recap is a summary of our last 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.

You can find this meeting’s chat log here.

Chat Summary

  • The recap continued the discussion from last week (read the recap) about how to prevent plugin installations from happening if the plugin requires a WordPress or PHP version that is not met by the environment (see #43986 for the related ticket).
  • First it was discussed how to display the notice to inform the user of the version requirement not being met. @melchoyce had presented several design approaches for it, with the aftermath of last week’s meeting highlighting a mockup that replaces the bottom section of the plugin card with the red notice.

Plugin search result: "Incompatible plugin" error

  • The majority of voices during the meeting voted for using the above design, mostly for its clear highlighting and available space. Concerns were expressed about not showing specific PHP versions and, more specifically, about hiding the stats about ratings and active installations. The latter are completely unrelated, so the above mockup may need to be adjusted to include the stats as they are displayed on regular plugin cards at this point. This will need to be re-evaluated in the next meeting.
  • The other point discussed were the copy to use for the notice, including a link to show to solve the problem. The following copy was agreed on for the two respective issues:

    Incompatible with your version of WordPress. Please update WordPress (link to update WordPress).

    Incompatible with your version of PHP. Learn more about updating PHP (link to the Upgrading PHP page).

  • The above copy is brief and on point, and contains a clearly-described link as a call-to-action, being much more accurate than the previous “Why” links. It was decided to not include specific WordPress or PHP versions in this notice because these version numbers are more technical and would be unnecessary information for most users. Only the “More Details” modal should provide them. The copy was agreed on to use during the meeting, however with a concern being expressed later about the strict tone resulting of the short length of the structurally incomplete sentence. The following alternative was suggested:

    You can’t install this plugin because it doesn’t work with your version of WordPress. Please update WordPress (link to update WordPress).

    You can’t install this plugin because it doesn’t work with your version of PHP. Learn more about updating PHP (link to the Upgrading PHP page).

  • It was agreed that this copy sounds better, but it would need to be figured out how to fit it into the small space available. Alternatively, the longer variant could only be used for the notices displayed in the More Details modal. On the other hand, that would make visibility of these seemingly friendlier notices much lower. The copy can likely be finalized in next week’s meeting.
  • A problem that was not clearly handled yet is what should happen if both the WordPress and PHP versions are insufficient. In that case, either both sentences could show, increasing the required space further and possibly looking strange due to a single notice showing content that looks like two actual notices. On the “More Details” modal this is not a problem, but it may need a solution on the plugin cards.
  • An alternative was suggested to, at least on the plugin card, always only mention one of the two problems, even if both occur. While none of the participants were really satisfied with that approach, they agreed that in such a case the WordPress version issue should take precedence because it is most likely much easier to fix. The discussion on how to deal with both issues occurring simultaneously should be continued once it is clear how to display the notice and what content to use. It may very well be solved in that process as it needs to be considered for both decisions.

While the preliminary decisions made during the meeting are certainly not final, @afragen implemented the state after the meeting in an updated patch and provided screenshots for it on the ticket, which can help a lot in evaluating the possible approaches in the upcoming meetings.

Next week’s meeting

  • Next meeting will take place on Monday, June 11, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion on how to display the notice, with particular attention to maintaining the information currently present on the plugin card and accounting for the possibility of both versions being insufficient. The concrete copy to use should only be discussed if there is enough time left at the end.
  • 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.

#core-php, #php, #summary

PHP Meeting Recap – May 28th

This recap is a summary of our previous 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.

You can find this meeting’s chat log here.

Chat Summary

  • We started with discussing Trac ticket #43986 – Disable “Install Plugin” button for PHP required version mismatch and the currently posted patches. An immediate goal was to distill the different approaches we’ve been exploring so that the #design team can give specific feedback on these approaches, instead of only asking for general and vague “feedback”.
  • Questions we’ve distilled for that ticket:
    • Where does compatibility breakdown go: 1. under install button, 2. in bottom panel, 3. hidden away under “More Details” modal
    • Whether to show compatible/not-compatible state, or only show non-compatible state and stay quiet for compatible state
    • Whether to use (colorized) icons or not
    • Whether to show current/required version numbers or not
    • If both PHP and WordPress version are insufficient: 1. show both, 2. show only WordPress (easier to fix), 3. show only PHP (more problematic)
  • Both @afragen & @SergeyBiryukov had provided similar patches, which differed in their general approach of how to integrate into existing Core behavior: while @afragen added actions to make the new blocking functionality extensible, @SergeyBiryukov opted to hardcode the integration into the existing Core flow instead.
    After some deliberation, we decided to go with the hardcoded approach, to avoid introducing new actions (that are not needed for now) that would entail additional documentation, maintenance and backward compatibility effort.
  • @SergeyBiryukov stated that we could target 4.9.7 for this if we manage to get it ready soon.

Post-Meeting Updates

  • We agreed that, although we could filter out incompatible plugins, we prefer to show them with a disabled “Install” button, as this provides the incentive we need to encourage people to upgrade.
  • The #design team discussed the #43986 Trac ticket and provided some feedback. Mainly, the bottom area should be cleared and used completely for providing meaningful feedback if an “Install” action is being blocked.
  • @MelChoyce collaborated with @afragen directly to produce a new version of the patch that matches this #design feedback. This seems to be the screenshot that reflects the current state of the patch best:Plugin search result: "Incompatible plugin" error

Next week’s meeting

  • Next meeting will take place on Monday, June 4th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue work on the “Disable Install button” patch.
  • 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.

#core-php, #php, #servehappy, #summary

Dev Chat Summary: May 30th (4.9.7 week 2)

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

4.9.7 planning

  • No pressing need for quick 4.9.7 release, so aiming for ~6-8 week release cycle for 4.9.7
  • Leads nominated so far: @sergeybiryukov able to help as deputy (e.g., committing, backporting); @danieltj, @desrosj, and @tristangemus open to help contribute during 4.9.7
  • Please comment on this post, ping @jeffpaul, or comment during the next dev chat for nominations (self or otherwise) for release leads on 4.9.7

Updates from focus leads and component maintainers

  • The PHP team posted a summary from their meeting last week covering the “Upgrade PHP” page and possible Gutenberg blocks. Please join them this coming Monday, June 4th at 15:00 UTC in #core-php
  • The GDPR Compliance team met earlier today and of note will be changing the Slack channel and post tags to Core Privacy this Friday, June 1st. Please join them next Wednesday, June 6th at 15:00 UTC in #core-privacy

Guidelines for fixing coding standard violations

  • Now that r42343 has landed, Core is accepting patches to fix coding standards (CS) violations. The meeting attendees agreed on the following guidelines:
    • Patches for any CS fixes are welcome, as long as they’re not so extensive that it would require refreshing an unreasonable amount of regular patches.
    • In order to avoid wasting time, patches for violations which cannot be automatically fixed by `phpcbf` should be given preference over ones that can be automatically fixed.
    • Regardless of many files are touched in a CS patch, the corresponding commits should be limited to fixing a single file in each commit.
    • CS patches should be treated just like any other patch, and reviewed critically before being committed. That also applies to any changes made by `phpcbf`.
    • Commits for new features, bug fixes, and other “logic” changes should not include unrelated CS fixes. Coding standards fixes should be done in a separate commit. If a line is already being changed to fix a bug, etc, then it should have CS violations fixed at the same time. If fixing the violation for that line would introduce changes beyond that line, though, then the CS fixes should be done in a separate commit.
  • Does anyone strongly object to those, before they’re added to Handbook?

General announcements

Next meeting

The next meeting will take place on June 6, 2018 at 20:00 UTC / June 6, 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-7, #core, #core-php, #core-privacy, #dev-chat, #gdpr-compliance, #summary, #wpcs

Dev Chat Summary: May 23rd (4.9.7 week 1)

This post summarizes the dev chat meeting from May 23rd (agenda, Slack archive).

4.9.6 feedback

  • 4.9.6 was released on Thursday, May 17th thanks to the leadership from @desrosj and @allendav, heavy assists from @sergeybiryukov, @azaozz, and everyone over in #gdpr-compliance 🎉
  • Important developer and site owner topics included in 4.9.6 (New PHP Polyfills and Changes that Affect Theme Authors) all included within the 4.9.6 Update Guide
  • Auto updates were initially left off for 4.9.6 for about one day to evaluate incoming support requests and make sure there were no issues with the more than “normal” amount of code introduced
  • Initially some reports of users seeing a white screen on their sites, tracked to a small handful of plugins that were hooking into one of the new Privacy features using `init` instead of `admin_init`, and this was causing a very edgy edge case on some installs (see #44142)
  • Thus, auto updates have remained off for 4.9.6 to avoid more potential issues, documentation in the Plugin Handbook was updated with a notice describing that using `init` would potentially introduce problems on sites, and @ipstenu reached out to each plugin that was using this hook to inform them of the issue
  • Currently no plugins in the .org directory that implement the new privacy features incorrectly
  • As of devchat, auto updates have not been enabled and we need to plan when 4.9.7 should be released, and what it should contain
  • @matt reiterated that we’re going to put enhancements, new features, notices, and anything else we need into 4.9.x while we work on Gutenberg
  • Discussion on enabling auto-updates lead to agreement to do so; note that @pento enabled auto-updates ~4 hours after devchat

4.9.7 planning

  • Potential focuses: GDPR fixes, TinyMCE update
  • Leads: @sergeybiryukov able to help as deputy (e.g., committing, backporting); @danieltj, @desrosj, and @tristangemus open to help contribute during 4.9.7
  • Please comment on this post, ping @jeffpaul, or comment during the next dev chat for nominations (self or otherwise) for release leads on 4.9.7

Updates from focus leads and component maintainers

  • The Gutenberg team continues to iterate and shipped v2.9 on Friday, May 18th; check the release post for more details
  • The PHP team posted a summary from their meeting last week and welcome everyone to join their next meeting on Monday at 15:00 UTC when they’ll discuss whether there’s updates on the “Upgrade PHP” design review and discuss “Requires PHP” enforcement details

General announcements

  • @clorith: When making changes to twenty-themes we should note somewhere that we made changes to them in a release. Not everyone was happy about a theme update in 4.9.6 as well that added output to their footers. (related #44202)
  • @danieltj has also begun a proposal draft for Dark Mode on GitHub and is open to help, so please review if you’re interested/available

Next meeting

The next meeting will take place on May 30, 2018 at 20:00 UTC / May 30, 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, #4-9-7, #core, #core-php, #core-themes, #dev-chat, #gdpr-compliance, #gutenberg, #summary, #tinymce

PHP Meeting Recap – May 21st

This recap is a summary of our previous 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.

You can find this meeting’s chat log here.

Chat Summary

  • The initial half of the chat dealt with the design of the “Upgrade PHP” page:
    • The design team had suggested improving overview of the page structure using either an accordion or a list of headings as a table of contents at the top of the page.
    • It was decided that the ToC (table of contents) functionality provided by the Handbook plugin would be a perfect fit. @clorith outlined that the HelpHub project (which is the upcoming new WordPress support platform) has this plugin included. With the target release set to the end of May, it is perfectly fine to wait that remaining time until we can enable it for the page. Gutenberg will also be enabled on the support platform by that date.
    • @flixos90 noted that the line lengths of the current version of the page are very long, making it difficult to read. @schlessera quickly changed the layout of the page by changing the page template, so that this problem could be solved immediately.
  • The rest of the discussion revolved around possible Gutenberg blocks to implement for dynamic and more targeted content on the page.
    • All Gutenberg blocks for dynamic content should be based on a GET parameter php_version being passed. If none is passed, either the respective blocks should not appear, or, where it makes sense, a fallback PHP version could be used.
    • Participants agreed on implementing a block that would be used as a dynamic header for the page, providing a prominent message such as “Your PHP version x.x is supported/outdated/insecure.”, based on the php_version passed. This block would not appear without the GET parameter present.
    • It was also agreed to introduce one dynamic section as a block, which would show different copy based on the php_version passed. The content of each of the three variants (supported/outdated/insecure) should be fully editable through the block editing interface so that it can be easily translated. Without the GET parameter, this block would not appear.
    • @joyously suggested enhancing the page content with a chart for more visual context. It was determined that a timeline of PHP versions and the current position of the user’s PHP version in it would be a solid approach. Without the php_version GET parameter present, this block would still appear, just without the current version’s position highlighted.
  • @afragen asked for feedback on his work with #43986 and #43987, which is something we should focus on very soon.

Next week’s meeting

  • Next meeting will take place on Monday, May 28, 2018 at 15:00 UTC in #core-php.
  • Agenda: Review whether there are new ideas for the content of the Upgrade PHP page, and discuss the approaches of @afragen‘s patch and how to proceed.
  • 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.

#core-php, #php, #summary