PHP Meeting Recap – January 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

The agenda for today was to discuss UX mockups and the hosting situation.  However, @jaymanpandya was not around for the meeting and we don’t have any mockup update so we were unable to discuss.  That portion of the meeting was postponed until next week.  @azaozz was present at the meeting and we spent the entire meeting interacting with him with regards to this comment he made.

He expressed some concerns regarding both content (what the servehappy page contains) and location (where the servehappy page lives) of the servehappy page.

For reference and as a reminder, the servehappy information page is the first initiative of the entire project aimed for launch in the first quarter of 2017.  You can read more about it (and how it fits into the larger “servehappy” project in the roadmap, the project readme, the related trac ticket and see the current draft.  Also keep in mind that “servehappy” is a codename for the project.  It won’t necessarily be reflected in any final form for the public facing content.

By the conclusion of the meeting we arrived at the need to focus primarily on location as it is something we haven’t fully worked out yet (it hasn’t received the same level of discussion/planning as the content).  We identified some initial factors that should influence where this servehappy information page lives.  For the purpose of this summary, I’m going to list the headings and capture some of the related discussion under each heading.

Where should the “servehappy” information page  live?

Here’s some factors that can influence the location:

Factor: Privacy

This factor concerns the privacy of any information shared by site owners/sites for the servehappy page generation/content.

Some related background:

  • this landing page in it’s initial form is intended to be a more general encouragement to upgrade PHP, why one should upgrade PHP, and some instructions on how to upgrade PHP (including linking out to various specific host instructions).
  • When the admin notice is implemented, one initiative discussed is to link from that to this page and send along with the link via url parameters some basic information (such as php version and possibly plugin slugs that are on old php versions) that allow the servehappy page to be tailored more directly to the visitor.

Related comments in chat (this is not in chronological order but has been grouped for relevance):

  • concern over passing data via parameters and the privacy implications
  • php version and php info is already sent to the wp.org servers
  • “They are running an unsupported PHP version.” That’s all we need to know (@schlessera)
  • I see it similar to how you prepare a link that contains the language as a URL argument. Don’t think that’s a privacy issue (But IANAL). (@schlessera)
  • access logs can link ip/referring domain to PHP version… (@nerrad)
  • Before we talk about “privacy” issues, I think it’d be good to identify exactly what you think we plan on sending to this page and what is concerning from a privacy point of view instead of ambiguous assumptions. (@nerrad)

Factor: Maintainability

This factor concerns the degree of effort needed to implement, maintain and update the content and anything else related to this server.

Factor: User Trust

This factor concerns how likely user’s will act on something when it conveys something they can trust (i.e. wp-admin, vs external hosted page)

Proposed locations for the Page:

In the course of the meeting we arrived at a discussion on two primary locations where the servehappy information page would be hosted/served.  They are summarized below along with the relevant discussion pertaining to each location.  The plan is to bring this to a future core dev meeting so that we can get some opinions from others in the wider WP core team/community to help with the decision for where this content will live.

External Site:

This includes the potential of being a custom domain/separate site, WordPress codex, or as a page on WordPress.org

  • privacy concerns
  • We’ve already discussed just using an internal WP-org page, but it would be a less focused layout, and be not as optimized to achieve the actual goal. (@schlessera)
  • Seemed to be general consensus that maintaining the content would be easier in this location.

WordPress Core (powered by WordPress.org API)

  • Regarding why the external page, the core notice about PHP initially shouldn’t overwhelm the user immediately with tons of content. A page inside of core would be an alternative, but we would like it to be independent of core version releases. An alternative could be to have a page IN core, however its entire content would need to be powered by the wordpress.org API, so we would need a new endpoint for the education parts. (@flixos90)
  • ‘read more..’ in the notice could point to the page in core.
  • We need to keep in mind though, the more WordPress-centric we build it, the lower the possibility to open it up to collaboration with further projects. That may not be that important of a goal anyway, but something to consider. (@flixos90)
  • We will try to make the content as targeted as possible, but the more targeted it becomes the more information we need to have about different hosts and the more data the new API endpoint for the page needs to support. The fallback will be to send an email to the host with predefined content. (@flixos90)
  • With the API, you cannot easily add/remove elements. Either it’s one blob of content (which will make management a hassle) or it’s separate sections, and we cannot easily add/delete things. (@schlessera)
  • Again, I also want to emphasize it’s hard to tweak the .org API because there aren’t many who have access, but as long as all the actual information is not hardcoded somewhere in there, it sounds alright to me. (@flixos90)
  • I think we could easily manage the content as separate sections and send these individual sections over with the API. And then we could also send call to action data, like host-specific links or a fallback. (@flixos90)
  • We should build the API in a way though that the content is easily editable without any meta trac interaction required. Where could that happen? Which backend of a .org site could power that API? (@flixos90)

Next week’s meeting

  • Next meeting will take place on Monday February 5, 16:00 UTC in #core-php
  • Agenda: Followup on the location discussion, hosts situation, feedback on mock-ups for the PHP Compatibility checker plugin (which will promote the servehappy page), feedback on mockups for the servehappy page.
  • If  you have comments/feedback/suggestions about any of the above agenda items, but cannot make the meeting, please leave a comment on this post so that we can take them into account.

To prepare for the next meeting, here are some mockups for the PHP Compatibility checker:

  • https://xd.adobe.com/view/3f36c02e-6bbb-471c-b52f-78b8f9b7fbee/?fullscreen
  • https://slack-files.com/T024MFP4J-F8ZQ08V4Z-e421fe42bb

PHP Meeting Recap – January 22nd

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 #design team has acknowledged our call for design help for servehappy and added a corresponding task in their Trello board. @jaymanpandya has stepped forward and was assigned this task.
  • We summarized again how we’re envisioning the site:
    • stand-alone design, as including it into the wordpress.org page design would reduce the impact and hinder proper optimization;
    • targeting site owners, with the option to make the content adapt to URL parameters for more precise targeting;
    • focused on easy consumption and avoiding overwhelm, with additional, more detailed content available as needed;
    • hosted on wordpress.org infrastructure and showing a small mention to the wordpress.org project;
    • not collecting usage data or feedback through the site, as that will likely get vetoed.
  • @jaymanpandya is an experienced UX designer and will work on a first set of mockups so that we can get a feel for how this might work as a real site.

Next week’s meeting

  • Next meeting will take place on Monday, January 29, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss UX mockups and hosting situation.
  • 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

Servehappy Roadmap

The group of people in the #core-php channel has been discussing and planning a project codenamed “servehappy” for some time now. We are at the point where we think that our plan has matured enough to present it to a bigger WordPress audience, in the hopes that we can get buy-in from more people to support or join our cause.

Goals

Primary Goal (long-term, indirect):

  • Reduce the number of WordPress installations running on an unsupported PHP version

Secondary Goals (short-term, direct):

  • Make WordPress site owners aware that they are running an unsupported version of PHP
  • Educate WordPress site owners about PHP and its versions
  • Provide WordPress site owners with tools and resources that enable them to update their site’s PHP version

The primary goal is what we’re aiming at. However, this is not something we can directly act upon. The secondary goals are the actionable elements that are in line with the primary goal.

We are confident that we can produce a definite positive impact on the primary goal through a concerted effort on these secondary goals.

Current State

A good overview of the current state can be found in the project repository’s README.md file.

 

Mockup of the ServeHappy page, showing collapsible sections of content.

ServeHappy page mockup
Click to enlarge

 

Through our regular weekly meetings we’ve made good progress on putting together the content for an informational page called “servehappy (in reference to the “browsehappy” page that helped get rid of legacy web browsers). The page should ideally be hosted on the wordpress.org infrastructure, similar to how the browsehappy page is stored.

 

Mockup of the WordPress admin dashboard, showing an admin notice warning about the PHP version.

Admin notice mockup
Click to enlarge

 

This page is meant to be linked to by admin notice(s) in the WordPress admin dashboard that will appear for people with unsupported PHP versions. Work on implementing these can start as soon as we have confirmation that the servehappy project should be further pursued.

 

Mockup of a plugin detail screen in the admin dashboard, showing a red "Cannot install" button and a link to the ServeHappy page.

Plugin requirements mockup
Click to enlarge

 

Finally, we want to work on enforcing plugin/theme PHP requirements as they can already be stated in the plugin/theme meta information. With time, this will provide developers with better control over their code base and incentivize site owners to keep up with the WordPress ecosystem’s evolution.

We’ve prepared a short overview document that details the core integrations and how they tie into the servehappy page.

As a side note, while working on the servehappy page content, we started collecting links to various resources that can be of use to people wanting to update their PHP version. These can be found in a separate servehappy-resources repository.

Project Progression

We intend to target only PHP 5.2.x initially, to not put too much pressure on the support channels of hosting providers. When a reasonable amount of time has passed and most of the initial updating effort has been completed, we can consider moving the needle up to PHP 5.3.x.

Provided that we have a clear roadmap, transparent communication and the patience to let site owners and hosters handle the updates in manageable intervals, this provides us with a tool to slowly catch up to PHP releases and reduce the currently growing gap between WordPress requirements and PHP versions.

Timeline

Here’s our current preliminary timeline:

Information Page on WP.org – Current Draft
– Trac ticket
1st Quarter 2018
Admin Notice in Dashboard – Trac ticket 2nd Quarter 2018
Minimum PHP Requirements Trac ticket 3rd Quarter 2018

Of course, these are only guesstimates. The actual development work involved makes this timeline easily possible, but what is time-consuming (and hard to predict) is the amount of discussions that are needed to find a concensus on all critical decisions.

Our Request

Before we invest more time into this project, we want to get a basic decision (in principle) about whether we should pursue or not.

  1. Is the servehappy project worthwhile and do we have a general buy-in from Core leadership?
  2. Can we make the servehappy project an official feature project?
  3. Information Page – Can this page be hosted on the wordpress.org infrastructure?
  4. Information Page – Who is responsible for the final editorial check?

To this end, we had the servehappy project added to the agenda of the upcoming devchat meeting on 10th Jan, 2018. This post was prepared to allow attendees of this meeting to get a quick overview of the project in preparation for the meeting.

#php, #roadmap, #servehappy

PHP Meeting Recap – January 8th

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 primary focus of this chat was strategizing about our opportunity on January 10th to discuss the servehappy project during the devchat. We discussed a potential roadmap with estimated timeline so that there’s specific information to offer at the devchat.

Decisions arrived at for rough ETA’s on Roadmap

  • 1st Quarter 2018 is target for servehappy page on wp.org
  • 2nd Quarter 2018 is target for core integration (admin notice etc). See Core integration doc recently published.
  • 3rd Quarter 2018 possible target for plugin requirements work.

Other discussion

  • README.md was updated on the servehappy repository. Pull requests are welcome for keeping it up to date and adding any missing info (such as PHP Compatability Checker mentioned during the meeting)
  • For admin notice initial work will be done in the trac ticket (and that will be the source for initial wire-framing/discussion) and then we’ll do a feature plugin (possibly WordPress/servehappy-admin-notice) for iterating on implementation and easier user/usability testing.
  • Some discussion around Tide and any potential impact on the servehappy project. General consensus is that Tide doesn’t block anything but communication should be kept open between the two teams to be aware of any overlap of documentation or user facing things between the two projects.
  • @schlessera will be preparing a blog post outlining a more detailed roadmap that will be published within two days, the intent being using it as a resource ahead of the general WP core dev-chat meeting.

Next Meeting

The next meeting will take place on Monday January 15, 16:00 UTC as always in #core-php.  The agenda will likely cover the results from servehappy presentation at the dev chat meeting and the next steps from that. See you next week!

#core-php, #php, #summary

PHP Meeting Recap – December 18th

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

  • After asking for feedback last week, we got told that our weekly recaps are valuable to some readers, so we keep writing them. We removed the attendees’ list because it takes a substantial amount of time to complete, with little added value.
  • Due to the upcoming holidays, we are skipping the meetings for December 25nd and January 1st. Next meeting will be held on January 8th.
  • Regarding plugin testing, we reasserted that we’ll still recommend PHP Compatibility Checker for now, even though Tide (Team Home | GitHub) is on the horizon. As long as Tide is not open source and hasn’t been properly integrated into the WordPress ecosystem, it just isn’t a valid option.
  • As we’ve finished the content for the page, we are now discussing the overall strategy of moving forward with the project:
    • produce preliminary deliverables (site mockup, admin dialog mockup)
    • create/update (Meta) Trac ticket(s) to make sure we have a clear set of goals, a proper roadmap and a timeline
    • raise awareness through dev-chat meetings and news portals to get feedback and buy-in
  • Ask a precise question to get a precise answer: “Is that something worth pursuing within wordpress.org scope?”
  • We plan to discuss the project in dev-chat on January 10th. By then, we expect to have the deliverables ready.
  • Two tickets that currently track the progress: Trac 41191 (admin notice) and Meta Trac 2996 (external servehappy page).

Next week’s meeting

  • Next meeting will take place on Monday, January 8th, 2018 at 16:00 UTC in #core-php (Note: We are skipping two meetings because of Christmas and New Year’s Day).
  • Agenda: Discuss latest progress and our approach for the dev-chat meeting on January 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.

#core-php, #php, #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

PHP Meeting Recap – November 20th

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: @flixos90 @jdgrimes @nerrad @overclokk @ptasker @schlessera @uofaberdeendarren @vizkr

Chat Summary

The agenda for this week was to finish the rest of the “Before Upgrading PHP” document that will be handed over to the marketing team afterwards to get their help with writing the copy.

Here is the discussion summary:

  • It was decided that the sections dealing with asking plugin/theme support, the hosting provider and possibly a developer for help should be combined into one help section at the end of the document. The reason for this decision is that all of those resources may or may not be available for a site owner, and the results of a consultation may vary. It should be emphasized that the upgrade steps are intended to be easy enough for the site owner to perform them on their own, but those resources should still be pointed out for those who feel more comfortable that way.
  • Merging those help sections into one has made the document more straightforward to read. It essentially now consists of the following steps:
    • Backup & Rollback Plan
    • Updates
    • Compatibility Check
    • Find replacements for incompatible plugins
  • The third step will hopefully become a lot simpler once the new WP Tide project is available.
  • The fourth step is at this point the least straightforward one. Finding plugin alternatives requires either good knowledge of the WordPress economy or an exhausting search. In addition, migrating from one plugin to the other will likely involve non-trivial tasks that only a developer could take care of. At least in regards to finding alternatives, a dedicated feature for that in the plugin repository could help. @schlessera pointed out that this is apparently already being worked on by the plugin repository team.
  • By the end of the meeting, it was agreed that the draft is now ready to be passed on to the marketing team so that they can build something awesome out of it. @flixos90 has since asked for their help in the #marketing channel.

Next week’s meeting

The next meeting will take place on November 27th, 2017, 16:00 UTC as always in #core-php. There is no scheduled agenda yet this time, as there hasn’t been a response by the marketing team yet. WordCamp US will however provide a good opportunity to talk about the document in person. 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

PHP Meeting Recap – November 13th

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.

The meeting’s chat log.

Attendees: @flixo90 @jdgrimes @jon_bossenger @mikelking @mte90 @nerrad @schlessera

@sergey

Chat Summary

We started the meeting by examining the poll that @flixos90 had made regarding a modified meeting time slot.

As most of the votes went to the 16:00 UTC time slot, and nobody had a specific reason for not using that time slot, we decided to make that new time official from now on.

This means that all subsequent meetings are held at 16:00 UTC from now on.

Then we continued working on the “Before Upgrading PHP” section again, which we are working on in a shared Google Doc.

Here’s a brief summary of the corresponding discussions and decisions:

  • We discussed adding a second “Backup” step after all updates have been done. In case of a rollback further down the line, this would avoid going through all updates again, which incur a big time and bandwidth hit.
  • While discussing how to best add this addition “Backup” step, we came up with the idea of adding small “aside” text boxes to the document, which visually communicate that the content therein is not part of the critical path and should not be considered a blocker in case the user can’t complete that “aside”.
  • We discussed the different animals that Google Docs assigned to the anonymous users, and how they don’t seem to match up everywhere. 😉
  • Regarding the compatibility checker, we discussed whether to include knowledge about the future XWP project that might have an impact here, or not. We decided that we write the content for the current state and context, as there’s no guarantees to when or if any of the WIP projects will be completed and usable.
  • We added an aside to the compatibility checker as well, to warn users against false positives and other detection issues.
  • We acknowledged that our aside might be a bit on the intimidating side, and that we need the help of the #marketing team to rephrase the copy in that regard.
  • We rewrote the “Ask plugin/theme support” topic so that it is clearer and points people to existing resources first before contacting support.

Next week’s meeting

The next meeting will take place on Monday, November 20, 2017 at 16:00 UTC, as always in #core-php, and its agenda will be to finish the rest of the “Before Upgrading PHP” document that we will hand over to the marketing team to get their help with writing the copy. 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, #core-php, #php, #summary

PHP Meeting Recap – November 6th

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: @bpayton @flixos90 @jdgrimes @mte90 @nerrad @overclokk @psykro @schlessera @vizkr

Chat Summary

The agenda for this week was to review the suggestions @flixos90 has worked on for the “Before Upgrading PHP” section that is available in the Google document, taking the past weeks’ discussions into account.

As other important topics had come up after the agenda had been laid out though, the discussion ended up revolving around different topics, only taking a short peak at the document towards the end of the meeting. Here is the discussion summary:

  • @flixos90 shared some great news about the tool that the XWP team has been working on, which had been mentioned a few times before in other meetings: The tool automatically scans all plugins in the plugin repository for their usage of the WordPress coding standards and, more important for the PHP team, their compatibility with different PHP versions from 5.2 to 7.x. The project is going to be an official part of the repository, and all of this will be handled through an external API. The results of the scans will be displayed on the respective plugin page, and the PHP compatibility checker could leverage that data as well. The API will even be able to scan plugins and themes which are not part of the repository, by temporarily uploading them. This will allow to test even paid or custom developed plugins and themes. That part will not be exposed through any UI in the initial release, but it will be possible through the API.
  • @nerrad commented that this will likely require some changes on the Servehappy page copy that exists so far. These changes will likely be minor though and most importantly take away some points of uncertainty that with that tool at hand won’t matter anymore.
  • It would make sense for the PHP Compatibility Checker to leverage that API, so it needs to be discussed with the responsible people at WP Engine what steps should be taken here. The new API could either be used in addition for more accurate results, but it may possibly even be better to replace the current mechanism with it entirely, as it would improve speed significantly because it could in many cases use data that has already been gathered before rather than running the expensive checks on the server.
  • The above two topics should be discussed in detail once the API has been officially released to the public.
  • @psykro asked whether it would be possible to change the meeting time or host a second meeting. Everyone who responded was open to a change, however it should preferably remain close to when it’s currently scheduled (every Monday at 19:00 UTC). If you are interested, please leave your vote(s) on this Slack post.
  • @mte90 asked about the new plugin headers for a minimum required PHP version and specifically about when the integration with core for it should be developed. While core should not include any PHP-related notices or warnings until the Servehappy page is published, it makes sense to start work on it before. This will not be a major topic for the PHP meetings for now, but should mainly happen in its Trac ticket #40934, unless a rather complex topic comes up which would benefit from a discussion in a meeting. @psykro, @schlessera and @mte90 expressed their interest in working on this. Mockups for the visual side of things should be created early, and the #design team should be asked for help with this. Since the project will likely involve quite a bit of code and it’s not optimal managing this solely through Trac, it was suggested to go either with a plugin-first approach or use a GitHub fork of the WordPress development repository.
  • After that, attendees started reviewing the sections in the Google document and added some comments and suggestions. @nerrad highlighted that the last section about contacting a developer should only be targeted at those site owners that already have an ongoing relationship with one, or at least already know one. People who have never hired a developer are unlikely to do so for a “random” PHP upgrade. More in-depth review and discussion on the Google document was postponed to next week’s meeting.

Next week’s meeting

The next meeting will take place on November 13th, 2017, 19:00 UTC as always in #core-php, and its agenda will be to actually review the initial suggested copy for the “Before Upgrading PHP” section so that it can be passed on to the marketing team afterwards. 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

PHP Meeting Recap – October 30th

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: @flixos90 @jdgrimes @mte90 @nerrad @schlessera @vizkr

Chat Summary

The agenda for this week was to discuss the last remaining GitHub issue for the “Before Upgrading PHP” section and review the Google document for it that @schlessera had created from the previous discussion results.

  • @flixos90 gave a quick update on the current state of the PHP Compatibility Checker plugin by WP Engine:
    • The sales call to action was already removed on the GitHub repo. It’s not in the public release yet, but it’s done.
    • The plugin is currently not 5.2-compatible, but will be made that.
    • In order to use the best PHPCompat library version possible, the plugin will bundle both the last 5.2-compatible version as a static dependency and then the latest version via Composer. Those will be loaded as necessary.
    • Instead of allowing the user to test for a specific PHP version, the plugin should offer a way to automatically scan for all recommended PHP versions and in the end recommend the user which version to upgrade to (if no errors in the latest version, recommend that one; otherwise proceed; give them a quick comparison overview at the end). This will make the process easier.
    • In that automatic procedure, older versions than 5.6 should only ever be checked if all other newer versions include failures. Under these circumstances, the idea is that it’s still better for a site to be on PHP 5.4 for example than 5.2.
    • All of this will be worked on. However, as there’s currently no timeline, there’s no pressure there. Once there is an idea on when it’s needed, the WP Engine team should be informed.
  • The GitHub issue about contacting a developer was considered a bit fuzzy, as it is probably only useful for cases where a site was initially set up by a developer, but then never maintained. In these cases the site owner may still have a developer of choice that they can contact. In case a site is actively being maintained by a developer, it’s unlikely that it’s still on such an old setup. But even there it might help. It was decided to include this recommendation as the last paragraph, to not overemphasize it. @nerrad suggested to go with something like the following:

    While the steps above are something we believe any WordPress site owner can do, if you have an existing relationship with a developer/agency, you may want to also consult with them regarding the specific needs for your site.

  • Regarding the sections in the Google document, it was decided that the “Updates” section should follow right after the “Backup and rollback plan” one as it builds upon that.
  • It is still unclear how to handle the plugin and theme-related sections, both in terms of getting support and finding replacements. The idea of a crowdsourced list of plugins and whether they have any issues and which ones is nothing that can be relied upon yet. Plugin alternatives cannot be recommended without affecting the plugin market in an opinionated way, the only solution here would be a “Related plugins” functionality in the repository, but this would be something else far away from execution. For now these sections should be kept vague enough, while being as precise as possible about everything else.
  • It must be clarified that while a backup helps with issues of WordPress core, plugins or themes, it does not back up the PHP version. If the PHP upgrade breaks a site, the entire PHP version needs to be rolled back, so contacting the host would be required again.
  • In order to get this document to a place where it can be handed over to the marketing team, actual copy suggestions like in the initial Servehappy document will be needed. Right now a lot of it is summary including things some of which should not actually be emphasized as much in the final document.
  • The current Google doc should be reworked to only include draft copy as content, and anything that’s currently there and significant to know in addition should be added as context-sensitive comments. @flixos90 started work on this as of now, and anyone is welcome to chime in with more suggestions, which will then be reviewed in the next meeting.

Next week’s meeting

The next meeting will take place on November 6th, 2017, 19:00 UTC as always in #core-php, and its agenda will be to review the initial suggested copy for the “Before Upgrading PHP” section so that it can be passed on to the marketing team afterwards. 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