Dev Chat Summary: January 30th

This post summarizes the weekly dev chat meeting from January 30th (agendaSlack archive).

5.1 updates

Beta 3

5.1 Beta 3 was delayed by 24 hours following issues with the PHP error recovery (aka WSOD) feature. The current plan is to release beta 3 a few hours following the dev chat today.

Schedule update

Remaining planned schedule dates remain the same, with RC 1 and a hard string freeze on February 7 and a final release planned for February 21.

See also: WordPress 5.1 Development Cycle

Dev notes status report

All but three dev notes planned for 5.1 have been published

@desrosj is continuing to coordinate 5.1 dev notes. There are also plans to release a Field Guide for 5.1 on the day that RC1 is released. If any component maintainers have information they would like to have included in the Field Guide, please provide them to @desrosj before February 6, 2019.

Updates from focus reps and component maintainers

Meeting notes and summaries

Other calls/proposals

  • The REST API team is aiming to have owners for every ticket milestoned for WordPress 5.2, so could use more help if people are looking for tickets to work on.

PHP error recovery (WSOD) update

Earlier this week, security concerns were raised about this feature, which ultimately has lead to the decision by the #core-php team to revert this feature from 5.1 and try again in 5.2 in order to adequately address the issues identified. For additional context, people can reference the original ticket (#44458) and the new ticket created to track new refinements (#46130).

Continued work on this feature will be coordinated in #core-php on Slack and during weekly meetings on Mondays at 16:00 UTC.

Additional follow up

  • @flixos90 is in touch with the original reporter of the security concern.
  • @aaroncampbell agreed to follow up with the author of the ZDNet article to inform them about the feature being removed. The article has since been updated to reflect this change.
  • From a marketing perspective, @joostdevalk reminded that because of the open nature of our project, these kinds of things are going to happen, which isn’t itself a concern, as long as we are actively following up.

Open floor

@kadamwhite mentioned that the upcoming Gutenberg roadmap would likely require enhancements to the REST API in Core and suggested that there be closer coordination between the editor team and the REST API team regarding implementation of new features or enhancements.

It was suggested that when new features require knowledge from other teams, that the people working on those features reach out via component slack channels or in comments to component/team meeting notes, which should be published consistently by all active teams.

#5-1, #dev-chat

Site Health Check Project review at WCUS

This is a verbose set of notes to record the discussions that took place at WCUS and to reflect the work that has been done across multiple teams.

The Site Health Check project is a collaborative multi-team project with a focus on encouraging better site maintenance.

This project benefits not just WordPress users, but also the surrounding PHP ecosystem as a whole. Our hope is that this will prompt a lot of PHP updates across the web.

It started as a project to focus efforts on getting users to update their hosting version of PHP from 5.2 to something where the End of Life has not already passed.

The project was initially called ServeHappy, homage to the BrowseHappy project which was a global tech effort to move away from Internet Explorer 6. The problem with the project name was that, when tested with users who did not know about the ins and outs of the project, the name was confusing and was not clear what the project’s intentions were.

The project is now known as the Site Health Check project. It encourages and hints to users that if they run a website, they should have a routine of checking and updating not just WordPress but underlying technologies that the site is built on. It also builds positive website ownership and habits.

The project is split into what can be considered 3 parts – changes to WordPress core itself, a site health check plugin and the site health check community support.

Upcoming changes to WordPress Core

The core-centric side of the project still reflects the Servehappy origins. This includes:

  • An information page on WordPress.org explaining the importance of updating PHP. The team has been working on improving the language used to benefit non-technical people and have clear instructions of what to do if they find out their site is running an old version of PHP.
  • A dashboard notice that will inform users if their site is running on a PHP version that WordPress considers outdated and plans to drop support for in a future update.
    • The version shown in the dashboard is API-driven which means that WordPress leadership has a centralized “knob” to tune the PHP version distribution.
    • The dashboard includes a link to wordpress.org/support/update-php which has generic information on what the notice means and how to update PHP on their servers.

  • There will be an environment variable or a filter which allows hosting companies to modify the link to the “Update PHP” page on their servers so that it goes to something more relevant for their customers.
    • There are some concerns of security problems and abuse over the link redirection.

  • The team has been working on a feature to add white screen protection, which the hosting group felt was helpful and cool. The white screen protection catches any fatal errors that a PHP update might produce. From the front facing side of the website, the site will still be white screened, but with the protection in place, the user can still access the admin panel.

  • There was a discussion whether it would be better for the site to be slightly broken rather than completely broken, but the general consensus was that it is better to white screen because from the Core Team perspective, they cannot be sure of what the PHP error causes, and thus can’t be sure that all the information being shown is meant to be public.

    It is better to white screen the whole website but ensure that access to the admin panel is still accessible. Once logged in, there will be a general notification regarding the WSOD.

PHP minimum required headers

Plugins

For a while, WordPress plugins have been able to set a minimum PHP required comment as part of the plugin header. To date it has not done anything but set the intention that the plugin author is able to declare what PHP minimum version they are willing to support.

Work is being done so that the Add New Plugin admin screen will show all plugins a user searches for, but will not be able to install any plugins that require a newer version of PHP without updating that first. Another task being worked on is blocking plugin updates if the newer version requires a higher version of PHP, same as it currently works if the update requires a higher version of WordPress.

This gives plugin authors better control of what PHP versions they are willing to support, and will hopefully encourage people to upgrade their version of PHP at the same time.

This change will allow plugin authors the choice to use more modern PHP functionality and syntax without worrying their plugin will break for the end user.

Themes

For themes, the Requires PHP header is not implemented yet, as they didn’t have the same readme.txt file up until recently: https://make.wordpress.org/themes/2018/10/25/october-23rd-theme-review-team-meeting-summary/

Now that new themes do have that requirement, there is an expectation that the header will be implemented as well in the foreseeable future. Here’s a ticket for that: #meta-3718

Relevant Trac Tickets

  • #43986 Disable “Install Plugin” button for PHP required version mismatch. This has already been committed to core.

  • #43987 Block plugin updates if required PHP version is not supported – Plugins screen

  • #44350 Block plugin updates if required PHP version is not supported – Updates screen

The latter two trac tickets are currently slated for 5.1 as well, planned for February 21: https://make.wordpress.org/core/5-1/

The feature merge deadline is January 10 though, so it needs to be discussed at the next #core-php meeting whether making it into 5.1 is still feasible.

A prerequisite for these changes is the WSOD protection that needs to be completed and committed by the deadline: #44458

Join in

The group has weekly meetings on Mondays 16:00 UTC on in the #core-php channel of WordPress Slack.

GitHub: https://github.com/WordPress/servehappy

Site Health Check Plugin

The site health check plugin is a way for users to be able to see technical details of their website setup without going into the server side of things. It is useful to conducting top level investigation work without accessing the server directly.

The beta version of the plugin takes the best practices from the Hosting Team’s documentation and checks the server against that. This includes: WordPress version number, plugins and themes are up to date, PHP version number, if HTTPS is active across the whole site as well as a number of other things.

When Health Check gives notifications about upgrading things, it hands users off to plain English documentation to walk them through the process. For example: https://wordpress.org/support/update-php/. Notifications for plugins and themes being up to date are based on the version inside the plugin and theme repo. If a theme or plugin is not present in the repo, it will assume it is up to date and will not give an error.

Eventually, a lot of the Site Health Check plugin will be in core.

The Site Health Check Plugin uses a traffic light system to flag up the importance of a suggested change. The definition of critical vs non-critical update notifications is from a security perspective. If it is a security issue, it’s critical.

Early user testing with the community has shown that the plugin suffers from a lack of designer eye. During WCUS, we have had a designer volunteer to review the interface and give feedback.

This should help with the usability of the plugin and balance it between positive reinforcement of things that are set up as guided by best practices whilst not over-burdening people with extra technical information.

There is some useful documentation on how to use the Site Health Check Plugin: https://make.wordpress.org/support/handbook/appendix/troubleshooting-using-the-health-check/

Join in

– Github: https://github.com/wordpress/health-check

– WP.org : https://wordpress.org/plugins/health-check

Site Health Check Desks & Community Support

In-person support is invaluable. When a user is unsure of what to do, they can find in-person support at their local meetup and WordCamps. To omit any surprises, we can encourage our community to pre-warn and prepare as many people as possible.

The idea of Site Health Check desks has been tested in 3 different WordCamps and 1 meet-up with improvements and suggestions being fed back to the plugin and fliers.

Site Health Checks is an extension of the Happiness Bar, and by asking the simple question “Do you know what version of PHP your website is running?”, people either:

  • Know & it is up to date – get a high-five. Say Awesome and keep up the good work. Pre-warn the next EOL of PHP Dates.
  • Know & it is out of date – highlight the EOL date has already passed and recommend they update their PHP version.
  • If they don’t know, Check if they know how to check. If they do, suggest that they check and that they want it to be 7.2 or higher. 7.1 EOL is in a year.
  • If they don’t know and don’t know how to check, invite them to sit down and the volunteers can help them check using the Site Health Check plugin. DO NOT scrape the site. They can end up being blocked off the servers.

Postcards were created with 5 core things to check. As well as printable table toppers. They are used as fliers for people to know where to download the site health check.

Meetup organisers have also shown an interest in running the site health check and promoting it at their meet-ups.

This is where much of the user testing of both the “Update PHP” information page and the Site Health Check plugin is happening.

Plugins and Themes Plans

Plugins and Themes served from WordPress.org can be automatically checked and updated to be compatible with 7.X. This is because there is access to the SVN where these plugins are being pushed from.

Ideally, plugin authors who have a plugin in the plugin repo will update their plugins to be compatible with PHP 7.X. There are already plugins such as the PHP Compatibility Checker which people can use to check how compatible their websites are with a version of PHP.

How are premium plugins and themes going to be handled?

The plugin team at WordPress.org can contact authors, but ultimately it is up to the plugin author to action the suggestions that are made from the WordPress.org team.

If there is no answer, or the author does not wish to fix errors, then this is a dead end.

Target Dates

WordPress 5.1  ->  ServeHappy notice + White Screen of Death protector

WordPress 5.2 ->  Site Health Check plugin

Where hosting companies come into play

We would like hosting companies to go aggressively, pushing their communities forward before WordPress does.

We know that, as a hosting company, many of you will see the same issues come up during a PHP update. It would be useful to the rest of the group if any information of any PHP errors that are being seen repeatedly and information about which plugin or theme is causing it. It will allow the rest of the team to prioritise which plugins and themes need attention to be fixed across the whole community.

It will also help the support team if any solutions are found to be shared, so that they know what to be suggesting in the forums. We may be able to add notices before a PHP update into the health check which highlights problematic plugins.

Hosts with PHP lower than 5.6 may see some initial notifications before that date.

Hosting company teams are most likely to know other people working in the hosting sector. Above all else – get the word out.  Big hosts are represented well here, but as a community we are aware and worried about the smaller, independent hosters. Talk to your hosting friends. Let them know this is coming. Invite the small hosting companies to join the Hosting Team on WordPress.org for up to date information of what is upcoming and will be effecting hosters.

The more we can update in batches the less burden there is across the whole industry.

Where plugin and theme authors come into play

If plugin and theme authors ensure that their plugins have a PHP minimum version set in their required header, then their plugins and themes will be ready once the PHP requirement is being enforced.

Plugin and theme authors should also ensure that their plugins are compatible with PHP 7.X. Tools such as PHP Code Sniffer (PHPCS) or the PHP Compatibility Checker as mentioned above should help.

Actions from the meeting

– Ensure there is communication with the hosting team regarding release date plans.

–  #core-php should be cross posting ServeHappy notes to the Hosting P2 as well.

– WordPress.hosting has been taken, unsure by who. It would be handy to have WordPress.hosting symlink to Hosting Team P2 to help getting other hosting companies to join the Hosting Team

– Recommend that Hosting Team check and sync up the Best Practices documentation.

– Can someone from the hosting team please review and ensure that Health Check plugin is checking against everything that exists in the “Hosting Best Practices” doc.

– Recommended to Health Check plugin to check out Lighthouse plugin UI.

– Write up more in-depth info for meetup and WordCamp organisers, have postcard and table toppers online so they can be shared and translated easily.

Thanks

The effort to raise the minimum PHP version requirement of WordPress is a big cross- team effort. Big thanks to

  • @brettface for the notes.
  • #core-php, #plugins, #themes and #meta team for their hard work
  • the #hosting team for their input and support
  • @alexdenning from #marketing team for the content review
  • @clorith from #forums for the health-check plugin development
  • WordCamp London 2018, WCEU 2018 and WordCamp Brighton 2018 organisers for allowing us to test the Health Check help desk concept
  • And to the #polyglots team who will be asked in the near future to translate our work for the whole community.

#recap, #servehappy, #wcus

PHP Meeting Recap – December 17th

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 meeting focused on the individual pieces that are left to complete so that the most essential Servehappy parts can become part of the WordPress 5.1 release (planned schedule has first Beta set at January 10th).
  • For the fatal error recovery mechanism (see #44458 or GitHub PR for development) the following steps are needed:
    • Add support for recovering errors by the theme by pausing it. It was determined before that the admin can work without an active theme, so implementation of this should be straightforward based on the existing code that already handles this for plugins.
    • In addition to displaying a note in the frontend when an error occurs (customizable via a php-error.php drop in), an email with the same message should be sent to the admin email address.
    • @schlessera will take care of implementing these two remaining tasks.
    • The multisite team will furthermore have an additional look at the existing implementation of multisite support.
  • A few updates are required for the Update PHP page:
    • Instead of having the content coming from the editor, it should be hardcoded and displayed via a template so that translation of the content is more streamlined and can happen via GlotPress. Furthermore it makes it a quicker process to add visual assets to the page later. @flixos90 is taking care of this.
    • The page slug needs to be changed from upgrade-php to update-php, as previously discussed, including a redirect. @sergeybiryukov has already completed this work.
  • For the actual notice in core itself, a few tweaks need to be added.
    • The version numbers need to be updated for WordPress 5.1.
    • The link URL to the page needs to be updated to account for the slug change.
    • The link URL needs to be customizable via both an environment variable (to be set by hosting providers) and a filter (for later adjustments in the codebase).
    • @flixos90 is working on these updates as part of #45686.
  • In the Servehappy API endpoint, the recommended PHP version should be set to 7.3, and the lowest acceptable version should be set to 5.6 to account for the future version bump. On any version below that, WordPress users will see a warning. Furthermore the information on official PHP version support needs to be updated as both PHP 5.6 and 7.0 are no longer support (or will be in very few days). This update has as of now been committed already as well.
  • During the work on the Meta changes in the aftermath of the meeting, it came up that adjusting version numbers exposed by wordpress.org should become a more straightforward process that can happen in a central location. This part is not crucial to have prior to WordPress 5.1, but is a minor tweak to make maintenance simpler in the future.
  • Still left is enhancing the page content with visual assets. It was agreed that these should not contain any language-dependent text. Among the suggestions were:
    • a diagram of how the server hardware, PHP, and WordPress relate to each other
    • a timeline of PHP version history
  • None of the attendees felt capable or had availability to work on such visual assets. If you can help with this over the next couple weeks, please let us know in the comments or the #core-php channel on Slack.
  • Due to the holidays in many parts of the world, the meetings in the next two weeks are cancelled. Finishing the features for WordPress 5.1 is a high priority though, and communication should continue asynchronously as needed. The next official meeting will take place only a few days before the intended 5.1 Beta release, so at that point everything should preferably be good to be merged.

Next week’s meeting

  • Next meeting will take place on Monday, January 7th, 2019 at 16:00 UTC in #core-php.
  • Agenda: Finalize remaining WordPress 5.1 work in order to be ready in time for the first Beta (Janurary 10th).
  • 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 – 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

PHP Meeting Recap – November 19th

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

  • @joyously asked about the current state of Tide. @flixos90 added that he is not clear on where it currently stands, but once it is open for projects like Servehappy to integrate with it, it would make a great use-case. Automating the PHP version compatibility might be more reliable in the long run than requiring plugin/theme authors to manually keep that information up to date.
  • The topic of having a range of supported PHP versions for each plugin was discussed throughout the meeting.
  • Information of a maximum supported version of course helps the user to determine its compatibility, generally. However, it can also have negative implications on the PHP efforts: In case the maximum supported version information is not accurate, it will make site owners hesitant from updating PHP, for no reason. Particularly since this conflicts with the project’s goal, caution is required.
  • Neither the plugin/theme author nor an automated code-sniffing based tool can reliably provide compatibility information. Arguably, the latter will end up with more accurate results in the long run, but it still will include many false positives (or false negatives).
  • Due to this problem, there was mostly consensus that no tested up to PHP version should be exposed at this point. While both the minimum and maximum versions are not reliable, the maximum version is more likely to have a negative impact on the project’s efforts.
  • Another topic discussed was the safeguarding of such incompatible plugins and themes, when they are attempted to be used. A site owner should be prevented to interact with such an extension as early as possible, i.e. when installing it. If it is installed through a way that WordPress cannot control, such as uploading manually, then it should at least apply the same restriction on activation. A follow-up discussion to the meeting questioned whether this restriction should be enforced, or alternatively only suggested, for example by using indicative colors in the UI. 
  • In that regard, it needs to be ensured that the more experienced users are accounted for as well, in case they want to be informed of fatal errors in the more traditional way and get around the safeguarding mechanisms. An idea could be to provide a constant or otherwise configurable flag to disable the safeguarding mechanisms, which could cover both the extension restriction and the WSOD prevention. By default these should definitely be enabled, to account for the majority of users. This being configurable would allow to circumvent the hard restrictions, which are preferable for the common case.

Next week’s meeting

  • Next meeting will take place on Monday, November 26th, 2018 at 16: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

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 – November 5th

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

  • Note that, in order to maintain the original time in most parts of the world after the end of daylight saving time, the meeting time has been adjusted from 15:00 UTC to 16:00 UTC.
  • Due to the focus on Gutenberg and the resulting lack of activity in other areas, this and the following meetings should preferably be used for some “housekeeping”, reviewing the project roadmap and planning the next steps after 5.0.
  • @flixos90 asked to review the Servehappy feature project page, since that has not been updated in a long time. The page would later be updated to reflect some of the additional requirements that came up mid-2018 and to show the currently planned timelines for all features in the project’s scope, plus links to relevant resources and tickets.
  • @afragen brought up #44619 which had not been tagged with the “servehappy” keyword before, mentioning that the ticket is close to ready. @sergeybiryukov pointed out that it should receive design feedback first.
  • @joyously asked about the plans for themes requiring certain PHP versions. While nothing has been developed in this regard yet, themes should eventually be able to specify a minimum required PHP version, just like plugins. This information should be available through the Themes API, and WordPress core should implement techniques to restrict installation, updates and activation of such themes if the requirements are not met, again just how it has been worked on for plugins for the past couple months. However proceeding with this is currently blocked by the lack of theme readme support for wordpress.org, since the minimum requirements should be specified via the readme.
  • The Tide project could in the future be used as an additional means to determine PHP compatibility of plugins and themes.

Next week’s meeting

  • Next meeting will take place on Monday, November 12th, 2018 at 16:00 UTC in #core-php.
  • Agenda: Review future proceedings for the project and refine 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

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