Dev Chat Summary: February 7th (4.9.5 week 1)

This post summarizes the dev chat meeting from February 7th (agenda, Slack archive).

4.9.3 + 4.9.4 update

  • 4.9.3 went out on Monday, 4.9.4 went out on Tuesday; note technical details behind 4.9.4
  • Note final paragraph from the 4.9.4 technical details post:
    • What we’re doing to prevent this happening again We’ll be making a follow up post after we’ve been able to determine how to ensure that this never happens again. We don’t like bugs in WordPress any more than you do, and we’ll be taking steps to both increase automated coverage of our updates and improve tools to aid in the detection of similar bugs before they become an issue in the future.
  • If you have ideas, solutions, or are able to support increasing “automated coverage of our updates” and improving “tools to aid in the detection of similar bugs” then please gather those and add them to the pending post on this topic.
  • @jbpaul17 to see if any process-related changes might help
  • @sergey also asked for ideas on how we can improve the quality and consistency of our code reviews
  • @helen spoke with @dd32 and will look into a way to test auto-updates
  • @desrosj noted that automating some parts of the release process might help

Updates from focus leads and component maintainers

General announcements

  • Comment thread from today’s agenda post on topic of security not able to be addressed as no one from the Security team was present, but @aaroncampbell provided a response ahead of time:
    • Okay, so this is the DoS issue with load-scripts.php and load-styles.php: Basically, the best mitigation for this is at the network level. Hosts and WAFs can rate limit this in a way that makes a lot more sense than anything WordPress can do. Caching would also be extremely useful in this case. Something that we _could_ do is limit the number of scripts that could be loaded at once with those, but the problem with that is all it does is reduce the load by some relatively marginal amount.
  • @leemon asks for review on #43226; @drewapicture to take a look
  • @binarymoon asks for review on #38545; looking for someone to give feedback and get to an agreement so this ticket can move forward
  • @joyously asked whether New Contributor meeting was still occurring; @desrosj to speak with other facilitators and get the meetings re-started
  • @williampatton shared insights into his experience being a deputy release lead on 4.9.3; encourages others to contribute as leads, noting core commit access is not required, recommends pairing with experienced lead; highlighted permissions issues that should be resolved; thankful for support from others during the release process; will help elaborate on minor release handbook page
  • @chanthaboune highlighted the need to “lessen that cognitive load for new/learning release leads”, need to call out contingencies and what’s time-specific; in general how can we make the contribution process easier

Next meeting

The next meeting will take place on February 14, 2018 at 21:00 UTC / February 14, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-3, #4-9-4, #4-9-5, #core, #core-editor, #core-media, #dev-chat, #security, #summary

Dev Chat Agenda: February 7th (4.9.5 week 1)

This is the agenda for the weekly dev meeting on February 7, 2018 at 21:00 UTC / February 7, 2018 at 21:00 UTC:

  • 4.9.3 + 4.9.4 update
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-5, #agenda, #core, #dev-chat

Media Meeting Recap – February 1, 2018


This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, February 1, 2018 at 1900 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

@antpb @blobfolio @desrosj @karmatosed @mikeschroder @postphotos

Transcript: Read on Slack


  • The best way to follow along with media related Gutenberg items is the media label in GitHub.
  • Repository milestones have been re-arranged to make it easier to see what is going on.
  • Milestone #33 is coming up. There are two media issues, but the primary focus is: Add block playlist. A decision was reached to punt this issue to 2.3. @antpb needs some background on the mediaElementobject is used for the media player.

4.9.4 (now 4.9.5) Tickets

The next portion of the meeting was dedicated to going through blessed tickets in the next minor milestone. All three were deemed in a good place with good direction.

  • #42968 – Media: Grid View: new upload, file is in the wrong position in the grid until after upload is complete
  • #43201 – PHP Warning: count(): Parameter must be an array or an object that implements Countable in /wp-includes/media.php on line 1206
  • #42724 – Options Media page hides breaks on desktop

5.0 Tickets

The next part of the meeting was spent on blessed tickets in the next major milestone (5.0).

#42919 – Unable to upload files with the AAC extension

Discussion around whether AAC files could be embedded lead to the realization that AAC also needs to be added to `wp_get_audio_extensions()`. Firefox appears to have a few issues with AAC. Some testing needs to be done to see if this can be done in the same ticket, or if a new one is more appropriate. @desrosj will do some digging.

The following tickets need a combination of code review and approval:

  • #40921 – Inconsistent Handling of mp4 by Audio Widget
  • #42463: Poor Description of add_image_size Params
  • #42017: Parse the creation date out of uploaded audio files

5.0 Suggested Tickets

#9257 – EXIF GPS data

Has good direction, but needs some feedback to make any adjustments. #42479 was closed as a duplicate on the premise that there is no GPS information in audio/video besides any in the associated image. In his initial testing, @desrosj remembers there being some GPS information on video files, but more testing is needed before it can be re-opened. Files from popular devices would need to be provided as well.

#43046has_image_size() returns false for Core image sizes

Backwards compatibility issues need to be fully explored for this ticket. At minimum, the inline documentation should be updated to more accurately reflect what is happening in the function. At maximum, a new boolean parameter could be added indicating whether core image sizes should be included in the list checked against. An example of where this may be very useful is preventing issues when a plugin or theme removes a core image size (if this is possible – needs research).

Next Meeting

The next #core-media meeting is set for Thursday, February 8, 2018 at 1900 UTC. Hope to see you there!

WordPress 4.9.4 Release – The technical details

Today we’ve released WordPress 4.9.4, the day following WordPress 4.9.3.

WordPress 4.9.4 is the first minor release of WordPress in over four years since WordPress 3.7 was released where not all users will be receiving an automatic update.

This isn’t by choice – a bug went undetected during the 4.9.3 development cycle, and was only discovered hours after 4.9.3’s release. The bug causes a PHP Fatal error to be triggered when WordPress attempts to update itself.

Unfortunately this means that WordPress Administrators will need to proceed with a WordPress update themselves, through the WordPress Administration panel (Just hit Update Now under Updates), using WP-CLI, or via FTP. Hosts who apply updates automatically on their customers behalf will also be able to continue to update sites as normal.

What Happened? #43103-core aimed to reduce the number of API calls which get made when the autoupdate cron task is run. Unfortunately due to human error, the final commit didn’t have the intended effect, and instead triggers a fatal error as not all of the dependancies of find_core_auto_update() are met. For whatever reason, the fatal error wasn’t discovered before 4.9.3’s release – it was a few hours after release when discovered.

Ways to update:

  • Through the WordPress Administration area: Simply visit your WordPress Dashboard → Updates and click “Update Now.”
  • With WP-CLI: If you have command line access to WordPress, and WP-CLI installed, wp core update will update your site just as quickly as before.
  • Manually by FTP: If you prefer, you can update by Downloading the latest ZIP, and using FTP to upload it to your site. The only changed files expected are wp-includes/update.php & wp-includes/version.php.
  • With PHP: If you have command line access, you can also update WordPress simply by running wp_maybe_auto_update() inside of WordPress, for example: php -r 'include "wp-load.php"; wp_maybe_auto_update();'. This is also how we suggest hosts who don’t have WP-CLI installed proceed with automated updates for their customers.

As noted above, only two files changed in this release – wp-includes/update.php & wp-includes/version.php.

Are there any security implications? WordPress 4.9.3 and 4.9.4 do not include any security fixes, however, in order for WordPress to receive future security updates automatically sites will first need to be updated to 4.9.4.

What we’re doing to prevent this happening again We’ll be making a follow up post after we’ve been able to determine how to ensure that this never happens again. We don’t like bugs in WordPress any more than you do, and we’ll be taking steps to both increase automated coverage of our updates and improve tools to aid in the detection of similar bugs before they become an issue in the future.

#4-9-4, #43103-core

Dev Chat Summary: January 31st (4.9.3 week 3)

This post summarizes the dev chat meeting from January 31st (agenda, Slack archive).

4.9.3 update

Updates from focus leads and component maintainers


  • Question from @azaozz in latest meeting: What if the PHP education page (codename "servehappy") was not on any .org-related website, but inside of core?
  • We'd like to ask for feedback on this, what are all your initial feelings on that? Note that this is separate from the prompt for the user to switch the PHP version in their hosting account.
  • Some considerations:
    • The main condition for this to happen is to have the entire content powered by the .org API. The content will be highly dynamic and may need adjustments regularly, so we must not be dependent on core releases to change it.
    • A new API endpoint would need to be built for that purpose that should send the content of all sections of the page, to some degree targeted to the current request. Parameters like the PHP version active, plugin slug (in case the user is sent to the page because a plugin requires a higher PHP version), data about the host (if available), would be part of the request. This would allow the content to target the user's problem as well as possible.
    • All content that endpoint returns should not be hard-coded, but easily manageable through a backend (maybe a special section in
    • How is it possible to change the .org API? Who has access? We'd need to figure out how the process of working on that could be streamlined.
    • Summary of thoughts from PHP meeting recap
  • Next step is for the Servehappy team (including @azaozz) to discuss this during the next PHP meeting (on Monday 16:00 UTC) and come back with a recommendation

General announcements

  • @afercia uncertain about what can go in a minor release, specifically about fixes or small enhancements that require a dev note given that minor releases auto-update
    • Changes that require a dev note in a minor release, with such a short notice, don’t give plugin and theme authors the time to update.
    • As further changes to the minor release policy, best to have recommendation prepared for upcoming devchat

Next meeting

The next meeting will take place on February 7, 2018 at 21:00 UTC / February 7, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-3, #core, #core-editor, #core-php, #dev-chat, #documentation, #js, #minor-releases, #servehappy, #summary

WordPress 4.9.3 Release Candidate

WordPress 4.9.3 maintenance release fixes 34 issues reported against 4.9 and is scheduled for February 5th. The release candidate is now ready for testing.

Thus far WordPress 4.9 has been downloaded more than 34 million times since its release on November 16, 2017. Please help us by testing this RC to ensure 4.9.3 fixes the reported issues and does not introduce any new ones.

JSHint Removal

One of the important changes is the removal of JSHint from code editor due to its GPL-incompatible license. If your code relies upon JSHint from core, you should update it to include a copy of JSHint. See ticket #42850 for more details.

Changes Since 4.9.3 Beta

Code Editor

  • #42586 Add Ctrl/Cmd+F as aliases for persistent search for more intuitive behaviour.


  • #42450 Ensure customize_autosaved requests only use revision of logged-in user.
  • #42495 Ensure media playlists get initialized after selective refresh; expose new wp.playlist.initialize() API.
  • #42658 Ensure heartbeat keeps changeset locked when in branching mode.
  • #42991 Include nav menu item for Home custom link in search results for "Home".


  • #39859 Avoid page scrolling when opening the media modal.

For a full list of changes see the 4.9.3 Beta posttickets closed, and the changesets committed.


JS docs initiative: Add inline-docs for JavaScript!

We are pleased to announce the JS docs initiative! It’s an ongoing effort to get all JavaScript files in WordPress well-documented and make this documentation easily accessible. JavaScript development within WordPress core is speeding up fast, and better documentation will help this work progress as smoothly as possible.

In the last few months, we’ve fixed the JavaScript documentation standards by discussing sticking points in the #core-js weekly meeting. The structural documentation of all the Backbone classes has also been fixed (major props to @herregroen for fixing this).

At the bottom is a list of every first-party JavaScript file in core. Files with a checkmark have been patched and are considered completed. Files marked with (username #xxxxx) are already claimed, and being worked on.

Directly below is the process we’re using to make sure each of these files can get patched swiftly with no duplicated nor wasted efforts.

How to contribute

  1. Familiarize yourself with the JavaScript documentation standard, as well as the formatting guidelines and documenting tips.
  2. Check the list first to make sure the file you want to work on hasn’t already been claimed.
  3. Update your local WordPress SVN (use svn up) or Git repo (use git pull) to the latest version of WordPress trunk.
  4. Create a new ticket on Trac for the file.
    • Format the title as “JSDoc: path/to/file.js”.
    • The Type should be “defect (bug)”.
    • Assign the ticket to the component the file is associated with.
    • Leave the Version blank.
    • Add the docs and javascript focuses.
  5. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN or Git checkout.
  6. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

We’d like to welcome everyone to start contributing inline documentation! You can start contributing by picking a file from the list of unclaimed files below and claiming it in the comments. Please also see the JS docs handbook page for a step by step guide on how to get started.

Note: Note: To give everyone a chance to claim a file and to ensure the work proceeds as quickly as possible, please only work on one file at a time.

Determining the since version

We use JSDoc’s @since tag to indicate when a particular function was added to WordPress core. When you are documenting a function, you will also need to identify when that function was first introduced.

The recommended tool to use when searching for the version something was added to WordPress is svn blame. An additional resource for hooks is the WordPress Hooks Database. If, after using these tools, the version number cannot be determined, use @since Unknown.

If you use the git repository of WordPress you can also use git to determine the @since version. Either use git blame or the GitHub blame function. Once you have the commit hash which introduced a piece of code you can find out the version by using git tag --contains [commit-hash]. This will list all versions a certain commit has been shipped in. The lowest version is then what you put after the @since annotation.

Note: Make sure that the commit you found it the actual commit where a piece of code was introduced. JavaScript files have been moved around a lot in the past, so make sure to take that into account.

Note: All @since tags should follow the three digit x.x.x format.

Keeping Discussions Focused:

Any discussion about the specifics of a patch itself should happen on Trac. Any discussion about the broader scope of what we’re trying to do should take place during the weekly devchat. That’s either #core-js or #core.

Files needing patches:

Checked files are completed, marked files are claimed

  • wp-admin/js/accordion.js
  • wp-admin/js/bookmarklet.js
  • wp-admin/js/color-picker.js
  • wp-admin/js/comment.js
  • wp-admin/js/common.js
  • wp-admin/js/custom-background.js
  • wp-admin/js/custom-header.js
  • wp-admin/js/customize-controls.js
  • wp-admin/js/customize-nav-menus.js
  • wp-admin/js/customize-widgets.js
  • wp-admin/js/edit-comments.js (@atimmer)
  • wp-admin/js/editor-expand.js
  • wp-admin/js/editor.js
  • wp-admin/js/gallery.js (@hunkriyaz)
  • wp-admin/js/image-edit.js
  • wp-admin/js/inline-edit-post.js
  • wp-admin/js/inline-edit-tax.js
  • wp-admin/js/language-chooser.js
  • wp-admin/js/link.js
  • wp-admin/js/media-gallery.js
  • wp-admin/js/media-upload.js
  • wp-admin/js/media.js
  • wp-admin/js/nav-menu.js
  • wp-admin/js/password-strength-meter.js
  • wp-admin/js/plugin-install.js
  • wp-admin/js/post.js
  • wp-admin/js/postbox.js
  • wp-admin/js/press-this.js
  • wp-admin/js/revisions.js
  • wp-admin/js/set-post-thumbnail.js
  • wp-admin/js/svg-painter.js
  • wp-admin/js/tags-box.js
  • wp-admin/js/tags.js
  • wp-admin/js/theme.js
  • wp-admin/js/updates.js
  • wp-admin/js/user-profile.js
  • wp-admin/js/user-suggest.js (@timhavinga)
  • wp-admin/js/widgets.js
  • wp-admin/js/word-count.js
  • wp-admin/js/wp-fullscreen-stub.js
  • wp-admin/js/xfn.js (@kapteinbluf)
  • wp-includes/js/admin-bar.js
  • wp-includes/js/autosave.js
  • wp-includes/js/comment-reply.js
  • wp-includes/js/customize-base.js
  • wp-includes/js/customize-loader.js
  • wp-includes/js/customize-models.js
  • wp-includes/js/customize-preview-nav-menus.js
  • wp-includes/js/customize-preview-widgets.js
  • wp-includes/js/customize-preview.js
  • wp-includes/js/customize-selective-refresh.js
  • wp-includes/js/customize-views.js
  • wp-includes/js/dashboard.js
  • wp-includes/js/heartbeat.js
  • wp-includes/js/mce-view.js
  • wp-includes/js/media-audiovideo.js
  • wp-includes/js/media-editor.js
  • wp-includes/js/media-grid.js
  • wp-includes/js/media-models.js
  • wp-includes/js/media-views.js
  • wp-includes/js/media/audiovideo.manifest.js
  • wp-includes/js/media/controllers/audio-details.js
  • wp-includes/js/media/controllers/collection-add.js
  • wp-includes/js/media/controllers/collection-edit.js
  • wp-includes/js/media/controllers/cropper.js
  • wp-includes/js/media/controllers/customize-image-cropper.js
  • wp-includes/js/media/controllers/edit-attachment-metadata.js
  • wp-includes/js/media/controllers/edit-image.js
  • wp-includes/js/media/controllers/embed.js
  • wp-includes/js/media/controllers/featured-image.js
  • wp-includes/js/media/controllers/gallery-add.js (@atimmer)
  • wp-includes/js/media/controllers/gallery-edit.js (@manuelaugustin)
  • wp-includes/js/media/controllers/image-details.js
  • wp-includes/js/media/controllers/library.js
  • wp-includes/js/media/controllers/media-library.js
  • wp-includes/js/media/controllers/region.js
  • wp-includes/js/media/controllers/replace-image.js
  • wp-includes/js/media/controllers/site-icon-cropper.js
  • wp-includes/js/media/controllers/state-machine.js
  • wp-includes/js/media/controllers/state.js
  • wp-includes/js/media/controllers/video-details.js
  • wp-includes/js/media/grid.manifest.js
  • wp-includes/js/media/models.manifest.js
  • wp-includes/js/media/models/attachment.js
  • wp-includes/js/media/models/post-image.js
  • wp-includes/js/media/models/post-media.js
  • wp-includes/js/media/models/query.js
  • wp-includes/js/media/models/selection.js
  • wp-includes/js/media/routers/manage.js
  • wp-includes/js/media/utils/selection-sync.js
  • wp-includes/js/media/views.manifest.js
  • wp-includes/js/media/views/attachment-compat.js
  • wp-includes/js/media/views/attachment-filters.js
  • wp-includes/js/media/views/attachment-filters/all.js
  • wp-includes/js/media/views/attachment-filters/date.js
  • wp-includes/js/media/views/attachment-filters/uploaded.js
  • wp-includes/js/media/views/attachment.js
  • wp-includes/js/media/views/attachment/details-two-column.js
  • wp-includes/js/media/views/attachment/details.js (@maartenleenders)
  • wp-includes/js/media/views/attachment/edit-library.js
  • wp-includes/js/media/views/attachment/edit-selection.js
  • wp-includes/js/media/views/attachment/library.js
  • wp-includes/js/media/views/attachment/selection.js
  • wp-includes/js/media/views/attachments.js
  • wp-includes/js/media/views/attachments/browser.js
  • wp-includes/js/media/views/attachments/selection.js
  • wp-includes/js/media/views/audio-details.js
  • wp-includes/js/media/views/button-group.js
  • wp-includes/js/media/views/button.js
  • wp-includes/js/media/views/button/delete-selected-permanently.js
  • wp-includes/js/media/views/button/delete-selected.js
  • wp-includes/js/media/views/button/select-mode-toggle.js
  • wp-includes/js/media/views/cropper.js (@kapteinbluf)
  • wp-includes/js/media/views/edit-image-details.js
  • wp-includes/js/media/views/edit-image.js
  • wp-includes/js/media/views/embed.js
  • wp-includes/js/media/views/embed/image.js
  • wp-includes/js/media/views/embed/link.js
  • wp-includes/js/media/views/embed/url.js
  • wp-includes/js/media/views/focus-manager.js
  • wp-includes/js/media/views/frame.js
  • wp-includes/js/media/views/frame/audio-details.js
  • wp-includes/js/media/views/frame/edit-attachments.js
  • wp-includes/js/media/views/frame/image-details.js
  • wp-includes/js/media/views/frame/manage.js
  • wp-includes/js/media/views/frame/media-details.js
  • wp-includes/js/media/views/frame/post.js
  • wp-includes/js/media/views/frame/select.js
  • wp-includes/js/media/views/frame/video-details.js
  • wp-includes/js/media/views/iframe.js
  • wp-includes/js/media/views/image-details.js
  • wp-includes/js/media/views/label.js
  • wp-includes/js/media/views/media-details.js
  • wp-includes/js/media/views/media-frame.js
  • wp-includes/js/media/views/menu-item.js
  • wp-includes/js/media/views/menu.js
  • wp-includes/js/media/views/modal.js
  • wp-includes/js/media/views/priority-list.js
  • wp-includes/js/media/views/router-item.js
  • wp-includes/js/media/views/router.js
  • wp-includes/js/media/views/search.js
  • wp-includes/js/media/views/selection.js
  • wp-includes/js/media/views/settings.js
  • wp-includes/js/media/views/settings/attachment-display.js
  • wp-includes/js/media/views/settings/gallery.js
  • wp-includes/js/media/views/settings/playlist.js
  • wp-includes/js/media/views/sidebar.js
  • wp-includes/js/media/views/site-icon-cropper.js
  • wp-includes/js/media/views/site-icon-preview.js
  • wp-includes/js/media/views/spinner.js (@avillegasn)
  • wp-includes/js/media/views/toolbar.js
  • wp-includes/js/media/views/toolbar/embed.js
  • wp-includes/js/media/views/toolbar/select.js
  • wp-includes/js/media/views/uploader/editor.js
  • wp-includes/js/media/views/uploader/inline.js
  • wp-includes/js/media/views/uploader/status-error.js
  • wp-includes/js/media/views/uploader/status.js
  • wp-includes/js/media/views/uploader/window.js
  • wp-includes/js/media/views/video-details.js
  • wp-includes/js/media/views/view.js
  • wp-includes/js/quicktags.js
  • wp-includes/js/shortcode.js
  • wp-includes/js/tw-sack.js
  • wp-includes/js/utils.js
  • wp-includes/js/wp-a11y.js
  • wp-includes/js/wp-ajax-response.js
  • wp-includes/js/wp-api.js
  • wp-includes/js/wp-auth-check.js
  • wp-includes/js/wp-backbone.js
  • wp-includes/js/wp-custom-header.js
  • wp-includes/js/wp-embed-template.js
  • wp-includes/js/wp-embed.js
  • wp-includes/js/wp-emoji-loader.js
  • wp-includes/js/wp-emoji.js
  • wp-includes/js/wp-list-revisions.js
  • wp-includes/js/wp-lists.js
  • wp-includes/js/wp-pointer.js
  • wp-includes/js/wp-util.js
  • wp-includes/js/wpdialog.js
  • wp-includes/js/wplink.js
  • wp-includes/js/zxcvbn-async.js

Current status:

Happy documenting!



Dev Chat Agenda: January 31st (4.9.3 week 3)

This is the agenda for the weekly dev meeting on January 31, 2018 at 21:00 UTC / January 31, 2018 at 21:00 UTC:

  • 4.9.3 update
  • Updates from focus leads and component maintainers
  • Servehappy
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-3, #agenda, #core, #dev-chat

WordPress 4.9.3 release pushed to February 5th

The 4.9.3 release was due out today (January 30th) however a delayed RC with a short testing window has meant it is better to move RC to after dev chat tomorrow on the 31st and reschedule the 4.9.3 release to Monday, February 5th so that a release is not pushed immediately before the weekend.

In the meantime please continue to test the beta release: 4.9.3-beta1 (ZIP). For more information on testing see Beta Testing. The current 4.9.3-beta1 contains several enhancements and fixes but importantly note the removal of JSHint from core and see ticket #42850 for more details. For a full list of changes see the beta1 release post, tickets closed and the changesets committed.


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 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

  • 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 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 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: