Improvements in Media component accessibility in WordPress 5.3

Form controls are still unlabelled in WordPress media views. Some don’t have associated <label> element, <aria-label>attribute or some have an empty label.

Properly labeling form controls is essential for a basic level of accessibility, as labels give form controls their accessible name. The name is then used by assistive technologies to inform users what the form control is about. Not to mention visible <label> elements are clickable and help users with motor impairments to set focus on the associated form control.

Also, the WordPress accessibility coding standards recommend explicitly associated labels (with for/id) attributes instead of implicitly (wrapping) labels.

WordPress 5.3 will now include some accessibility improvements of all the media views from controls:

  • Changes the media views form controls to have explicitly associated labels with for/id attributes
  • Adds a few missing labels / aria-labels
  • Improves a few existing labels / aria-labels
  • Improves semantics in a few places, by adding visually hidden headings, fieldset + legend elements, aria-describedby attributes
  • Improves the image custom size input fields and their labeling
  • Adds role=”status” to the “saved” indicator so that status messages are announced to assistive technologies
  • Swaps the columns source order in the image details template, to make visual and DOM order match
  • Swaps the “Replace” and “Back” buttons source order in the Replace Image view, to make visual and DOM order match
  • Gallery settings: move checkbox label to the right: checkboxes are supposed to have labels on the right
  • Merge similar strings, unified to “Drop files to upload” (removed “Drop files here”, and “Drop files anywhere to upload”)
  • Makes the “upload-ui” consistent across the media views
  • Hides the IE 11 “X” ::-ms-clear button in the Insert from URL field, as it conflicts with the uploading spinner
  • Adds comments to all the media templates to clarify their usage
  • Slightly increases the vertical spacing between form fields in the media sidebar
  • Removes some CSS selectors introduced as backwards compatibility for WordPress pre-4.4
  • Removes some CSS still targeting Internet Explorer 7 and 8
  • Fixes buttons group layout for Internet Explorer 11

The most important change to clarify is that the labeling changed from this (implicit labeling):

<label>
    My input
    <input type="text" />
</label>

to this (explicit labeling):

<label for="my-input">My input</label>
<input type="text" id="my-input" />

Simplified code sample


More details on these improvements can be found in Trac ticket #47122.

This note was drafted by @justinahinon and proofread by @afercia.

#5-3, #accessibility, #dev-notes, #media

Updates to Image Processing in WordPress 5.3

WordPress 5.3 includes several enhancements to how images are used and post-processed after upload.

When an image is uploaded to WordPress, alternate smaller sizes are automatically created. Some of these “intermediate” sizes are defined by core, and others by themes or plugins. These are used both for art direction uses, like alternate crops, and automatically by core for responsive images if they are the same aspect ratio.

Resizing images is very resource intensive. As average image sizes have increased over time, this has only increased the chances that requests may time out or run out of memory. WordPress 5.3 includes several enhancements to help more uploads succeed, and to aid users in recovery when they do not. These changes also enable WordPress to generate two new, higher resolution default sizes, to help user images look their best.

Saving of image metadata while creating intermediate sizes

Before 5.3, WordPress would first generate all intermediate sizes before saving proof of their existence in the database in meta.

This meant that if an upload failed in the middle, there could be many sizes that had completed successfully stored, but this wouldn’t be reflected in the database. A user’s only recourse was to re-upload over and over again in the hope that their server was less busy and all of the sizes would be generated.

In 5.3, this problem is fixed through saving metadata for each size as it is created in the database. This means more database writes, but allows WordPress to use the sizes generated earlier, and to resume failed uploads.

To make this possible, a new method make_subsize() was introduced in the WP_Image_Editor_GD and WP_Image_Editor_Imagick classes. It returns the new sub-size image path and dimensions ready to be added to the image meta’s sizes array. See #40439.

Additional changes:

  • Introduces wp_get_missing_image_subsizes() and wp_update_image_subsizes() to generate image sub-sizes that are missing or were not created after the upload.
  • Adds a way to display errors that happened while creating sub-sizes.
  • Introduces wp_create_image_subsizes() intended for use after an image was uploaded. It saves/updates the image metadata immediately after each sub-size is created.

With that in place it became possible to attempt to finish post-processing of images after upload if the server runs out of resources while creating intermediate image sizes (the dreaded “HTTP Error” message). See #47872.

“BIG image” enhancements

Until now it was possible to use the originally uploaded images on the front-end even when they are were not “web ready”. In WordPress 5.3 when a large image is uploaded it is stored in the uploads directory but is not used on the web site. A new scaled down image is created and used as the largest available size. This scaled down image is usually much more suitable for web use, the file size is up to ten times smaller than the original. See #47873.

Additional changes:

  • Introduces wp_get_original_image_path() that retrieves the path to the originally uploaded image in all cases.
  • Introduces big_image_size_threshold filter to set the pixel value above which images will be scaled. The same value is used as max-width and max-height when scaling the original.

These enhancements also made it possible to automatically rotate uploaded photos according to the EXIF data, and to add two additional default image sizes to better support high-density displays. See #14459 and #43524.

Thanks @mikeschroder for helping to write this post.

#5-3, #dev-notes, #media, #upload

WordPress and PHP 7.4

PHP 7.4 is in the final stages of its release cycle. As of the publish date of this post, version 7.4 RC3 has been released, and the final release of PHP 7.4.0 is scheduled for November 28, 2019.

As the expected changes in PHP 7.4 were made public earlier this year, contributors to WordPress Core worked to identify compatibility issues within the code base. Overall, the changes needed to declare full PHP 7.4 support were minor, and have all been made.

WordPress aims to fully support PHP 7.4 in the 5.3 release (currently scheduled for November 12, 2019).

Here is a breakdown of the changes in PHP 7.4 that plugin and theme developers need to be aware of and should accommodate in their code.

Changes to Curly Brace Syntax

In the past, PHP has allowed the use of curly braces ({}) to access array elements and string offsets.

<?php
$array = [1, 2];
echo $array[1]; // prints 2
echo $array{1}; // also prints 2
 
$string = "foo";
echo $string[0]; // prints "f"
echo $string{0}; // also prints "f"

Using the curly brace syntax will now trigger a deprecated notice in PHP 7.4 with the plan to remove the feature entirely in PHP 8.0 (or another future release).

For more information about this change, see the accepted proposal on the official PHP RFC Wiki, or check out what changed in WordPress Core to fix these issues in #47751.

Specific Parameter Order Requirements For implode()

The implode() function accepts two parameters, $glue and $pieces. For historical reasons, implode() has accepted these parameters in any order, though it has been a recommendation that the documented order of implode( $glue, $pieces ) be used.

Starting in PHP 7.4, tolerance for passing the parameters in reverse order is deprecated and will be completely removed in PHP 8.0. Calling implode( $pieces, $glue ) in PHP 7.4 will trigger a deprecated notice.

Note: This also affects the join() function, which is an alias of implode() and accepts the same two parameters.

For more information about this change, see the accepted proposal on the official PHP RFC Wiki, or check out what changed in WordPress Core to fix these issues in #47746.

Accessing Array Offset on Non-Arrays/Objects

PHP has previously thrown a warning only when attempting to use an offset that is of an invalid type. However, starting with PHP 7.4, a warning will also be thrown when a container is of an invalid type.

While code which relies on the undocumented behavior of PHP returning null when attempting to array access a null/bool/int/float/resource will continue to work as expected, each and every instance of this will now throw a PHP E_WARNING.

This issue is most common when using array access on the outcome of functions with mixed return values, i.e. array|false. When the return values of these function are used, more type checking needs to be done before attempting to access the return value as if it were an array to prevent this warning.

For more information about this change, see the accepted proposal on the official PHP RFC Wiki, or check out what changed in WordPress Core to fix these issues in #47704.

Note: because this issue cannot be easily/reliably detected using static analysis tools, it is possible that there are more occurrences of this issue in Core. Please open a new ticket on Trac and tag it with the php74 keyword if additional issues of this type are discovered.

Concatenation & Plus/Minus Operator Precedence

In past versions of PHP, the operator precedence of the ., +, and - operators has been exactly the same. Because of this, operations are evaluated from left to right. However, because concatenated strings generally are not numbers, this often produces undesired behavior. It’s rare that the intended behavior is to add or subtract concatenated strings.

// Example:
echo "sum: " . $a + $b;
 
// Current behavior: evaluated left-to-right
echo ("sum: " . $a) + $b;
 
// Desired behavior: addition and subtraction have a higher precedence
echo "sum :" . ($a + $b);

In PHP 8.0, the . operator will have a lower precedence than + and -. This will ensure that additions and subtractions are always performed before concatenation occurs.

As an example, the expression '3' . '5' + 7 will now be equal to “312” instead of previously “42”.

Starting in PHP 7.4, a deprecation notice will be triggered for any unparenthesized expressions containing a . before a + or -. While this is a subtle change, every occurrence of this pattern will result in a change of behavior in PHP 8.

For more information about this change, see the accepted proposal on the official PHP RFC Wiki, or check out what changed in WordPress Core to fix this issue in #47441.

Deprecated: Magic Quotes Related Functions

The magic_quotes configuration was removed from PHP in version 5.4. The function implementations that check whether or not these settings have been enabled have returned false since then. Later, PHP 7.0 removed magic_quotes entirely.

As of PHP 7.4, get_magic_quotes_gpc() and get_magic_quotes_runtime() are now marked as deprecated and they are slated for removal in PHP 8.

For more information about this change, see the accepted proposal on the official PHP RFC Wiki, or check out what changed in WordPress Core to fix this issue in #47783.

Left-Associative Ternary Operators

In most other languages, the ternary operator is right-associative. However, in PHP, it is left-associative. This behavior is generally not useful and can be confusing for programmers who switch between different languages.

In PHP 7.4, nested ternaries without explicit parentheses will throw a deprecation warning In PHP 8.0, it will become a compile-time error instead.

<?php
1 ? 2 : 3 ? 4 : 5;   // deprecated
(1 ? 2 : 3) ? 4 : 5; // ok
1 ? 2 : (3 ? 4 : 5); // ok

There were no occurrences of this pattern in WordPress Core, but it’s important to check your plugins, themes, and custom code to ensure PHP 7.4 compatibility. For more information about this change, see the accepted proposal on the official PHP RFC Wiki.

Compatibility Tooling

To help detect potential compatibility issues with supported versions of PHP, the PHPCompatibility checker has been added to WordPress Core with a custom tailored ruleset that extends the PHPCompatibilityWP ruleset.

If you build or maintain plugins or themes, it is highly recommended that you add the PHPCompatibility checker to your toolkit to make detecting PHP version compatibility issues easier and consistent. Aside from the array offset issue, all other issues mentioned in this article can be automatically detected through the use of PHPCompatibility.

When working on WordPress Core, composer compat can be run to scan the Core code base for potential compatibility issues. Furthermore, every TravisCI build will now contain a “PHP Compatibility Check” job that will scan for potential compatibility issues. This job is currently allowed to fail while the results are analyzed and the ruleset is refined to eliminate false positives.

For more information, see #46152 on Trac.

External Libraries & Dependencies

WordPress Core contributors have collaborated with the maintainers of several external libraries and dependencies to ensure compatibility with PHP 7.4.

getID3

The getID3 library was updated from v1.9.14 to v1.9.18. This update removes some occurrences of the now deprecated curly brace syntax and some code related to magic quotes. For more details, check out these pull requests, #47783, or [46112].

PHPMailer

The PHPMailer library was updated from v5.2.22 to v5.2.27 in Core and patched to prevent deprecated notices related to magic quotes from being triggered. Magic quotes has been completely removed from PHPMailer 6.0 and higher. #41750 exists to upgrade PHPMailer to the latest and greatest early in the 5.4 release cycle. For more details, check out #40472 and #47783, or the relevant changesets ([46097] and [46378]).

Requests

The Requests library was updated to address occurrences of the now deprecated curly brace syntax and accessing array offsets on non-arrays. For more details on these updates, see PR-346 and PR-370 in the Requests repository, #47746, or the related changesets ([46258] and [46416]).

SimplePie

The SimplePie library was patched in Core to prevent deprecated notices related to passing parameters to implode() in the incorrect order from being triggered. This issue is fixed in the most recent release of version 1.5.3. Upgrading the entire library to the latest and greatest with increased test coverage is being explored and is expected early in the 5.4 release cycle (see #36669). For more details, check out #47746 or [46260].

Other Updates

A few other libraries that no longer have an externally maintained canonical source have also been updated.

Summary

As always, reading through the complete upgrade document is highly recommended.

Even as WordPress Core continues to expand its support for new versions of PHP, the current support for old versions will remain as is at PHP 5.6.20 and higher until usage numbers show that the impact on users will be minimal.

There is a separate initiative to decrease the usage numbers for older versions of PHP being guided by the Core PHP team through the servehappy initiative. If you wish to help with this effort, please join the #core-php room in the Making WordPress Core Slack instance.

WordPress continues to encourage all users to run the latest and greatest versions of PHP. This includes PHP 7.4 upon its official release.

A full list of tickets related to PHP 7.4 support can be found on Trac.

Props @jrf and @jorbin for peer reviewing.

#5-3, #dev-notes, #php-7-4

Filtering nested REST response _fields in WP 5.3

WordPress 4.9.8 introduced the ability to limit the fields included in the JSON objects returned from the REST API, for example specifying

/wp/v2/posts?_fields=id,title,author

to return a list of posts with only id, title & author fields in situations where we don’t need all of the data contained in other fields like content or media (see #38131). Since 4.9.8 we’ve made further improvements to skip computing fields we did not explicitly request when _fields is present, saving time on the server in addition to slimming down the JSON response object.

In WordPress 5.3 we are adding the ability to filter by nested fields. Previously we could only request top-level properties like content or meta, which would return the full content object (with raw and rendered properties when using an edit context) or the object containing all meta values. We can now specify a nested path such as content.raw and the REST API will skip computing the rendered content, a useful performance boost for applications like Gutenberg which only require that underlying raw post content.

Now that we can register complex array or object meta, we may similarly ask for only a few of many registered meta fields, or certain properties within a complex object, using a query such as this:

?_fields=meta.meta-key-1,meta.meta-key-2,meta.meta-key-3.nested-prop

(Note that this specific meta example depends on bugfix #48266, which will ship as part of RC1.)

Thank you @timothyblynjacobs, @dlh, @danielbachhuber, and @rmccue for assisting with the development of this useful feature!

#5-3, #dev-notes, #rest-api

WordPress 5.3 adds a “Show” button next to the password field on the login screen

Many web services today display a Show button next to the password fields. The purpose being to help the user ensure that the password entered is correct.

Note that a button already exists to show/hide the password in the New User, Edit User and Reset Password pages. This functionality is now available with WordPress 5.3 on the login screen.

Here’s a quick view of the behavior of the button.


For more information on this feature, check ticket #42888 on Trac and changesets [46256] and [46372].

#5-3, #dev-notes

WordPress 5.3: Backbone Upgrade Guide

In WordPress 5.3, the version of Backbone bundled with WordPress will be updated from v1.3.3 to v1.4.0. Developers who override on and off events on their models may run into a few issues if they have listenTo events being applied to them.

Consider the example below:

// Model
class Model extends Backbone.Model {
    initialize() {
        this.collection = new Backbone.Collection()
    }

    on() {
        this.collection.on.apply( this.collection, arguments )
    }

    off() {
        this.collection.off.apply( this.collection, arguments )
    }
}

// View
class View extends Backbone.View {
    initialize() {
        this.listenTo( this.model, 'event-name', null )
    }
}

// Create an instance of Model and View
const model = new Model()
new View( { model } )

// Remove callbacks from model
model.off();

A TypeError will now be thrown at model.off, as when the model’s callbacks are removed, Backbone attempts to remove the set of listeners applied to the model as well. These sets of listeners are no longer on the model, but instead are on the model’s collection.

The reason for this is because Backbone now uses the listened object’s public on method when applying the listenedTo event, and in the example above, the on event will be applied to model.collection. A simple fix to this error is to instead pass model.collection as the object to be listened to.

For a full list of changes in this release, see the Backbone Changelog. For reference on this update, see the Trac ticket #47478.

Props @adamsilverstein and @desrosj for peer review.

#5-3, #dev-notes, #external-libraries

Dev Chat: 10/9/2019

@davidbaumwald served as facilitator and note taker for this week’s chat held in the #core Slack channel. To view the chat from the beginning, click on this Slack Archive.

Announcements

WordPress version 5.3 Beta 3 was released on Tuesday. Congratulations to everyone involved in inching 5.3 closer to the finish line.

5.3 Updates

With 5.3 Beta 3 now release, focus turns to Release Candidate 1(RC1) is next on the schedule just a few days from now. A “soft string freeze” is now in effect.

@francina called for volunteers for next week’s RC1 release session. Both Mission Control(MC) and a Core Committer will be required. @azaozz and @sergeybiryukov raised their hands.

@karmatosed provided a quick update on 5.3’s About page, saying that everything is on track and copy is being finalized.

@jeffpaul inquired about the progress on compilation of Dev Notes for 5.3. @justinahinon pointed to a Google Sheet that he’s using to organize them and coordinate volunteer authors.

This discussion led to a call for more volunteers and ticket owners to draft Dev Notes. @desrosj mentioned that he’s “… started a page for the handbook collecting the learnings from the last three releases for this.”

@ianbelanger brought a Twenty Twenty update to the group. A PR has been opened to address WPCS violations in the Beta Twenty Twenty patch, and a call for testing was announced. @karmatosed added that testing on mobile is a great help to the team.

Open Floor

@azaozz mentioned that there are, as of writing, only 37 open tickets in the 5.3 milestone, and everything should be closed out as RC1 is released. This was a great reminder of the tremendous work done by Core Contributors during the course of the 5.3 cycle, as over 350 tickets were initially open when the cycle was kicked off!

These notes were drafted by @davidbaumwald and proofread by @justinahinon.

#5-3, #dev-chat, #summary

Introducing handling of big images in WordPress 5.3

The way WordPress handles large images has always been a topic of discussion for users and developers.

There are generally two types of images that are uploaded:

  • Images that have been edited or created in an image editing application.
  • Photos that are uploaded either directly from the camera or haven’t been edited.

In the first case, the images are usually “web-ready”. They may have been scaled down to an appropriate size and optimized.

In the second case, the images are usually much bigger than needed and are not optimized for web use. A photo taken with an average modern smartphone is easily over 5MB in file size. Photos taken with a good quality camera can be much larger.

WordPress 5.3 introduces a new way to manage these images by detecting big images and generating a “web-optimized maximum size” of them.

How does it work?

When a new image is uploaded, WordPress will detect if it is a “big” image by checking if its height or its width is above a big_image threshold. The default threshold value is 2560px, filterable with the new big_image_size_threshold filter.

If an image height or width is above this threshold, it will be scaled down, with the threshold being used as max-height and max-width value. The scaled-down image will be used as the largest available size.

In this case, the original image file is stored in the uploads directory and its name is stored in another array key in the image meta array: original_image. To be able to always get the path to an originally uploaded image a new function wp_get_original_image_path() was introduced.

Disabling the scaling

The scaling is controlled by the big_image_size_threshold filter. Returning false from the filter callback will disable it.

add_filter( 'big_image_size_threshold', '__return_false' );

For reference on this change, see Trac ticket #47873 and changesets [46076] and [46353].

#5-3, #core-media, #dev-notes

Editor chat summary: Wednesday, 9 October 2019

This post summarizes the weekly editor chat meeting on Wednesday, 9 October 2019, 14:00 WEST held in Slack.

Weekly Priorities

WordPress 5.3 is planned for next week, there are still some issues we need to fix before then:

Some of the priorities are being worked, but others are not taken yet. If you think you can help with some of these tasks, please leave a comment on the issue!

It is also essential to address some browser issues, namely on IE. People with a windows dev setup could be beneficial here.

We are getting close to the WordPress 5.3 release; testing is essential, namely on the mobile phone you use, given the wide variety of devices that exist.

Task coordination

Note: If you’re reading this summary outside of the meeting, please drop a comment if you can/want to help with something!

@youknowriad

  • Working on the Media Upload errors handling.
  • Working on a fix to the navigation mode.
  • Lots of reviews and coordination.
  • Exploring some improvements to Block nesting selection with a new Block Breadcrumb.

@get_dave

  • Continues the work on DimensionControl https://github.com/WordPress/gutenberg/pull/16791, and ResponsiveBlockControls https://github.com/WordPress/gutenberg/pull/16790 PRs.
  • Started on the implementation of a potential new Link insert/edit interface as per https://github.com/WordPress/gutenberg/issues/17557

@gziolo

  • Helped @epiqueras to land the initial version of the Components Storybook.
  • Is focused on some optimizations related to eliminating dead code (mostly for experimental features) from WordPress 5.3 release.

@jorgefilipecosta

  • Worked on some changes to the custom gradient picker. Now, it is possible to move the control points using arrow keys, and the code was reorganized. It should be ready for a more in-depth review; a11y feedback would also be valuable.
  • Focused on some 5.3 must-haves.
  • Helped (reviewed tested, or suggested commits) in navigation block (related PR’s), DimensionControl, ResponsiveBlockControl, and other smaller PR’s.
  • Will continue the work on must-haves, apply a refactor that makes media&text work on IE, and fix some generic block editor issues.

@karmatosed

@brentswisher

  • Hoping to revisit displaying a notice of some kind in the inserter when there are disabled blocks (https://github.com/WordPress/gutenberg/pull/17338).
  • Help out with any 5.3 issues that he can.
  • Will try to help get through some of the new issues, label them, and get additional attention to them if he thinks they are WordPress 5.3 must-haves.

Open floor

@jeffreycarandang asked for an updated to PR https://github.com/WordPress/gutenberg/pull/17617 and to issue https://github.com/WordPress/gutenberg/issues/17809.

Regarding PR https://github.com/WordPress/gutenberg/pull/17617 @youknowriad and @jorgefilipecosta both had some comments on the problem the PR faces. The basic idea is that when a format is applied to a rich text, the focus goes back to the rich text (e.g., when we press a “bold button” it is expected I can continue typing) this behavior was always present. Some time ago, mainly because of accessibility reasons, a change was applied to popovers that automatically closes them when the focus is outside. The two previous behaviors together have some impact on formats that are applied in a popover (the popover may close in an unexpected situation). This is a high priority very complex problem, and a solution is being worked.

Regarding issue https://github.com/WordPress/gutenberg/issues/17809, @youknowriad pointed $wp_version variable as a possible solution and provided a way to make it available in JavaScript.

@welcher asked more detailed feedback on https://github.com/WordPress/gutenberg/pull/16384 which adds a priority mechanism to the Slot&Fill pattern.

@mcsf and @youknowriad shared strong reservations.

It seems that priority and order are very visually focused, in stark contrast with how Gutenberg has tried to use SlotFill so far.

In Gutenberg, we talk about advanced settingsinspector, etc., instead of the visual element sidebar. Coming back to priority, what does it mean for SlotFill as far as selective rendering goes? how is a sequence determined semantically? etc.Why does this matter? Well, the bridging of different platforms and environments under Gutenberg is an important factor. If a codebase needs to work transparently across Web and Mobile, for example, its semantics needs to be clear and independent of a particular visual expression (e.g. Web on Desktop)

@mcsf

@mkaz had a docs related question:

How do y’ll feel about ES5 support in documentation? Most of the code and package docs are ESNext, but we show ES5 examples first in docs. I don’t have a proposal together yet, but I feel we should move people quicker to ESNext since it is what they most likely will experience everywhere.

People agreed that the default docs should be ESNext but ES5 examples should still be present.

#core-editor, #editor-chat, #meeting, #summary

Dev Chat Agenda for October 9 2019 (5.3 week 8)

Here is the agenda for the weekly meeting happening later today: Wednesday, October 9, 2019, 20:00 PM UTC. Please share any items you’d like to include in the comments below!

  • Announcements and highlighted posts
  • Upcoming Release Discussions
  • Calls from component maintainers
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-3, #agenda, #dev-chat