search

Automattic / WP-Job-Manager

Manage job listings from the WordPress admin panel, and allow users to post jobs directly to your site.
https://wpjobmanager.com
GNU General Public License v3.0
901 stars 368 forks source link

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

Open tripflex opened 4 years ago

tripflex commented 4 years ago

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 commented 4 years ago

This came up in https://wordpress.org/support/topic/gallery-problem-24/

Braehler commented 4 years ago

@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 commented 3 years ago

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

wgicio commented 3 years ago

WordPress rotating images also fails with job manager

eg DSC_0552-rotated.jpg

This is also not working:(

tripflex commented 2 years ago

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

wgicio commented 2 years ago

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 commented 2 years ago

@onubrooks June is almost over ...

gikaragia commented 2 years ago

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 commented 9 months ago

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

@mikeyarce @yscik @fjorgemota @gkaragia

thedebian commented 9 months ago

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 commented 2 months ago

Could you guys please prioritize this for the next update?