PHP Meeting Recap – October 16th

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: @felipeelia @flixos90 @jdgrimes @mte90 @schlessera @sergey @stevenkword @tobifjellner @vizkr

Chat Summary

The agenda for this week was to continue discussion on the GitHub issues that deal with the planned “Before Upgrading PHP” section.

  • @flixos90 started by giving a brief recap on last week’s meeting, particularly on the discussion of the PHP Compatibility Checker plugin by WP Engine and the changes that need to be made to it in order for it to be referenced and recommended by the Servehappy page and core. Together with the lead developers of that plugin, he will explore the next steps.
  • The meeting then focused on the individual GitHub issues.
  • “Ask hosting provider”: This is kind of a fuzzy issue as to whether that is useful depends entirely on the individual hosting provider. One idea was to focus on managed hosts only for this and in the copy start with something like “If you are on a managed host, they may be able to…” – however, it may be a better decision to not mention this at all, as it would be hard to give valuable advice. No clear decision was made on this yet.
  • “Updates”: WordPress core, plugins and themes should be up to date (of course only plugins that do not require a higher PHP version in their update). As these updates can also break the site without even getting to the PHP part, this point should therefore mentioned after the “Backup and rollback plan” point. In regards to that, it may be helpful to recommend doing an extra backup after everything has been updated (still before the PHP upgrade) – however only if storing multiple backups is possible with the solution the site owner is using for their backups.
  • “Ask plugin/theme support”: This is definitely good advice when using premium plugins or themes with paid support. For community-driven plugins, it really depends on the popularity of the plugin and how many volunteers are helping out for the respective plugin. A related idea that came up was to create a list where support volunteers can add specific plugins with issues on certain PHP versions to so that over time a crowdsourced resource to find out about possible issues in advanced will evolve. Since @danielbachhuber and XWP have apparently been working on an automated solution for a similar cause, it may be valuable to combine these efforts. The result could for example be an API that delivers data on plugin compatibility with different PHP versions, taking both automated and manually submitted data into account. What to present about this point on the Servehappy page heavily depends on what these projects will end up working like.
  • “Check WP.org plugin/theme info”: It was decided that this point should not be included. There is no plugin information on the maximum supported PHP version, and even if there was, the majority of plugin authors would not update it accordingly over time (the same issue that is currently happening with the “Tested up to” field for the WordPress version). Furthermore, most developers whose plugins have issues on a more modern PHP version likely do not know about it or are not maintaining the plugin any longer.
  • “Test locally/on staging”: This point should be ditched as well, as it is much too advanced. A local environment is definitely not something trivial to set up for a non-technical person. For staging it depends on the site owner’s hosting provider again, but even on hosts that offer 1-Click-Staging, it can be a complex task – especially since several hosts do not allow changing PHP versions differently between the environments of a single site.

Next week’s meeting

The next meeting will take place on October 23rd, 2017, 18:00 UTC as always in #core-php, and its agenda will be to finalize discussion on the remaining GitHub issues for the “Before Upgrading PHP” section, with the following week focusing on transfering all these thoughts into 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-php, #php, #summary

PHP Meeting Recap – October 2nd

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 @jpry @joostdevalk @garyj @mte90 @nerrad @schlessera @sergey @techjewel

Chat Summary

This meeting revolved around discussing the “Before Upgrading PHP” section.

First, we quickly brainstormed a list of possible actions we could recommend:

We later created an issue for each of these possible actions, and the above list links to these.

Then, we discussed in more detail how a non-technical site-owner could run compatibility checks, and in what ways we could automate this. There are two main directions that need to be evaluated: static analysis & runtime checks.

The static analysis can be done through the PHPCS library. There’s a usable plugin wrapper called “PHP Compatibility Checker” that already does all the required work of wrapping the PHPCS command line tool into a WordPress plugin and provide a neat user interface. However, this plugin currently contains a direct entry point into the sales funnel of WPEngine, the hosting company that funded its development. While this is just fine to refer people to on a personal basis, we currently consider this a show-stopper when it comes to officially endorsing this plugin, as it would mean that we’re sending existing customers from other hosting providers from within the admin backend they’re hosting to their competitor’s sales page. We decided we’d contact WPEngine to see whether they would be willing to collaborate on a “toned-down” version of the plugin.

[ NOTE: in the meantime, discussions with the hosting company responsible for the above plugin were very fruitful, and they are willing to change the plugin to defuse the sales message. ]

While we also discussed the merits of runtime checks when installing/updating plugins, we came to the conclusion that is is not reliably feasible, as it is not possible to reliably hit all possible code paths of a given plugin/theme in an automated manner.

We briefly went over the new “Required PHP version” information, and whether a “Tested up to PHP version” was already discussed. Most people think that this is not easily kept up to date and will lead to stale information. However, the possibility should be explored whether the statistics collected upon plugin updates could not be used to statistically deduce whether a given PHP version can be assumed to be safe to use.

We briefly mentioned Backups as well before the end of the meeting. These cause some of the same issues, in that we don’t want to link to specific vendors at the expense of others. For now, we’re thinking it’s best to give general advice about what to watch out for with the backups, and then link to something like this page: https://wordpress.org/plugins/search/backup/

As already stated we have created GitHub issues for every topic, and an overview of these can be found in the “Before Upgrading PHP” section of the Sections” project board. Any feedback on this topics is welcome!

Next week’s meeting

The next meeting will take place on Monday, October 9, 2017 at 18:00 UTC, as always in #core-php, and its agenda will be to go over the feedback added to the individual sections and distill the information. 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 – 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 18th

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 @jdgrimes @mikelking @mte90 @nerrad @pross @schlessera @screamingdev @sergey @tfrommen @xkon

Chat Summary

The entire meeting revolved around discussing the draft document that the #marketing team has produced for our PHP “servehappy” page. We went through the document paragraph by paragraph in order to have a guided approach to discussing the content.

Even though we went way past the normal meeting duration, we only got through the first half of the document so far.

Here’s a non-exhaustive list of observations we had:

  • The page talked about having “detected an issue”. Although that makes sense when we redirect people from within the WordPress admin dashboard, we should first try to build a generic page that makes sense as well when you directly access it.
  • We should make sure that negative points we raise with old PHP versions do not draw a negative picture of WordPress itself.
  • A lot of thoughts went into the paragraph that opposed backward support to the recommended version. We want to emphasize that you should not run on older PHP, even though WordPress does support it.
  • Country-specific assumptions, such as using the term “dollars”, should be avoided as far as possible.
  • Some of the copy feels clunky when reading it as a technical person, but no-one feels able to improve upon it without making too many assumptions about the technical knowledge of its intended audience.
  • We’re still discussing how best to refer to the different PHP versions and branches, and what relative terms like “latest” or “most current” mean in this context. This is why we’re trying to avoid direct version references whenever possible.
  • There were some inconsistencies in terms of what “we” refers to. We decided to consistently use “we” to refer to “we, the people working on the WordPress project” and address the visitor as “you, the site owner”.
  • We had some discussion about “more features being delivered through plugins”, and whether that should include “themes” as well. We opted to leave themes out of there, because, even though you can technically introduce new features through themes, best practices recommend having the theme be about the visual presentation only and having plugins provide new features instead. We don’t want to further spread the misconception that themes should include actual required functionality.

Next week’s meeting

The next meeting will take place on Monday, 25 September 2017, 20:00 CEST, as always in #core-php, and its agenda will be to discuss the second half of the draft document to finish what we started. 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 – 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

PHP Meeting Recap – August 28th

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 @davidsword @flixos90 @jdgrimes @joyously @mte90 @nerrad @ptasker @schlessera @screamingdev @sergey @sobak @tfrommen @vizkr

Announcement

Last week saw an important milestone for the efforts of the PHP initiative, as plugin authors are now able to specify the minimum required PHP version in each plugin’s header. For now this will only be information displayed in the plugin repository (here is the meta commit that did it 🎉), but eventually it will have an effect on core behavior as well, as core will be able to warn users and prevent upgrades that would not be compatible.

For the latter, the “Serve Happy” page in the works will be a major foundation, to have a location to point site owners to when they encounter such an issue.

Chat Summary

The agenda for this week was to finalize the section outline and its suggested contents that have been discussed in the past couple weeks in order to present these ideas to the marketing team. One or two sentences should be provided for each suggested sub-section, or at least a bullet point on what each respective section will be about. This recap heavily builds upon the work from last week, so reading the previous recap in advance is especially recommended this time. The discussion on GitHub will help as well.

  • The outline should be finalized for the site owner context, as this is the most important group that needs to be addressed in order to grow the number of people on supported PHP versions.
  • Out of the three previously suggested approaches, it was decided to go with the “probability approach”: It should be highlighted that almost half of all WordPress sites are running in a way that has significant drawbacks. Readers should become curious on what they can do to run their site in the most efficient way possible.
  • In addition, the “detected issue approach” should be used conditionally, based on a certain GET parameter that will be set when the user is directed to the page from WP-Admin. This will allow the page to be targeted correctly, indicating issues precisely.
  • The term PHP should not be brought up in the introduction, but rather in the second section where more information is provided. If it was in the introduction, it could too easily scare away people from continuing reading. The paragraph that was so far used for the “technology approach” is a good start for that one.
  • The “technology approach” is also something that could be used for an eventual PHP whitepaper, similar to the existing security whitepaper. However that is another topic that can be worked on once the “Serve Happy” page is completed.
  • The “What is PHP?” section should also include general information on PHP versions/upgrades and why they are needed. The latter was previously suggested for a later section, but explaining versions and upgrades is required to follow the actual objective of the page a bit later.
  • It has to be explained why WordPress can’t deal with PHP upgrades itself and also why there are simple one-click WordPress updates, but not one-click PHP updates.
  • It will be helpful to include a wireframe illustration of a common WordPress stack, to help users understand where the responsibilities lie with WordPress, PHP, MySQL etc.
  • Indicating potential problems with upgrading PHP should be hinted at already when explaining why WordPress cannot deal with the problem by itself. In the actual “How to upgrade PHP for your website” section, this should only be referenced briefly as the focus should be put on which steps to perform in order to prepare a PHP version upgrade.
  • A GitHub issue has been opened to collect and discuss ideas to include in the steps to prepare an upgrade.
  • At the end of the meeting, it was decided that, while there aren’t actual drafts for everything yet, there is a clear idea now of what every section and sub-section should contain. As such, the outline is now ready to be shared with the marketing team. After the meeting, an initial meeting with the marketing team was scheduled, taking place at the marketing team’s regular time (see “Initial marketing collaboration meeting” section further below).

Suggested page outline

This is the current outline suggested (some sub-sections have actual drafts, while the ones in square brackets simply explain what they should be about):

  1. Introduction
    • You want your site operating at its full potential. Is it? Almost half of the sites running WordPress are not. This page will help you determine if your site is one of them and how you can fix that.
  2. What is PHP?
    • One of the important software components that enables WordPress to run on all sites is PHP. [briefly explain in a non-technical way what it is]
  3. Why PHP matters to you as a site owner
    • Every WordPress website requires PHP to run. PHP has many different versions, and as it is with most things in our technology world the more recent the version, the better experience you get. WordPress makes it easy for you to get started by supporting a wide variety of PHP versions, but if you want your website experience to be better, you want to make sure you’re running the latest PHP version.
    • [educate the user about what the problems with an outdated PHP version are]
    • [highlight benefits of using a current version of PHP]
    • While it would be stellar if WordPress could solve the PHP problem itself, unfortunately it is not in charge of the PHP version, since PHP runs on the server that powers your website. Furthermore there can be incompatibilities between certain PHP versions and certain WordPress plugins or themes, which it cannot detect automatically.
  4. How to upgrade PHP for your website
    • Before you proceed with the update, you should try to make sure that your website including its plugins and themes work correctly with the PHP version you want to upgrade to.
    • [provide steps to prepare an update to PHP]
    • [give instructions on updating PHP]
    • [help troubleshoot issues]

Initial marketing collaboration meeting

A little later today, the initial meeting for our collaboration with the marketing team will take place. The agenda will be to touch base, present the section outline and answer possible questions. In addition to the general introduction, plans on how to proceed and collaborate efficiently should be developed. The meeting will take place today (August 30th, 2017, 15:00 UTC) in the #marketing channel on Slack. Please join in if you’re interested, as this will likely determine how the collaboration will work going forward.

Next week’s meeting

The next meeting will take place on September 4th, 2017, 18:00 UTC as always in #core-php, and its agenda will be to review progress and discuss next steps based on the outcome of the meeting with the marketing team. 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 – August 21st

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 @jdgrimes @mte90 @nerrad @schlessera @screamingdev @sergey @spacedmonkey

Announcements

Before we get to the chat summary, I want to make an announcement first, for the people that don’t attend the Slack channel.

GitHub repositories have moved

The servehappy and servehappy-resources repositories have been moved from the temporary wp-core-php GitHub organization to the official WordPress GitHub organization.

Here are the links to the new locations (the old locations should redirect to these):

Chat Summary

We started with discussing the sections and the section content of the landing page again. We iterated over a couple of different versions of the first section, which we had been calling the Why you want to read this section.

What we came up with was to consider three different approaches to phrasing this first section, with the understanding that:

  • the #marketing team will help us find the best way to write the actual copy for each approach;
  • the different approaches can be A/B tested to optimize them and find the most effective one.

Here’s a preliminary summary of the three approaches we went with:

  1. The “technology” approach:

    One of the important software components that enables WordPress to run on all sites is PHP. On this page you will learn what PHP is, why being on the latest version of PHP is so important for your site, and some steps you can take to make sure your site has the latest PHP version in use.

  2. The “detected issue” approach:

    Your website might not be operating at its full potential. This page will tell you about an important issue we have detected and how to go about to resolve it (no jargon!). Let’s talk about what PHP is, and why you might need to update it.

  3. The “probability” approach:

    You want your site operating at its full potential. Is it? As many as 4.5% of sites running WordPress are not. This page will help you determine if your site is one of them and how you can fix that.

Then we went on to discuss the distribution of the remaining content we need across the different sections. We identified the individual goals that the content needs to achieve and built a preliminary overview:

  • A. What is PHP?
    1. explain what PHP is
  • B. Why PHP version matters to you as a site owner
    1. explain what the problem with old PHP is
    2. explain the benefits of new PHP
    3. explain what an update is
    4. explain why WordPress can’t deal with this problem itself
  • C. How to upgrade PHP for your website
    1. list the potential problems an update might cause
    2. provide steps to prepare an update to PHP
    3. give instructions on updating PHP
    4. help troubleshoot issues

Again, the exact ordering and the copy to use should be discussed with the #marketing team. For the C. section, we are considering a UI component similar to an accordion, to avoid people being overwhelmed with the amount of content on the page. This might need to be discussed with the #accessibility team first, though.

Concerns were raised about how useful the project board on GitHub is for discussing something like the overall structure here. This problem is the reason why we have a “Meta” section on the project board that can contain issues to discuss overarching topics like the main sections.

Finally, it was confirmed once again that the project is meant to be translated in as many languages as possible. However, we only want to start working on the translations once the content is somewhat finalized, to avoid wasted effort.

Next week’s meeting

The next meeting will take place on Monday, 29 August 2017, 20:00 CEST, as always in #core-php, and its agenda will be to finalize the section work we’ve been doing so far and to get it into a shape we feel good about presenting to the #marketing team. 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 – August 14th

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: @afragen @desrosj @dimadin @drewapicture @flixos90 @jdgrimes @mikeschroder @nerrad @pross @schlessera @sergey @spacedmonkey @stevenkword @tfrommen

Chat Summary

The agenda for this week’s meeting to continue our efforts for the planned .org page to educate and convine mainly non-technical users about the benefits and necessity of PHP upgrades. Here are the highlights from the discussion:

  • There is now a new GitHub organization for the core PHP team, and a repository as a central location for the work towards the new page, which now lives under the temporary codename “servehappy”.
  • There’s furthermore an additional repository as a collection of third-party resources on the topic, such as articles or hosting-/tool-specific upgrade tutorials. Some of those will be good references and inspiration for our own version.
  • Everyone is welcome to contribute to both of those.
    • The primary task for the “servehappy” repository will be to open issues for the benefits we’ve come up with over the past few weeks, and discuss them one by one, whether they qualify for the page and how they can be framed in the most convincing way. A project board exists to get a quick overview about where each of those benefits stands in terms of workflow.
    • Any useful resource found about the topic should be added to the resources repository. This can happen in a very intuitive way, as you don’t even have to fork the repository to enhance it. Simply use one of the file editing buttons to make your changes, and create a pull-request from it. Enhancing the resources list is much appreciated too.
  • @nerrad suggested to also have issues for the different sections planned for the page (see last week’s recap for the proposed outline). A project view for these has been created since, which is a work in progress.
  • While we call the first section “What we want from you”, this title should only be used for ourselves to remind us what we’re using the page for and that this should be conveyed in the first section. However, that should be phrased in a way so that the site visitor does not feel put under pressure. It should go more into a direction like “Once you’ve read this page, you will want this too”.
  • The section “What should you need to know before doing an update?” must not unnecessarily make the user worry. Let’s highlight possible issues, but not overestimate them. People should see upgrading as a good thing, and we should point them at how they can determine whether their sites are ready.
  • Users should briefly be educated about the natural requirement of software updates, and that PHP is just the same. Phrases like “Now you need to do this every … months” must not be used, but a more general way that highlights the benefits of staying up to date and that, in order to do so, upgrades are occasionally required. If site owners are not made aware of this, the next upgrade request will be just as painful as this one.
  • An important goal of the page is to improve the distribution of the PHP versions as collected by the installation/update stats of WordPress.org.
  • At the end of the chat, we talked about PHP versions a bit, and which jumps were more critical or problematic than others.@mikeschroder highlighted that the jump from 5.2 to 5.3 was actually one of the hardest, while 5.6 to 7.0 was quite smooth. @schlessera added that 7.1 is a bit more problematic than 7.0 because of some of the changes involved.@mikeschroder will try to see if they still have data at DreamHost about the 5.2->5.3 jump that they could share. He furthermore reminded ask to ask more of these questions in the #hosting-community channel.

The takeaway of this week was that we should finally get in touch with the marketing team. Let’s work on adding a brief one or two sentences for each of the sections that were proposed in last week’s meeting to give them more context, to provide a better foundation for the #marketing team. This can happen via GitHub. More benefits should be added as issues on GitHub as well.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, as always in #core-php, and its agenda will be to continue discussing the page outline, benefits and further coordination. If you have suggestions 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 – August 7th

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: @chetansatasiya @clorith @desrosj @flixos90 @tfrommen @jdgrimes @kelseyfecho @mikelking @mte90 @nerrad @schlessera @screamingdev @sergey @sudar @xkon

Chat Summary

@flixos90 started by letting everyone know that he will be alternating with @schlessera in running the weekly meeting.

As we had split up the discussion into two main topics during the last PHP meeting, we wanted to concentrate on one topic only this time: making progress on providing the informational page that should educate people about PHP updates.

As we noticed that some benefits we had identified in prior meetings only applied to specific subsets of our target audience, we discussed the need to more explicitly subdivide the audience into individual segments, and adapt the language we’re using for each of these. We distilled the following list of main segments to begin with: site-owners, developers, hosters.

We agreed that it does not make much sense to have separate landing pages for each and that we’d rather have one single default landing page for the site-owners, with links to other sections/subpages for the other segments. The reason for that is that the page should start with adapted language for the least tech-savvy group, with additional details as needed, so as not to overwhelm the page’s visitors.

For site-owners, we also want to provide a convenient email template that they can send to their hosting provider to get an update. We could potentially discuss this with hosting companies to know what their preferred ways of contacting them about updates are, to make the process as frictionless (and cost-effective) as possible. This would mean that the provided template could change depending on what hosting provider was detected for the current site.

The list of benefits should be done as real copywriting, as we are basically building a sales page, trying to sell “updating PHP” to the site-owners that have to pay the price for that. The page should use proper marketing language, convincing stats and diagrams, and story-telling techniques to finally end in a call to action.

The page we’re building should also include a section on the more tricky technical aspects of updating PHP, like checking plugin compatibility and troubleshooting issues.

Given all of the above, we decided it is time to contact both the #marketing as well as the #hosting-community teams/channels to ask for help.

And although we decided we need to deal with different audiences and adapt the page to each of them, we also realized that this multiplies the amount of work to be done. In order to get first results as quickly as possible, we agreed to concentrate on initially building the section for site-owners first, and adding the other segments afterward.

As for the structure of the page, we discussed a first general layout like the following:

  1. What we want from you
  2. Call to action
  3. What is PHP?
  4. Why do you need an update?
  5. What should you need to know before doing an update?
  6. How do you do an update?
  7. Call to action

The main location to persist decisions, for now, is Meta Trac ticket 2996. However, we’ll prepare some shared document space to gather all intermediate materials.

Next week’s meeting

The next meeting will take place on Monday, 14 August 2017, 20:00 CEST, as always in #core-php, and its agenda will be to discuss the more organizational aspects of making progress. We want to agree on one tool where we can collaborate on archiving our current results and on producing first deliverables. 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 – July 31st

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: @desrosj @drewapicture @flixos90 @jdgrimes @mikeschroder @nerrad @schlessera @screamingdev @sergey @sobak @spacedmonkey @swissspidy @xkon

Chat Summary

There were two main topics that were discussed during the meeting. The first one was the planned .org page that would inform users about PHP, its outdated version problem connected with WordPress and how to upgrade. Here are the thoughts shared about such a page:

  • Once ready, it should be ensured that polyglots learn about that page and translate it into the respective languages for each rosetta site.
  • The page should be aimed at users and not contain technical details that would bore people. It should be on point, describe the problems an outdated version causes as well as the benefits of a more modern version in easy-to-understand language. Images and graphics could be used to present key takeaways at one glance.
  • There are obviously several benefits when using a modern PHP version, however most of them are not immediate and thus might have a hard time convincing a user to upgrade. We need to spend more time on looking for immediate benefits, such as improved performance (PHP 7+) or compatibility with specific popular plugins that require a higher PHP version.
  • The marketing team’s help with this would be much appreciated.
  • Catch phrases like “xy% upgraded their PHP, when do you?”, “WordPress is more … with the latest PHP” and altruisms like “WordPress can be much more better when you …” could be used on the page.
  • Most hosts that still have their users on unsupported versions are probably just cutting costs and do not care about much else. However, officially supporting minimum PHP requirements for plugins and linking administrators to the .org page could cause several support tickets, organically increasing pressure on those hosts. They may very well upgrade once they notice a significant amount of people asking.
  • An article by WP Engine was highlighted on how they first introduced PHP 7 support. They created a compatibility checker plugin, which is something that could benefit core in general for such cases.
  • The WordPress requirements page already has a few bits and pieces that we might be able to reuse. Eventually that page should also link to the new page we’re working on.
  • Searching for further material on PHP and its upgrades and how other parties dealt with it should be the primary objective for everyone interested in such a page. Others have come before WordPress core, so we need to learn from their experiences, possibly their mistakes and use their content as inspiration.

The second topic that came up during the discussion was to plan a more long-term strategy for version upgrades beyond the jump from PHP 5.2 to 5.3. Without such a strategy, we will run into the same problem over and over again.

  • Such a roadmap should eventually be placed on the PHP information page on .org (see above). It will make the strategic reasoning much clearer how and what exactly to communicate.
  • There do not need to be any dates on it, but it should provide a long-term overview on when WordPress is planning to raise the minimum requirement.
  • A long-term roadmap gives people enough time to prepare. While it was a less critical step than upgrading PHP, this year’s decision to drop support for IE8 came pretty much out of the blue, and this must not be the case for any PHP requirement bump.
  • We must ensure that the strategy is based on our experience with upgrading PHP versions, investigations and statistics. The roadmap should be dependent on when people can reasonably upgrade, not the other way around.
  • It is very likely going to be a slow process, but even then, having somewhat of a schedule will make hosts, and possibly even users that visit the page, aware of the long-term upgrading strategy.
  • The strategy should possibly be to slowly catch up with PHP development. While PHP’s version upgrades are rapid, core’s support policy should at least somewhat depend on it, for example with something like supporting versions 2 years longer. To get there, we will need to carefully plan reasonable bumps over a long transition period to slowly close the (much bigger) gap that there is now. Of course it will take a while until a goal like this can be achieved – but even if it takes 10 years or more, a roadmap will communicate this way in advance for both WordPress users and developers as well.
  • It can be really long-term, as long as it’s a systematic and reasonable approach.
  • At some point, we will get to where PHP is right now. It is in our favor that PHP has matured and the version differences become smaller, which makes it much easier to change the version installed on a hoster’s server.
  • The first upgrade (from PHP 5.2 to 5.3) is certainly going to be the toughest one, both because we first need to do the heavy lifting of informing generally and also because the enhancements from 5.3 over 5.2 are among the most significant between two PHP versions, for example there was some pretty big breakage with non WordPress code on Dreamhost when they made the switch. The following versions were much easier.

As a result of the discussion, we figured that we now have two primary goals: The primary goal is still accelerating the current upgrading path (through the aforementioned .org page, plugin PHP version requirements etc.). The other important goal is to investigate a reasonable long-term strategy for PHP requirement bumps.

Next week’s meeting

The next meeting will take place on Monday 18:00 UTC, as always in #core-php, and its agenda will be to continue discussing the two topics, particularly how to proceed with them as they are quite different. If you have suggestions 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