Automattic / Automattic/WP-Job-Manager

WordPress "scaled" image feature support, full res URL saved to listings

Open
#1,973 12 comments 3 reactions 0 assignees View on GitHub
Dominant language
PHP
Stars
899
Forks
369
Avg merge
11h 37m
Merged PRs (30d)
12

Description

https://make.wordpress.org/core/2019/10/09/introducing-handling-of-big-images-in-wordpress-5-3/

Introduced in WordPress 5.3, if an image is above a certain "threshold" (width or height), with a default of `2560`, WordPress will automatically created a "scaled" version of the image, signified by `-scaled` being added to the image name, resulting in an image like:
`XXX-scaled.jpg`

The issue with this is that the value saved for fields on listings, is the actual full res URL of the image, not the "scaled" version of the image. Technically these images still exist (as WordPress just creates an additional "scaled" version of the image), but there's two reasons I wanted to bring this up.

**Unable to convert URL to attachment ID**
The first issue is that any plugin or theme that attempts to convert the URL to an "attachment post ID" will fail, including calling the internal WordPress core `attachment_url_to_postid` function, since the value saved to listings is the not the "scaled" version, and when the attachment is inserted, the data is replaced with the URL to the "scaled" image (see below).

**Full Res Images are Served on Sites**
The other issue is that technically this feature of using "scaled" images will be disregarded by WPJM and the full res images will be served. By supporting the "scaling" feature of WordPress 5.3+, we can make sure that when the user has not specifically disabled the "scaling" feature, that the scaled images will be used -- speeding up site load times, as well as the issue mentioned above.

This only happens when the image is "attached" to a listing, and is triggered by the following:

1. WPJM->create_attachment
2. wp_generate_attachment_metadata()
3. wp_create_image_subsizes()
4. _wp_image_meta_replace_original()
5. wp_update_attachment_metadata()

It appears that this metadata is passed back to the `wp_generate_attachment_metadata` function called by WPJM, which includes the metadata saved to the "attachment post" including `original_image`

So IMO I think to resolve these issues, we should work on adding support for handling this "scaling" of images.

Specifically in the `wp-content/plugins/wp-job-manager/includes/forms/class-wp-job-manager-form-submit-job.php` file where we call `wp_generate_attachment_metadata` we can check the data returned to see if the image was in fact "scaled", we would just have to figure out how we would then update the data in `$values` to reflect this.

The problem is that `create_attachment` is called _**after**_ the metadata is updated/set in `update_job_data`, so we would essentially have to move things around a bit, or come up with the best way to handle this.

What are your thoughts @jom ?

Contributor guide

Open the contributing guide

Research direction

Start in wp-content/plugins/wp-job-manager/includes/forms/class-wp-job-manager-form-submit-job.php, focusing on create_attachment and the call to wp_generate_attachment_metadata. Trace how the returned metadata relates to update_job_data and the values saved for listings. Done means WordPress 5.3+ scaled images are reflected in listing data when scaling is enabled, without disrupting explicitly disabled scaling.

Written by the indexing model from the issue text.

Assessment

Tech stack
php, wordpress
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.