Opened 5 months ago
Closed 5 months ago
#48302 closed defect (bug) (fixed)
Big Image: Provide function to get original file URL
Reported by: | kraftbj | Owned by: | azaozz |
---|---|---|---|
Milestone: | 5.3 | Priority: | normal |
Severity: | normal | Version: | 5.3 |
Component: | Media | Keywords: | has-patch |
Focuses: | Cc: |
Description
After r46076, for big images, the original file is saved as attachment metadata outside of the sizes array. This can make it a bit of an extra work to get the original URL for an image.
Akin to wp_get_original_image_path()
, we should add a wp_get_attachment_original_image_url()
as a complement to wp_get_attachment_image_url
.
This will make it easier for plugins to retrieve an URL for the highest quality version available.
Attachments (3)
Change History (14)
This ticket was mentioned in Slack in #core-media by mike. View the logs.
5 months ago
#4
@
5 months ago
Would it be better to just improve wp_get_attachment_image_url() with $size = 'original' (fall-back to 'full') rather than a whole new function for that purpose? Just throwing it out there!
#5
@
5 months ago
Would it be better to just improve wp_get_attachment_image_url()
Open to it. I went, in part, on the prior art of wp_get_original_image_path()
coupled with wanting to avoid figuring out a potential conflict with someone having set an "original" additional image size.
Since the original image isn't technically an image size in how WP stores that, I felt okay to not try to stuff too much together.
#6
@
5 months ago
Yeah, I did wonder if there could be conflicts, though it seems 'original' would be an odd name to use for a scaled version. But I suppose it IS possible, and that'd be difficult to find any instances of folks using such a size name.
#7
@
5 months ago
After r46076, for big images, the original file is saved as attachment metadata outside of the sizes array. This can make it a bit of an extra work to get the original URL for an image.
This is intentional. The logic here is that the original file is stored but not used as the "largest" size anywhere. Same as if the user has scaled down the image before uploading it.
In these cases the original is used only to make new image sub-sizes as they will be of better quality.
If there are compelling user cases where the original, usually not suitable for web use, image is needed on a regular basis, I don't mind adding a core function to facilitate it. But if there isn't such case, why would that function be needed in core?
#8
@
5 months ago
- Milestone changed from 5.3 to 5.4
Unfortunately this ticket was opened only few hours before 5.3-RC1. Going to move it to the 5.4 milestone for now but it can still be considered for 5.3 if a compelling user case exists.
#9
follow-up:
↓ 10
@
5 months ago
If there are compelling user cases where the original, usually not suitable for web use, image is needed on a regular basis, I don't mind adding a core function to facilitate it.
The primary use case I had in mind is for lightbox or image carousel plugins will sometimes have a "View Original" or similarly worded link to the full-size image so visitors can edit it, print it, etc.
#10
in reply to:
↑ 9
@
5 months ago
- Milestone changed from 5.4 to 5.3
Replying to kraftbj:
The primary use case I had in mind is for lightbox or image carousel plugins will sometimes have a "View Original" or similarly worded link to the full-size image so visitors can edit it, print it, etc.
Okay, lets fix this. There was almost identical function in the initial patch on #47873. It didn't get in as it wasn't used in core, but making it easier for plugins is better. Otherwise we'll end up with plugins adding their own, identical functions.
Moving this into the milestone for consideration/visibility.