Dev Chat Agenda: January 17th (4.9.2 week 7)

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

  • 4.9.2 planning
  • 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-2, #agenda, #core, #dev-chat

What’s new in Gutenberg? (12th January)

Hope everyone has had some good time! We are resuming the releases of Gutenberg for this new year. The first one — 2.0 — is rather big, with updates across the board. The highlights cover several pasting improvements, a more polished publish flow, block API tweaks and extensibility additions, various accessibility improvements, block library updates (like new querying by category in latest posts), etc.

2.0 🦕

Design and editing experience




  • Render toolbar always by the block on mobile.
  • Improve performance of responsive calculations using matchMedia.
  • Avoid shifts around toolbar and scrolling issues on mobile.
  • Improve how the fixed-to-block toolbar looks on mobile. Change how the fixed position toolbars behave, making them sticky.
  • Prevent Mobile Safari from zooming the entire page when you open the inserter.

Block API and Misc.

Bug Fixes

#core-editor, #editor, #gutenberg

Servehappy Roadmap

The group of people in the #core-php channel has been discussing and planning a project codenamed “servehappy” for some time now. We are at the point where we think that our plan has matured enough to present it to a bigger WordPress audience, in the hopes that we can get buy-in from more people to support or join our cause.


Primary Goal (long-term, indirect):

  • Reduce the number of WordPress installations running on an unsupported PHP version

Secondary Goals (short-term, direct):

  • Make WordPress site owners aware that they are running an unsupported version of PHP
  • Educate WordPress site owners about PHP and its versions
  • Provide WordPress site owners with tools and resources that enable them to update their site’s PHP version

The primary goal is what we’re aiming at. However, this is not something we can directly act upon. The secondary goals are the actionable elements that are in line with the primary goal.

We are confident that we can produce a definite positive impact on the primary goal through a concerted effort on these secondary goals.

Current State

A good overview of the current state can be found in the project repository’s file.


Mockup of the ServeHappy page, showing collapsible sections of content.

ServeHappy page mockup
Click to enlarge


Through our regular weekly meetings we’ve made good progress on putting together the content for an informational page called “servehappy (in reference to the “browsehappy” page that helped get rid of legacy web browsers). The page should ideally be hosted on the infrastructure, similar to how the browsehappy page is stored.


Mockup of the WordPress admin dashboard, showing an admin notice warning about the PHP version.

Admin notice mockup
Click to enlarge


This page is meant to be linked to by admin notice(s) in the WordPress admin dashboard that will appear for people with unsupported PHP versions. Work on implementing these can start as soon as we have confirmation that the servehappy project should be further pursued.


Mockup of a plugin detail screen in the admin dashboard, showing a red "Cannot install" button and a link to the ServeHappy page.

Plugin requirements mockup
Click to enlarge


Finally, we want to work on enforcing plugin/theme PHP requirements as they can already be stated in the plugin/theme meta information. With time, this will provide developers with better control over their code base and incentivize site owners to keep up with the WordPress ecosystem’s evolution.

We’ve prepared a short overview document that details the core integrations and how they tie into the servehappy page.

As a side note, while working on the servehappy page content, we started collecting links to various resources that can be of use to people wanting to update their PHP version. These can be found in a separate servehappy-resources repository.

Project Progression

We intend to target only PHP 5.2.x initially, to not put too much pressure on the support channels of hosting providers. When a reasonable amount of time has passed and most of the initial updating effort has been completed, we can consider moving the needle up to PHP 5.3.x.

Provided that we have a clear roadmap, transparent communication and the patience to let site owners and hosters handle the updates in manageable intervals, this provides us with a tool to slowly catch up to PHP releases and reduce the currently growing gap between WordPress requirements and PHP versions.


Here’s our current preliminary timeline:

Information Page on – Current Draft
– Trac ticket
1st Quarter 2018
Admin Notice in Dashboard – Trac ticket 2nd Quarter 2018
Minimum PHP Requirements Trac ticket 3rd Quarter 2018

Of course, these are only guesstimates. The actual development work involved makes this timeline easily possible, but what is time-consuming (and hard to predict) is the amount of discussions that are needed to find a concensus on all critical decisions.

Our Request

Before we invest more time into this project, we want to get a basic decision (in principle) about whether we should pursue or not.

  1. Is the servehappy project worthwhile and do we have a general buy-in from Core leadership?
  2. Can we make the servehappy project an official feature project?
  3. Information Page – Can this page be hosted on the infrastructure?
  4. Information Page – Who is responsible for the final editorial check?

To this end, we had the servehappy project added to the agenda of the upcoming devchat meeting on 10th Jan, 2018. This post was prepared to allow attendees of this meeting to get a quick overview of the project in preparation for the meeting.

#php, #roadmap, #servehappy

Changed behaviour of esc_sql() in WordPress 4.8.3

As part of the WordPress 4.8.3 release, there is a change in `esc_sql()` behaviour that may affect plugin developers who expect `esc_sql()` to return a string that’s usable outside of the context of building a query to send to WPDB.

While we strongly recommend you do not use `esc_sql()` for other purposes, we understand that it can be tricky to rewrite old code rapidly. To return to the old behaviour, you can use the `$wpdb->remove_placeholder_escape()` method, like so:

echo esc_sql( "100%" );
// "100{9fa52f39262a451892931117b9ab11b5a06d3a15faee833cc75edb18b4411d11}"

echo $wpdb->remove_placeholder_escape( esc_sql( "100%" ) );
// "100%"

#4-8, #4-8-3, #dev-notes, #wpdb

No Dev Chat This Week (4.9.2 week 4)

A reminder that there will be no devchat this week as we are on hiatus over the holidays.


The next devchat will be on January 10, 2018 at 21:00 UTC / January 10, 2018 at 21:00 UTC.

#4-9-2, #core, #dev-chat

What’s new in Gutenberg? (11th December)

Gutenberg is back to a regular schedule after a great WCUS in Nashville which included many conversations and exchanges of ideas. If you missed it, checkout Matt’s State of the Word presentation for an overview of how the year has gone and what lies ahead for Gutenberg. (It also includes a demo of the plugin in action.) It was great to have new people helping at contributor day and submitting pull requests. Thanks!

This release introduces global reusable blocks as the main highlight, but there are also improvements to templates (ability to lock them down), versioning block attributes so markup can be migrated, and many extensibility additions as well as bug fixes.

1.9 🐆

  • Introducing reusable global blocks. (Stored in a wp_blocks post type.)
  • Add ability to lock down the editor when using templates so edits can happen but blocks can't be removed, moved, nor added.
  • Handle and upgrade deprecated blocks. This allows to migrate attributes without invalidating blocks and an important part of the block API.
  • Drag and drop upload support to gallery block.
  • Extensibility:
    • Expose packages/hooks public API under wp.hooks.
    • Introduces withFilters higher-order component to make component filtering easier.
    • Introduces getWrapperDisplayName helper function to make debugging React tree easier.
    • Introduces compose function to unify composing higher-order components.
    • Exposes hook for Block component.

Other changes

From 1.8.1

  • Add ability to switch published post back to draft.
  • Fix issue when changing column count in "text columns" block.
  • Prioritize common items in the autocomplete inserter.
  • Avoid changing publish/update button label when saving draft.
  • Add bottom padding to the editor container to improve experience of writing long posts.
  • Adjust the Classic block toolbar so it doesn't jump.
  • Colorize the little arrow on the left of the admin menu to white to match body content.
  • Update autocomplete suggestions colors to have a sufficient color contrast ratio.
  • Abort focus update when editor is not yet initialized.

#core-editor, #editor, #gutenberg

PHP Meeting Recap – December 18th

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

  • After asking for feedback last week, we got told that our weekly recaps are valuable to some readers, so we keep writing them. We removed the attendees’ list because it takes a substantial amount of time to complete, with little added value.
  • Due to the upcoming holidays, we are skipping the meetings for December 25nd and January 1st. Next meeting will be held on January 8th.
  • Regarding plugin testing, we reasserted that we’ll still recommend PHP Compatibility Checker for now, even though Tide (Team Home | GitHub) is on the horizon. As long as Tide is not open source and hasn’t been properly integrated into the WordPress ecosystem, it just isn’t a valid option.
  • As we’ve finished the content for the page, we are now discussing the overall strategy of moving forward with the project:
    • produce preliminary deliverables (site mockup, admin dialog mockup)
    • create/update (Meta) Trac ticket(s) to make sure we have a clear set of goals, a proper roadmap and a timeline
    • raise awareness through dev-chat meetings and news portals to get feedback and buy-in
  • Ask a precise question to get a precise answer: “Is that something worth pursuing within scope?”
  • We plan to discuss the project in dev-chat on January 10th. By then, we expect to have the deliverables ready.
  • Two tickets that currently track the progress: Trac 41191 (admin notice) and Meta Trac 2996 (external servehappy page).

Next week’s meeting

  • Next meeting will take place on Monday, January 8th, 2018 at 16:00 UTC in #core-php (Note: We are skipping two meetings because of Christmas and New Year’s Day).
  • Agenda: Discuss latest progress and our approach for the dev-chat meeting on January 10th.
  • 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.

#core-php, #php, #servehappy, #summary

WordPress 4.9.1 scheduled for November 29th

WordPress 4.9 has been downloaded over 6 million times since its release two weeks ago.

A small number of bugs have been identified which are impactful enough that the core team has decided to release 4.9.1 with fixes for those issues. The release is scheduled for tomorrow, November 29th, 20:00 UTC. A beta release will be packaged later today and made available for testing.

The issues that have been fixed are:

  • #42573: File caching affecting users’ ability to use the plugin and theme file editors.
  • #42574: MediaElement upgrade causing JS errors when certain languages are in use.
  • #42579: Incorrect logic in extract_from_markers().
  • #42454: Unable to translate Codex URL in theme editor.
  • #42609: Theme editor cannot edit files when running on a Windows server.
  • #42628: flatten_dirlist() doesn’t play nice with folders with numeric names.
  • #42634: DB_HOST socket paths with colons not parsed correctly.
  • #42641: On multisite upgrade the wp_blog_versions table doesn’t get updated
  • #42673: Themes page throws console error when there is only one installed theme.

In addition, one fix for a bug introduced in WordPress 4.7 will be included in 4.9.1:

  • #42242: lang attribute in the admin area doesn’t reflect a user’s language setting.

Stay tuned for the announcement of a beta package.


MediaElement upgrades in WordPress 4.9

MediaElement has been upgraded to 4.2.6 (see #39686), which includes many bug fixes as well as:

  • Removal of all dependencies to jQuery in code to make it more portable
  • Updated UI, using flexbox
  • Improved accessibility for player controls
  • Dropped support for older browsers (supports IE11+, Chrome, FF, Safari, Android 4+ and iOS 8+), keep in mind that ME.js applies to the front end and not just WP Admin
  • Upgraded YouTube and Vimeo renderers to use new APIs (for Vimeo, it uses now, since Froogaloop is deprecated)
  • Added support for iOS 10 and Mac OS on websites using HTTPS

With this upgrade, a couple of things must be considered:

  1. In order to create themes compatible with it, it is required to add the classPrefix: mejs- in the player configuration, since latest version of MEJS switched to BEM naming convention, so make sure it is set correctly.
  2. player.options.mode has been removed completely.
  3. Although jQuery was removed from the core package, a MediaElement migration file has been included to provide full backward compatibility between themes and development of new features.

A full list of changes in MediaElement.js is available in the project’s GitHub repository.

Props to @rafa8626 for helping write this Dev Note.

#4-9, #dev-notes, #mediaelement

PHP Meeting Recap – December 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: @afercia @clorith @drewapicture @drivingralle @flixos90 @jdgrimes @joostdevalk @jorbin @ottok @overclokk @paulstonier @pross @ptasker @spacedmonkey @vizkr

Chat Summary

The main agenda for this week was to review the copy the marketing team has been working on in regards to the “Before Upgrading PHP” document.

Here is the discussion summary:

  • As WordPress recommends a specific PHP version on the requirements page, it was decided that that same version should be used on the Servehappy page (currently 7.2). Vague version terminology like “PHP 7+” or similar should be replaced accordingly.
  • A few minor changes to the copy were suggested and added to the Google document as a comment.
  • The part about the backup not including the PHP version might need to be clarified, but on the other hand it might unnecessarily scare away site owners from proceeding. This is something that still needs to be figured out.
  • On a side note, the PHP Compatibility Checker plugin should make it easier to run the check after the installation. Currently there’s simply a submenu item added in the admin, but no link or anything to it, so the user has to search for it which is bad UX.
  • There was a discussion regarding the proposal in #42858, to bump the minimum version requirement in PHP 5.0 and make 4.9 some kind of LTS version. The gist of the discussion was that this would be a problematic move as it would leave deliberately leave users behind which is against WordPress’ principles. An eventual version bump should be announced well in advance, and there should be enough time to educate site owners on the topic and prepare them for the upgrade instead of forcing them to either upgrade immediately or be left behind. The Servehappy page should be a major contributor to that education, but before it is in place, no measures in regards to a minimum version bump should be taken. Once it is live, #40934 and #41191 will be the two main tickets that need to be worked on for core so that site owners can actually be made aware of the problem.

The rest of the meeting focused on a few organizational items:

  • Writing the weekly recap posts is an extra maintenance burden that may possibly not be worth the effort. A regular update would still be valuable though, so a good alternative would be to write a monthly update post or just an update post when something major was decided. If you have been reading these weekly recaps and find them particularly useful, please leave a comment on this post, otherwise the team will move over to writing decision-dependent update posts.
  • Once Servehappy is set in stone, one of the next major goals of the initiative will be to discuss and come up with more patterns and standards in core, in order to at least in the future prevent rather random decisions by individual developers, causing an inconsistent codebase. As of now however, Servehappy is the sole priority.

Next week’s meeting

The next meeting will take place on December 18th, 2017, 16:00 UTC as always in #core-php. The agenda will be to plan spreading the word more, particularly by asking for more feedback in the weekly development chat. 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