Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tripflex opened this issue Feb 17, 2020 · 11 comments
Open

Comments

@tripflex
Copy link
Collaborator

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 ?

@richardmtl
Copy link

@Braehler
Copy link

Braehler commented Mar 2, 2020

@richardmtl
this is based on the topic in the suppprt forum and my discussion with @tripflex during a support issue and what he found out

@wgicio
Copy link

wgicio commented Mar 24, 2021

has it been resolved yet? having issues with listings not showing the scaled images

@wgicio
Copy link

wgicio commented Mar 25, 2021

WordPress rotating images also fails with job manager

eg DSC_0552-rotated.jpg

This is also not working:(

@tripflex
Copy link
Collaborator Author

tripflex commented Apr 7, 2022

ping @jom @fjorgemota @gkaragia or whoever is still apart of this project? Seeing this issue starting to happen more and more frequently

@wgicio
Copy link

wgicio commented Apr 8, 2022

ping @jom @fjorgemota @gkaragia or whoever is still apart of this project? Seeing this issue starting to happen more and more frequently

Coincidentally I checked back on this issue yesterday to see if it was only me having the problem, clearly not!

@tripflex
Copy link
Collaborator Author

@onubrooks June is almost over ...

@gikaragia
Copy link
Contributor

Hey @tripflex this is a label that we use to track our current and future work, not about what will be fixed in June.

@tripflex
Copy link
Collaborator Author

tripflex commented Feb 6, 2024

4 years later and this is still an issue guys .....

@mikeyarce @yscik @fjorgemota @gkaragia

@thedebian
Copy link
Contributor

thedebian commented Feb 7, 2024

Hi there @tripflex,

In 4 years, quite a lot of things happened in WPJM, and I understand it can be frustrating seeing things moving forward and having your own request still not being updated.

We're trying to sort out priorities by project, emergency, and number of requests, and we're a small team, which means we sometimes have to prioritize things differently than you'd expect them to be prioritized.

There's also no need to ping anyone if you don't have a specific question in mind, we regularly skim through the backlog to reprioritize existing issues; as long as your issue is here, we know it's here.

All that said, WP Job Manager is also an open source project, if you feel things are not going the way you'd like them to go, you still have the power to submit a PR, we'll be happy to review it and see how it'd fit in the core.

@Gnodesign
Copy link
Collaborator

Could you guys please prioritize this for the next update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants