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

PHP Meeting Recap – October 23rd

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: @charliespider @davidvee @jdgrimes @joyously @nerrad @schlessera

Chat Summary

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

We started by discussing the freshly introduced topic “Find replacements for incompatible plugins“, with the following observations:

  • Some plugins can be easily fixed in a matter of minutes by a developer. This is out of reach for most end users, though.
  • Replacing a broken plugin involves not only finding a suitable replacement but also migrating existing data between plugins. The involved effort can be quite substantial and deeply technical.
  • Providing actual recommendations on what plugin replacements to use is once again difficult to do in an “official capacity”, as it has a direct impact on the market around plugins.
  • Current search in the plugin repository is inadequate for this task. It needs more filtering / tagging / categorization tools (without just collecting spam of course) (meta trac #2753), but it would also profit from an actual “Similar plugins” functionality (meta trac #3208).
  • To avoid end users hitting a lot of incompatible plugins, we should investigate running the compatibility scanner over the entire plugin repository and directly email the plugin authors. Some of these issues might then already be taken care of at the time the end users run their own checks.
  • We have to make sure we don’t inadvertently communicate a message along the lines of “most free plugins are broken, WordPress can only reliably be used with premium plugins”.

We followed this by discussing how to best approach the #marketing team. We opted to create a Google Doc that will contain a distilled version of all of our remarks so that we have something usable to provide as a starting point. We’ll collaborate on filling out this document, to have it represent a shortened overview of what we gathered in the “Before Upgrading PHP” section on our issue tracker.

Next week’s meeting

The next meeting will take place on Monday, October 30, 2017 at 18:00 UTC, as always in #core-php, and its agenda will be to go over 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-php, #php, #summary

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