PHP Meeting Recap – January 29th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

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

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

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

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

Where should the “servehappy” information page  live?

Here’s some factors that can influence the location:

Factor: Privacy

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

Some related background:

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

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

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

Factor: Maintainability

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

Factor: User Trust

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

Proposed locations for the Page:

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

External Site:

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

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

WordPress Core (powered by WordPress.org API)

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

Next week’s meeting

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

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

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

#php, #summary