Opened 12 years ago
Closed 5 years ago
#21295 closed feature request (duplicate)
Retroactively generate new images sizes if requested
Reported by: | TwoThirdsWater | Owned by: | |
---|---|---|---|
Milestone: | Priority: | low | |
Severity: | normal | Version: | |
Component: | Media | Keywords: | has-patch |
Focuses: | Cc: |
Description
At present the image variations are created at the moment the image is uploaded to the server. If a new image size is later added, or the default ones changed after an image is uploaded then the existing images are not adjusted.
Whilst there are plugins that provide - regenerate thumbnail functionality it might be neater if an image size is requested that doesn't exist that the system generates it at the time it is requested. This only need happen once per image as once it is created it doesn't need to be created again.
Attachments (1)
Change History (25)
#3
@
11 years ago
- Milestone Awaiting Review deleted
- Resolution set to duplicate
- Status changed from new to closed
Duplicate of #15311.
This ticket was mentioned in IRC in #wordpress-dev by markoheijnen. View the logs.
10 years ago
#5
@
10 years ago
- Milestone set to 4.1
- Resolution duplicate deleted
- Status changed from closed to reopened
Reopening this ticket to only focus on the missing image size scenario. #15311 can deal with stop generating image sizes (and/or regenerate when parameters got changed).
Added a patch with the basic idea and moved it to 4.1 milestone for consideration to be included.
The only issue I currently having is that the new code will always be called when the image will be upscaled (#21294 and #19872)
#6
@
10 years ago
I wrote plugin for something like this: https://wordpress.org/plugins/optimize-images-resizing/
Note: it also removes all generated image sizes (except the default WP ones) and generates them only if requested.
#8
@
10 years ago
I like this idea as a first step.
markoheijnen, would you mind commenting this up so that it's clear to everyone what's going on in the patch?
#9
@
10 years ago
- Keywords 4.2-early added
- Milestone changed from 4.1 to Future Release
Will be working on what Mike mentioned. To late for 4.1
This ticket was mentioned in Slack in #core by eric. View the logs.
10 years ago
#12
@
10 years ago
- Milestone changed from Future Release to 4.2
has-patch 4.2-early so moving to 4.2.
This ticket was mentioned in Slack in #core by drew. View the logs.
10 years ago
#15
follow-up:
↓ 20
@
10 years ago
I am not super into this, since it would cause database writes on the front end, which is problematic if you have a read-only cluster and/or datacenter. There is also no locking mechanism, so this is susceptible to stampedes.
#16
@
10 years ago
- Milestone changed from 4.2 to Future Release
- Summary changed from Retrospectively generate new images sizes if requested to Retroactively generate new images sizes if requested
Not seeing much developer buy-in for owning this, punting from 4.2. It can always be brought back if somebody wants to own it.
#17
follow-up:
↓ 24
@
10 years ago
Not concerned about this being punted out of 4.2, however, if there's a way to get this picked up early in the next cycle, the ability to retroactively produce crops on request could be very useful as we work on a responsive images solution.
Also, there seems to have been a lot of good work put into solving this issue both here and on #15311, including discussion about adding some race conditions to keep servers from exploding, as @wonderboymusic noted above. Any chance we could merge these two tickets (i.e., close one and continue on the other)?
This ticket was mentioned in Slack in #feature-respimg by helen. View the logs.
9 years ago
#20
in reply to:
↑ 15
@
9 years ago
Replying to wonderboymusic:
I am not super into this, since it would cause database writes on the front end, which is problematic if you have a read-only cluster and/or datacenter. There is also no locking mechanism, so this is susceptible to stampedes.
Is it possible to have it as checkbox option disabled on default, as many other options in Settings ?
So we can use it only when needed, or for something like annual maintenance, or when developing.
This ticket was mentioned in Slack in #core-images by sergey. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-media by mike. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-media by mike. View the logs.
7 years ago
#24
in reply to:
↑ 17
@
5 years ago
- Milestone Future Release deleted
- Resolution set to duplicate
- Status changed from reopened to closed
Replying to joemcgill:
Also, there seems to have been a lot of good work put into solving this issue both here and on #15311, including discussion about adding some race conditions to keep servers from exploding, as @wonderboymusic noted above. Any chance we could merge these two tickets (i.e., close one and continue on the other)?
Yes, implementing this would need "locking" of the image/meta/sub-size while the new file is being generated and saved which is not trivial.
Closing this in favour of #15311 seems best.
Related/duplicate: #15311