Automattic / Automattic/WP-Job-Manager
WordPress "scaled" image feature support, full res URL saved to listings
- 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
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