Fix: Store scaled image URL for file fields when WP 5.3+ big image scaling is active

[masteradhoc]

Fixes #1973

Changes Proposed in this Pull Request

• Added an optional &$actual_url by-reference parameter to create_attachment().
  When WordPress 5.3+ scales a large image during wp_generate_attachment_metadata(),
  the metadata will include original_image and _wp_attached_file will point to the
  -scaled version. actual_url is set via wp_get_attachment_url() in that case,
  giving callers the canonical URL WordPress has stored.

• Moved attachment creation inline within the field loop in update_job_data(), before
  update_post_meta() is called. This ensures wp_generate_attachment_metadata() runs
  first, so any scaled URL is resolved before being persisted to post meta — fixing both
  the served image (full-res was used instead of scaled) and attachment_url_to_postid()
  failures (stored URL didn't match the scaled URL WordPress recorded internally).

Testing Instructions

• Upload an image larger than 2560px (width or height) as a file field on a job listing
  submission form.
• Confirm the value saved in post meta points to the -scaled version of the image, not
  the original.
• Confirm attachment_url_to_postid() returns the correct attachment ID for the stored URL.
• Confirm listings with images under the threshold are unaffected.
• Confirm multi-file fields and the company logo field behave as before.

Release Notes

• Fixed an issue where the full-resolution URL was stored for image file fields when
  WordPress 5.3+ big image scaling was active, causing oversized images to be served and
  breaking attachment ID lookups.

New or Updated Hooks and Templates

Deprecated Code

Screenshot / Video

[azaozz]

Hi, regarding of handling (very) large images in WP 5.3+

actual_url is set via wp_get_attachment_url() in that case,
giving callers the canonical URL WordPress has stored.

Why is this needed? The idea in WP was to "ignore" as much as possible the uploaded file as it is not suitable for use on the internet. These are typically photos with dimensions larger than 2560px and sizes over 4MB. This type of images shouldn't be used on the internet however WP still stores them just in case the authors may need them later.

They are exposed for downloading on the attachment screen in WP. If the same thing is needed somewhere in the plugin maybe it would be better to link to there?

[masteradhoc]

Hi @azaozz, thanks for looking at this!

The problem is that WPJM currently stores the original (pre-scaling) URL in post meta, because create_attachment() was called after update_post_meta(). This means:

1. attachment_url_to_postid() fails for any stored URL on oversized images — breaking any plugin or theme that tries to resolve the URL back to an attachment ID.
2. The full-resolution file is served instead of the scaled one, bypassing the performance intent of WordPress's own big image feature.

This PR fixes both by ensuring wp_generate_attachment_metadata() runs before the URL is persisted to post meta, and then using wp_get_attachment_url() to retrieve the canonical (potentially scaled) URL that WordPress itself recorded — keeping everything consistent with how WP handles the attachment internally.