Title: PHP Meeting Recap – January 29th
Author: Darren Ethier (nerrad)
Published: January 30, 2018
Last modified: September 12, 2018

---

 [  ](https://profiles.wordpress.org/nerrad/) [Darren Ethier (nerrad)](https://profiles.wordpress.org/nerrad/)
6:55 pm _on_ January 30, 2018     
Tags: [core-php ( 68 )](https://make.wordpress.org/core/tag/core-php/),
[PHP ( 79 )](https://make.wordpress.org/core/tag/php/), [summary ( 981 )](https://make.wordpress.org/core/tag/summary/)

# PHP Meeting Recap – January 29th

This recap is a summary of our previous PHPPHP The web scripting language in which
WordPress is primarily architected. WordPress requires PHP 7.4 or higher 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](https://wordpress.slack.com/archives/C60K3MP2Q/p1517242030000103)
here.

## Chat Summary

The agenda for today was to discuss UXUX User experience mockups and the hosting
situation.  However, [@jaymanpandya](https://profiles.wordpress.org/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](https://profiles.wordpress.org/azaozz/)
was present at the meeting and we spent the entire meeting interacting with him 
with regards to [this comment](https://make.wordpress.org/core/2018/01/29/php-meeting-recap-january-22nd/#comment-33394)
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](https://make.wordpress.org/core/2018/01/09/servehappy-roadmap/),
> the [project readme](https://github.com/WordPress/servehappy), the [related trac ticket](https://meta.trac.wordpress.org/ticket/2996)
> and see the [current draft](https://github.com/WordPress/servehappy/blob/master/DRAFT.md).
> 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](https://core.trac.wordpress.org/ticket/41191) 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
   pluginPlugin A plugin is a piece of software containing a group of functions 
   that can be added to a WordPress website. They can extend functionality or add
   new features to your WordPress websites. WordPress plugins are written in the
   PHP programming language and integrate seamlessly with WordPress. These can be
   free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
   or can be cost-based plugin from a third-party. 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](https://profiles.wordpress.org/schlessera/))
 * I see it similar to how you prepare a link that contains the language as a URLURL
   A specific web address of a website or web page on the Internet, such as a website’s
   URL www.wordpress.org argument. Don’t think that’s a privacy issue (But IANAL).(
   [@schlessera](https://profiles.wordpress.org/schlessera/))
 * access logs can link ip/referring domain to PHP version… ([@nerrad](https://profiles.wordpress.org/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](https://profiles.wordpress.org/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-adminadmin (and super 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 coreCore Core is the set of software required to run
WordPress. The Core Development Team builds WordPress. 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 codexWordPress
Codex Living online manual to WordPress.org [https://codex.wordpress.org/](https://codex.wordpress.org/),
or as a page on WordPress.orgWordPress.org The community site where WordPress code
is created and shared by the users. This is where you can download the source code
for WordPress core, plugins and themes as well as the central location for community
conversations and organization. [https://wordpress.org/](https://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](https://profiles.wordpress.org/schlessera/))
 * Seemed to be general consensus that maintaining the content would be easier in
   this location.

#### WordPress Core (powered by WordPress.org APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.)

 * 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](https://profiles.wordpress.org/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](https://profiles.wordpress.org/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](https://profiles.wordpress.org/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](https://profiles.wordpress.org/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](https://profiles.wordpress.org/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](https://profiles.wordpress.org/flixos90/))
 * We should build the API in a way though that the content is easily editable without
   any metaMeta Meta is a term that refers to the inside workings of a group. For
   us, this is the team that works on internal WordPress sites like WordCamp Central
   and Make WordPress. tracTrac An open source project by Edgewall Software that
   serves as a bug tracker and project management tool for WordPress. interaction
   required. Where could that happen? Which backend of a .org site could power that
   API? ([@flixos90](https://profiles.wordpress.org/flixos90/))

## Next week’s meeting

 * Next meeting will take place on [Monday February 5, 16:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180205T1600)
   in [#core-php](https://make.wordpress.org/core/tag/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](https://make.wordpress.org/core/tag/php/), [#summary](https://make.wordpress.org/core/tag/summary/)

### Share this:

 * [  Threads ](https://make.wordpress.org/core/2018/01/30/php-meeting-recap-january-29th/?share=threads)
 * [  Mastodon ](https://make.wordpress.org/core/2018/01/30/php-meeting-recap-january-29th/?share=mastodon)
 * [  Bluesky ](https://make.wordpress.org/core/2018/01/30/php-meeting-recap-january-29th/?share=bluesky)
 * [  X ](https://make.wordpress.org/core/2018/01/30/php-meeting-recap-january-29th/?share=x)
 * [  Facebook ](https://make.wordpress.org/core/2018/01/30/php-meeting-recap-january-29th/?share=facebook)
 * [  LinkedIn ](https://make.wordpress.org/core/2018/01/30/php-meeting-recap-january-29th/?share=linkedin)

 1. ![](https://secure.gravatar.com/avatar/73c1045212929211deda7262005831319397c68d340a8c41d53633b3f7e7f129?
    s=32&d=mm&r=g)
 2.  [Andrew Ozz](https://profiles.wordpress.org/azaozz/)  5:59 pm _on_ January 31,
    2018
 3. > We should build the APIAPI An API or Application Programming Interface is a software
    > intermediary that allows programs to interact with each other and share data 
    > in limited, clearly defined ways. in a way though that the content is easily 
    > editable without any metaMeta Meta is a term that refers to the inside workings
    > of a group. For us, this is the team that works on internal WordPress sites like
    > WordCamp Central and Make WordPress. tracTrac An open source project by Edgewall
    > Software that serves as a bug tracker and project management tool for WordPress.
    > interaction required. Where could that happen? Which backend of a .org site could
    > power that API?
 4. As mentioned in the chat: not sure if that’s possible. WordPress.orgWordPress.org
    The community site where WordPress code is created and shared by the users. This
    is where you can download the source code for WordPress core, plugins and themes
    as well as the central location for community conversations and organization. [https://wordpress.org/](https://wordpress.org/),
    the WordPress API, and all associated sites are under version controlversion control
    A version control system keeps track of the source code and revisions to the source
    code. WordPress uses Subversion (SVN) for version control, with Git mirrors for
    most repositories. and the meta trac is the “door” to updating them. This is done
    for accountability, code/patchpatch A special text file that describes changes 
    to code, by identifying the files and lines which are added, removed, and altered.
    It may also be referred to as a **diff**. A patch can be _applied_ to a codebase
    for testing. reviews, etc.
 5. I’m actually more concerned about who is going to gather and update the data about**“
    all”** hosting companies and the links to their help pages for upgrading PHPPHP
    The web scripting language in which WordPress is primarily architected. WordPress
    requires PHP 7.4 or higher, and of course if they will be willing to do it for 
    the next couple of years 🙂

Comments are closed.

# Post navigation

[← Core editor team meeting time change](https://make.wordpress.org/core/2018/01/29/core-editor-team-meeting-time-change/)

[WordPress 4.9.3 release pushed to February 5th →](https://make.wordpress.org/core/2018/01/31/wordpress-4-9-3-release-pushed-to-february-5th/)