Dev Chat Summary: November 1st (4.9 week 14)

This post summarizes the dev chat meeting from November 1st (Slack archive).

4.8.3 Release

  • We've seen a few reports, one issue with meta queries in WP_Query
  • No reports of linebreaks being removed after updating to 4.8.3
  • No issues reported through plugins (just some ACF/query oddities)

4.9 schedule

  • 4.9 RC1 went out on Monday
  • No feedback on RC1 testing or other issues to discuss, but please keep testing!
  • There are three tickets remaining with needs-dev-note, all relate to work I believe @westonruter is working through
  • @jbpaul17: working to pull together the Field Guide but could use some help writing summaries for the dev notes and collecting details for the New Action Hooks, New Filter Hooks, Modified Filter Hooks, and External Library Updates sections.
  • @jbpau17: Any component maintainers that want to highlight other tickets that weren’t significant enough to warrant dev notes, please send those Trac numbers to me ASAP
  • Aiming to publish the Field Guide by the end of the week, so any help before then would be wonderfully appreciated. Please reach out to @jbpaul17 (@jeffpaul on Slack) if you have availability… thanks!

General announcements

  • @davidakennedy: I should have #42090 committed today. Working on figuring out the updated POT files now. Will ping another committer to review before commit.

#4-8-3, #4-9, #core, #dev-chat, #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

Improvements to the Customize JS API in 4.9

There are many user-facing Customizer improvements in 4.9, including: drafting/scheduling of changesets, autosave revisions, changeset post locking, frontend public previews, a new experience for browsing and installing themes, updated nav menu creation UX, and the code editing improvements for the Custom HTML widget and Additional CSS. But in addition to all of these, there are also many improvements for developers which will make extending the Customizer much more pleasant.

Something important to remember about the Customizer is that it is a single page application that is powered by JavaScript. Many developers may only interact with the PHP API for registering controls, settings, sections, panels, and partials. But controls, sections, and panels do not need to be registered in PHP at all. The PHP API for registration is essentially a wrapper for the underlying JS API. When you load the Customizer all of the params for the PHP-registered constructs are exported to the client for the JavaScript API to instantiate and initially add to the UI, but this JS API can dynamically instantiate additional constructs at any time thereafter in a Customizer session. This is how new widgets, nav menus, and nav menu items are added without requiring the entire Customizer to reload. You can also avoid statically registering settings and partials in PHP by instead adding filters to dynamically recognize settings and partials, allowing them to be registered on demand. All of this allows the Customizer application to scale out to be able to customize and preview an unlimited number of things on a site (e.g. any post or page with their postmeta in the Customize Posts feature plugin). The point here is that in order for the Customizer to scale, the JavaScript API must be used directly. So this is why the Customizer JS API improvements in 4.9 are important as they fix many longstanding annoyances and shortcomings with the JS API.

This dev note contains the following sections:

Continue reading

#4-9, #customize, #dev-notes

What’s new in Gutenberg? (31st October)

This week's release has a focus on the writing experience: reducing the visual weight of blocks, improving the behaviour of keyboard interactions, moving the block toolbar to a docked position at the top of the interface, and several little tweaks to the design that cumulatively should have a significant effect on the editor feeling. It also includes the ability to convert a classic block (post) into several gutenblocks at will. This is a very big release so, please, help us test it!

1.6 🎃

Other Changes

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

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

Dev Chat Summary: October 25th (4.9 week 13)

This post summarizes the dev chat meeting from October 25th (agendaSlack archive).

4.9 schedule

  • Beta 4 dropped late last night / early this morning, please do help test. RC is scheduled to go out on Monday, October 30th and that entails soft string freeze.
  • For all @committers, please let @melchoyce @westonruter know if you are able to help with commits during RC as we’ll need two committers to approve a patch before merging.
  • Bug Scrubs are scheduled on Monday’s and Thursday’s. If you have availability to help run a scrub, please let @jbpau17 know. Any help would be greatly appreciated, thanks!
  • Currently nine tickets that show as needs-dev-note
  • Three Dev Notes coming from @westonruter and one from @rafa8626 (#39686); all could use proofreading
  • If anyone can help draft the Field Guide, please let @jbpaul17 know especially for things around New Action Hooks, New Filter Hooks, Modified Filter Hooks, and External Library Updates.
  • If anyone can help populating the “Developer Happiness” section of the About page, please let @melchoyce know or add notes to #42087

Editor / Gutenberg update

  • Gutenberg v1.5 includes metabox support and likely has advanced cases where the plugin will benefit from feedback and iteration.
  • You can report via GitHub, the feedback form within the Gutenberg plugin, or in #core-editor.

General announcements

  • @johnbillion: The last PHP 7.2 issue, #41526, needs some eyes and can still make it into 4.9 if another patch comes along. The original patch causes some warnings.
  • @paaljoachim: looking for comments on #42324

#4-9, #core, #dev-chat, #gutenberg, #summary

Improvements in REST API request parameter regular expressions

With WordPress 4.9, a bug has been fixed which would cause unexpected numeric results to be included in the parsed URL parameters for a REST API request. Prior to this change, calling WP_REST_Request::get_params() for a request like /wp/v2/users/(?P<id>[\d]+) with an ID of 10 would return array( 'id' => 10, 1 => '10' ), where the latter numeric key is unnecessary and a result of PCRE matching against a named subpattern (see preg_match() documentation). The fix ensures that the above request now only returns array( 'id' => 10 ) instead. This helps for example to verify that a request does not include more than a few specific parameters.

The WP REST API docs have always been using named URL parameters, using regular (numeric) matches was never recommended. With this bug fix in place, using named parameters is now effectively required, for example /my-namespace/my-endpoint/(?P<numeric_param>[\d]+) must be used instead of /my-namespace/my-endpoint/(\d+). For background discussion on these changes, see #40704.

#4-9, #dev-notes, #rest-api

Dev Chat Agenda for October 25th (4.9 week 13)

This is the agenda for the weekly dev meeting on October 25, 2017 at 20:00 UTC / October 25, 2017 at 20:00 UTC:

  • 4.9 schedule
  • Editor / Gutenberg update
  • 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, #agenda, #dev-chat