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 – September 25th

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: @brainfork @chasecm @flixos90 @jdgrimes @joyously @mte90 @nerrad @schlessera @sergey @spacedmonkey

Chat Summary

Continuing what was started last week, the agenda for this week was to review the second half of the copy for the “Servehappy” page, which the marketing team has worked on.

  • The first part of the meeting was about reviewing the “Are there risks when upgrading my PHP version?” section:
    • The first paragraph should emphasize more how WordPress consists of multiple parts by individual parties that may cause different kinds of compatibility issues when used together. There should be less focus on the open source part of it.
    • The first two paragraphs can be merged into one:

      In a perfect world, the answer would be “no”. However, the WordPress ecosystem is made up of thousands of themes and plugins (built and maintained by developers all over the world). All the various combinations of these parts that can be added to your site increase the potential for incompatibilities with certain PHP versions. WordPress cannot detect all those possible conflicts automatically.

    • The third paragraph should be omitted since talking about the different possibilities regarding PHP version upgrades does not belong into the section describing risks. The fourth paragraph will not be part of this section either, but can instead be reconsidered for an additional “Before Upgrading PHP” section, which will be worked on later.
    • An extra paragraph should be added to clarify some of the actual issues that may occur:

      Some of the things that could happen when these incompatibilities affect your site, are white screens or unexpected behaviour. If any of these happen to you, you can troubleshoot them (this should link to extra troubleshooting steps elsewhere) or roll back the php version on your server (the rollback part may not always be applicable, so it may be better to strip it out). However, by following the suggestions in the next section, you can drastically reduce the chance to run into any of these issues.

  • The second part of the meeting was about reviewing the “How to Upgrade PHP for your Website” section:
    • The first two paragraphs are good as is.
    • In the third paragraph, it should only be recommended to send an email to the host if the site owner does not find any resources about how to upgrade. The part about them feeling comfortable doing it should be removed, as upgrading PHP itself is a rather simple task compared to some of the steps recommended before the PHP upgrade. When the host provides an interface for it, the upgrade is usually only about navigating to the right area and hitting a button. The paragraph should therefore start like this:

      If you cannot find instructions for your specific host, the best thing you can do is ask them. […]

    • The email template itself should not use specific PHP versions and rather ask for the latest version (this may be revisited, see below):

      I want my website to be as performant and secure as possible with the latest version of PHP. For the server my WordPress site is hosted on, I want to ensure that is the case. If I am not already on the latest version of PHP, please let me know what steps I need to take to upgrade.

    • It may be useful to highlight that, if the hosting provider is unable to upgrade the PHP version, the site owner should consider switching to another host. On the other hand, it could also be clarified that if the site owner is uncomfortable / unable to upgrade to the latest PHP version due to some incompatibilities detected, it is also worth upgrading to the highest possible version that is still actively supported if there is no other way.
    • The section about self-hosted setups and servers managed by the site owner themselves should be removed as it is very unlikely those people are not already aware about PHP upgrades and how they work. This page is for non-technical people, and self-hosting a site does not fit into that scope.
  • Whether it is really the right decision not to mention any specific PHP versions should be revisited. Not mentioning any version will make the information on the page more vague, and regularly updating the page to use the current version should be an easy task, when done right initially. There could be a shortcode for the latest PHP version (currently 7.1) and another one for the lowest PHP version to recommend (currently 5.6), both of which would be used throughout. This would allow to only change the version numbers in one place and have them updated throughout the entire page.
  • As mentioned before, the page should also contain a section about which steps to execute before actually upgrading PHP. This could include things such as using a PHP compatibility checker plugin, checking how well the themes and plugins used are maintained, backing up the site, and more. This is currently not part of the Google document because there isn’t a clear idea for the section yet.

Next week’s meeting

The next meeting will take place on October 2nd, 2017, 18:00 UTC as always in #core-php, and its agenda will be to think about and plan the “Before Upgrading PHP” section mentioned above. Ideas are very welcome and it would be great if you could take some time to think about possible steps in the meantime so that there is already something specific to discuss next week. 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, #marketing, #php, #summary

PHP Meeting Recap – September 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: @brainfork @dnavarrojr @espellcaste @flixos90 @joostdevalk @jdgrimes @milindmore22 @nerrad @pbearne @schlessera @sergey @sobak @vizkr

Chat Summary

The agenda for this week was to review the current progress and plan how to proceed in the upcoming weeks.

  • @flixos90 shared the outcome of the meeting with the #marketing team that had happened some days ago (read the full chat log): The marketing team has started work on the copy for the planned Servehappy page, based on the drafts the PHP team created over the past couple weeks. A Trello board has been set up, and the actual text is being worked on in a Google doc. The team has set a deadline for September 15th. As of writing this post, the document has been completed. They also offered their help in the future for other things that the page would need, such as graphics and illustrations. A special thanks to the marketing team for their efforts!
  • The next PHP meeting will be used to review and discuss the document in detail and figure out questions or suggestions, if any. Anyone from the marketing team is also very welcome to join this chat in particular!
  • It was decided that once the document is considered to be in a good shape, it is time to pitch the idea of the suggested Servehappy page further. In particular more leadership people need to be convinced of the efforts in order to successfully proceed. The page must be officially affiliated with wordpress.org, whether it is hosted as part of it or at a separate location. This is a requirement so that it is eligible for being linked to from WordPress core itself.
  • @schlessera suggested creating a proposal document that describes the problem the team is trying to solve, the goals the solution should meet, the current state of things and what is needed to get this launched. This will provide clear documentation and can be used in addition to the page document itself to pitch the idea. With this, the team hopes to be able to at least get a “conditional” buy-in.
  • It was discussed whether the page should be part of wordpress.org or whether it should be hosted as a separate website, such as servehappy.com or servehappy.org (in either case it should be an official part of WordPress).
    • Having it as a separate site would perhaps make it interesting for other PHP projects as well.
    • Having it as a separate site would give more flexibility on what the overall page layout and design should look like while with .org, it would obviously need to integrate.
    • Having it as a separate site would give parity with something like browsehappy.com, however the Servehappy content would be much more specific to WordPress, so it may be better suited as part of wordpress.org.
    • Having it as a separate site would allow to create separate pages for the bits and pieces if it makes sense, and guide visitors through them.
    • In the end nobody had a heavy preference for either, so where to host this can be approached rather flexibly, as long as it is based on a clear decision by the core leadership. The core leads may very well also have their own preferences for this.
  • In order to bring more attention to the efforts, it was decided that the best way to start once both the copy and proposal documents are ready will be to first publish the proposal on the make blog and then bring it up at the weekly core dev-chat. The post should be available in advance so that it gives people time to prepare. It may also be useful to schedule regular update slots in the dev-chat meetings, in order to provide information on where the project is at and maintain traction.
  • The proposal document should also contain all suggested integration points with core.
    • What feature needs to integrate with the page?
    • Where should the link point to?
    • Is dynamic content transported through the link needed? If so, which GET parameters would the page need to support?
  • Using GET parameters for some dynamic parts of the page would give the visitor a better feeling their specific issue is addressed by the page. However, it needs to be ensured that all data passed is not controversial regarding privacy in any way. It needs to be entirely anonymous.

Next week’s meeting

The next meeting will take place on September 18th, 2017, 18:00 UTC as always in #core-php, and its agenda will be to review and discuss the page document the marketing team has worked on, as described above. 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