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

Improve processing of uploaded images

As mentioned in dev chat on May 15 there are quite a few “stalled” tickets on Trac dealing with image processing/resizing after uploading:

All of these, and more, can be “unblocked” by: Save progress of intermediate image creation after upload #40439.

Fixing this will also enable “refreshing” of the way we do responsive images, and will enable improvements in how we generally work with images in the block editor. Then we will be able to enhance the Image block and make it “just work” regardless of the context, see Enhancement: images handling and more importantly https://github.com/WordPress/gutenberg/issues/6177#issuecomment-442953527.

In short: fixing the above tickets will greatly improve user experience especially when uploading large images or the server is slow/busy. It will also open the way for enhancing how we work with images in the editor, and let us show better fitting images on the front-end.

#media, #upload

If the Flash uploader isn’t working for …

If the Flash uploader isn’t working for you, you can now select a regular browser uploader.

#flash, #upload

TinyMCE, media uploader, and plugin upda …

TinyMCE, media uploader, and plugin updater fixes along with a slew of smaller bug fixes.

#media, #plugins, #tinymce, #upload

A bunch of media upload updates from And …

A bunch of media upload updates from Andy just landed.

#media, #ui, #upload