PHP Meeting Recap – December 3rd

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

  • @drewapicture announced that he’d start working on a proposal to add modern PHP best practices to the core handbook at WCUS contributor day.
  • The discussion about feature flags from the previous week was picked up again, particularly regarding the trade-offs of relying on a (network) option vs relying on a constant or environment variable.
    • Since some of the processes to be tested are executed very early in the WordPress bootstrap process, a variable that can be set in wp-config.php or earlier should be used. There possibly could be a wrapper function to access that value, including a filter that would allow adjusting the constant value dynamically by code that would run later.
    • WP-CLI could also be used to “more dynamically” set the constants.
    • It was mostly agreed that the Beta Tester plugin should somehow incorporate the feature flags functionality, in favor of core, at least initially.
    • Eventually, it was summarized that the topic should get picked up again later, as the WSOD protection mechanism (see #44458) is not blocked by this and should move forward.
  • Further conversations on the current state of the project will happen at WCUS, with the results being published in a recap. The meeting on December 10th is cancelled because of WCUS and related travel.

Post-WCUS Update

  • As mentioned during the State of the Word, WordPress core aims to raise the minimum required PHP version to 5.6 by April 2019, and to 7 by end of 2019 – a great success for the ecosystem and the Servehappy initiative.
  • A conversation between members of the core, community and hosting teams happened during contributor day, planning the steps ahead for both Servehappy and the overall Site Health project that it is part of. A detailed summary of this will be published separately.
  • The goal for the initial parts of Servehappy is to release them ahead of the PHP version bump, likely as part of WordPress 5.1. Due to the intended version bump, the core notice should be displayed on all PHP versions below 5.6, contrary to the originally intended idea of only targeting 5.2 initially.

Next week’s meeting

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

PHP Meeting Recap – November 26th

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

  • @schlessera introduced the idea of using the concept of “feature flags” to be able to commit experimental code to be tested into trunk without immediately affecting everyone by default. Features hidden behind these feature flags would be opt-in through a mechanism like a setting in wp-config.php. The WP Beta Tester plugin could maybe be updated to provide a graphical interface to enable such feature flags.
  • The general format for feature flags in the wp-config.php could be something like the following:
    define( 'WSOD_PROTECTION', getenv( 'WSOD_PROTECTION ) || false );
  • This allows for direct hardcoding of the value, as well as for passing it in via the server environment.
  • Discussion revolved around whether such a “feature flag” system would actually improve anything. For code to be considered “committable” to trunk under a feature flag, conditions would probably be the very same than for it to be committable to trunk directly.
  • @nerrad is concerned about the code churn that such feature flags could add to Core development.
  • @sergeybiryukov is concerned that feature flags would create a new precedent in WordPress and would prefer to have us either commit the required hooks into Core to provide WSOD protection through a plugin, or to iterate directly in trunk as this has been done before the advent of feature plugins.
  • An alternative approach would be to make branches available through the WP Beta Tester plugin. However, branches are hard to keep in sync with trunk, especially in SVN.
  • @afragen will experiment with changes to the WP Beta Tester plugin to see how feature flags or branches could be handled.

Post-meeting update

Next week’s meeting

  • Next meeting will take place on Monday, December 3rd, 2018 at 15:00 UTC in #core-php.
  • Agenda: WCUS in-person opportunities planning.
  • 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: November 21st (5.0 Week 8)

This post summarizes the dev chat meeting from November 21st (Slack archive).

5.0 Planning and Updates

  • Gutenberg 4.4 and WordPress 5.0-beta5 shipped, including updates to the block editor, PHP 7.3 support, and Twenty Nineteen.
  • The 5.0 / Gutenberg team continued their daily updates to Make/Core, noting PRs and issues remaining, as well as recent and upcoming plugin releases (see 11/16, 11/19, 11/20).
  • There are a few pending tasks in Trac needing attention, which meant release candidate didn’t happen yet. On the Gutenberg side, milestones are clear after 4.5.1 was released early in the day. Anyone who can commit or review, it would be great to get your attention on those remaining Trac tickets as a priority. Find out more in the post just released today.
  • The documentation reorganisation is merged and new documentation is being added. There are a couple of excellent outlines available for users and site maintainers as well as designers and developers.

Focus and Component Updates

  • The PHP team shared last week’s meeting recap with notes on Servehappy, adding support for PHP version requirements to themes, and beginnings of coordination with the Theme Review team.
  • The JavaScript team shared this week’s meeting recap with notes on correcting package global names and npm packages publishing workflow.
  • The Privacy team met earlier today, so only their agenda is currently available that covers 5.0 testing/patches, 3rd party code on wp.org footers, mobile app permissions and tracking, Google Fonts in Gutenberg, and Google reCAPTCHA 3.0. A full recap will be posted soon.

Announcements and Open Floor

  • The date of the release candidate and the WordPress 5.0 release was discussed. The primary goal is to finish the RC, then decide upon an appropriate release date.
  • @aaroncampbell asked for volunteers to help onboard people, and guide them to first bugs for non-Gutenberg work at WCUS. Please reach out to him if you’re able to help.

Next Meeting

The next meeting will take place on Wednesday, November 28 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 the upcoming agenda post so that we can take them into account.

#5-0, #core, #dev-chat, #summary

PHP Meeting Recap – November 12th

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

  • @schlessera adapted the README.md in the Servehappy repository so that it just links to the Feature Project page, to avoid requiring both to stay in sync.
  • Adding support for PHP version requirements to themes was discussed (Meta Trac #3718). The current state of the requirement for themes to have a readme.txt file does not seem to be clearly defined, as the only source of truth is the combination of an old blog post from 2015 and its collection of comments.
  • @afragen proposed to split the individual next actions for theme support into separate tickets, just as we did with plugins.
  • We also initiated contact with one of the team leads of the #themereview team (@williampatton) to discuss the current state of the theme’s readme.txt requirements.
  • @schlessera noted that while it seems we need to help move some unrelated stuff forward to get around our own blockers, we should be careful to avoid taking on too much responsibility and wasting our time on unrelated efforts.

Next week’s meeting

  • Next meeting will take place on Monday, November 19th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Open floor.
  • 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

PHP Meeting Recap – October 29th

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

  • There was only very little presence/activity on October 29th.
  • Probably as a result of this, @nerrad asked whether it would make sense to “pause” the #core-php meetings until after WordPress 5.0 has been released. A lot of people have to focus on making their products/customer sites Gutenberg-ready and cannot invest the same amount of time into working on Servehappy while this is going on.
  • @nerrad also hinted at the possibility that the current lack of testers for WSOD protection could be due to the same reasons.
  • While discussing what the blockers actually are and what parts of Servehappy could be considered “ready to go”, we agreed that it would be useful to post a “State of Servehappy” recap post. @schlessera will prepare a draft for this to discuss.

Next week’s meeting

  • Next meeting will take place on Monday, November 5th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Open floor.
  • 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.

#php, #servehappy, #summary

PHP Meeting Recap – October 22th

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 discussing roadmap and priorities for Servehappy. It was not clear for everyone what the current state of the project is. Based on latest information we had, we settled on the fact that Servehappy is still considered a blessed task and that it was just moved out of 5.0 because of time constraints. Current goal is to get it included in a minor release following 5.0, as already suggested by the 5.0 release lead.
    • There’s an immediate need for getting more testers to actually test WSOD protection on real, complex sites with multiple plugins and custom code.
    • We discussed including the WSOD protection fork in the beta tester plugin so people can easily switch, but this would violate the plugin repository guidelines.
    • We also discussed what it would entail to commit it early into trunk to get it to run on the wordpress.org infrastructure. We should create a #meta ticket to discuss the details of this.

Next week’s meeting

  • Next meeting will take place on Monday, October 29th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion about getting more people to test WSOD protection.
  • 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, #core-php, #servehappy, #summary

PHP Meeting Recap – October 15th

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 discussed how the php-error.php drop-in in WSOD protection and the 500.php in the PWA feature plugin would relate to each other and how work could potentially be deduplicated/harmonised.
  • The php-error.php drop-in in WSOD protection is used server-side when a fatal error was caught. As it could be triggered by a theme or before the theming functionality has actually been loaded, it cannot be styled through a theme. It is “always-on”, though, and catch fatal errors very early on in the bootstrapping process.
  • The 500.php template from the PWA feature plugin is displayed by client-side code when the request made by the service worker returns a HTTP 500 status code. To achieve this, an offline cache is built through the service worker, and the site is requested to do a server-side rendering of the 500.php once so that it can be cached for the case where it is needed. Because of this, it can be styled through the theme, as the request to actually render is is a normal “render a page template” request. It requires for the service worker to have been installed previously and the server to have successfully rendered the page template once so that it can be cached. This means that there scenarios where this mechanism is not yet available.
  • There is an error query variable that would be a good fit to reuse for the 500 and offline mechanisms of the PWA feature plugin, but this would first require a change in WordPress Core as this query variable is currently being unset. There is already a Trac ticket to change this. For now, the PWA feature plugin uses a custom query variable wp_error_template instead.
  • Currentl functionality already should work as-is to always catch fatal errors on the server side and display the php-error.php drop-in, and if the service worker is active and the 500.php has already been cached, it will be used to progressively enhance the php-error.php drop-in to style it according to the current theme.
  • @westonruter suggested a change to make this more reliable and explicit by adding header information to the WSOD screen along the lines of X-WP-WSOD: true.
  • We should also add some token to the rendered page, as the headers might already have been sent in some scenarios, like a special form of HTML comment.
  • @joyously has added that for diagnosing errors, having access to even half of a HTML page can help, so cleaning everything out might further obfuscate the nature of errors.
  • @flixos90 argued that the php-error.php might not even be needed, with PWA as a later option in the future.

Next week’s meeting

  • Next meeting will take place on Monday, October 22nd, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss current roadmap and priorities.
  • 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: October 10 (5.0 Week 2)

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

5.0 planning

  • See @pento’s WordPress 5.0 for Contributors and Committers post:
    • “If you’re an experienced contributor or committer who has time available during the WordPress 5.0 release cycle, and want to be able to make meaningful contributions towards making WordPress 5.0 awesome” … “Please reply to this post with information about your availability, what components of WordPress you have experience in, and (if you haven’t got involved with Gutenberg yet) what you feel has been getting in the way.”
    • In that post are some direct actions you can take to help contribute to 5.0, otherwise please review and comment if you’ll be around during the 5.0 release cycle… thanks!
  • Also see review @pento‘s 5.0 commit/branch details if you plan to contribute during the 5.0 release cycle
  • @pento: if you have time to help, please review tickets in the 5.0 milestone to determine whether to keep it in 5.0 (Gutenberg-related), or move to 5.0.1 (other bug fix) or 5.1 (other feature)
  • @kadamwhiterequest for help testing Lazily Evaluate Translation Strings (#41305) with input requested by the end of this working week to help remove the blocker to further Gutenberg localization work
  • Plans for an updated readme.html to be committed with contributions open until RC
  • @chanthaboune: collecting blocker items and dates across team reps, will post listing to Make/Core, if you have items to add to the listing please ping @chanthaboune directly
    • @matt: 5.0 baseline and goal is 4.9.8 + Gutenberg, thus a lot of things that may have been considered blockers in past major releases are probably going to be reclassified as “nice to have”
  • @matveb: last JS package included in the Gutenberg 4.0 RC, on track and could be ready for end of the week

Updates from focus leads and component maintainers

General announcements

  • See @matt‘s post for details on the Gutenberg Phase 2 Leads, @alexislloyd (design and product) and @youknowriad (technical)
    • Phase 2 is about thinking outside the box, namely the post and page box, to allow Gutenberg to handle entire-site layouts. We will replace widgets with blocks, so any block will be able to be used in any registered “sidebar” for legacy themes, and we will upgrade “menus” to a navigation block.
    • Phases 3 and 4 of Gutenberg at WordCamp US in December.
  • @audrasjb: a11y team reorganizing, will discuss during next week’s meeting
  • @chanthaboune: as teams identify new/updated team reps, please follow notes on team rep orientation

Next meeting

The next meeting will take place on October 17, 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.

#5-0, #a11y, #core, #core-editor, #core-js, #core-media, #core-php, #core-restapi, #dev-chat, #gutenberg, #summary, #team-reps

Dev Chat Summary: October 3rd (5.0 Week 1)

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

5.0 planning

  • See @matt‘s post on plan for 5.0 and leads across the critical focuses involved in the release
  • See also @youknowriad‘s post on the technical overview of Gutenberg integration for specifics on how 5.0 could progress
  • See also @pento‘s post on the proposed release schedule
    • Current release date is November 19th, could be pushed as late as November 27th if needed.  If more time is needed, then we’ll move the release to January 22, 2019.
  • @pento: intention is to have 5.0 out (including some small fixes to ensure compatibility) before PHP 7.3 is released. If 5.0 delays significantly, then there will be a 4.9.9 release with just the PHP 7.3 compatibility fixes.
  • @joen: fast approaching UI freeze, likely by RC if not by Beta 1 (October 19th), though bugs and testing feedback might force us to have to make changes
  • @matveb: feature freeze during betas, towards end of the month, based on work remaining in Make/Core update
  • Twenty Nineteen theme will be included in 5.0 with discussions in #core-themes, though the 5.0 release won’t be delayed if the theme evolves slowly, development will take place on GitHub with @kjellr publishing a post on the topic shortly
  • @laurelfulford creating Trac tickets for bundled theme updates
  • @chanthaboune still following up with component teams to discuss concerns on shift from 4.9.9 to 5.0
  • @pento still working to determine the 5.0 release branch in SVN, likely not viable to work from trunk for 5.0, may branch 5.0 from 4.9 and work there, a Make/Core post will come once that’s determined
  • @matt: open to having 5.0.x releases that are like the 4.9.x releases that bring in some larger updates or improvements we push off (e.g., servehappy the WordPress PHP education initiative)
  • @youknowriad: will continue updating Gutenberg documentation in the plugin (they’re markdown files) while making it clear in the Handbook which version you’re looking at:
    • Is it the integrated version into Core (the default)
    • Is it the handbook for the updates coming to Core (the current version in the plugin)
    • A version selector could also be integrated
  • @lonelyvegan: list of documentation issues noted in GitHub repo
  • @matveb: note plan to reorganize handbook to give more visibility to vision/guidelines
  • @danielbachhuber: collecting REST API-related issues for 5.0, any help on them would be greatly appreciated
  • @jorbin: 400+ open tickets in the 5.0 milestone needing a bug scrub
  • Help appreciated on tickets labeled as Needs Testing or Needs Technical Feedback
  • @desrosj: can help write dev notes needed
  • @joemcgill: ideally Gutenberg goes through feature merge process to ensure security/a11y/etc. reviews

Updates from focus leads and component maintainers

General announcements

Next meeting

The next meeting will take place on October 10, 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.

#5-0, #core, #dev-chat, #summary

PHP Meeting Recap – September 24th

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 current implementation of the dynamic block we want to include at the top of the “Update PHP” page.

  • @nerrad had already implemented a Gutenberg block to provide this functionality. It has multiple fields in its sidebar to allow adapting the text to display.
  • @dd32 suggested looking into a hardcoded PHP template instead, to reuse Glotpress functionality for the translation workflow. Otherwise, it is very difficult for translators to know when strings had been updated. Also, this would ideally go into the theme for the Support subsite, instead of a plugin, to isolate the changes to this subsite only.
  • We mostly agreed that internationalization is easier with a hardcoded approach where the strings to localize are found in the code. @sergey pointed out that this is how all the content is done on the main wordpress.org site and linked to an example.
  • The approach to take would be to create a page wporg-support/page-update-php.php and hardcode the content into that.
  • This discussion showed that we wasted a lot of time (@nerrad invested up to 10 hours into the first iteration of the plugin), because the actual requirements were never mentioned before starting. We should think about how we can avoid situations like this in the future, making sure we don’t invest time in “non-options”.

WSOD Protection

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

  • The current implementation is missing logic for themes and might not yet work correctly on multisite installations.
  • @flixos90 will mention the ticket during the multisite meeting to look at what would be necessary for making it work with multisites.
  • For themes, @afragen quickly tested what would happen when no theme at all would be loaded. The login screen and the admin backend do not seem to be affected.
  • For skipping to load a theme that throws errors, we can add an additional condition in the bootstrap code where WP decides whether to load the functions.php file or not.

Next week’s meeting

  • Next meeting will take place on Monday, October 1st, 2018 at 15:00 UTC in #core-php.
  • Agenda:
    • Discuss hardcoded approach to “Update PHP” page.
    • Collect feedback on multisite approach for WSOD protection.
  • 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, #core-php, #php, #servehappy, #summary