Make WordPress Core

Opened 12 years ago

Closed 5 years ago

#21295 closed feature request (duplicate)

Retroactively generate new images sizes if requested

Reported by: twothirdswater's profile 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)

21295.diff (1.7 KB) - added by markoheijnen 10 years ago.

Download all attachments as: .zip

Change History (25)

#1 @SergeyBiryukov
12 years ago

  • Component changed from General to Media

Related/duplicate: #15311

#2 @SergeyBiryukov
12 years ago

#22697 was marked as a duplicate.

#3 @SergeyBiryukov
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

@markoheijnen
10 years ago

#5 @markoheijnen
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 @OriginalEXE
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.

#7 @wonderboymusic
10 years ago

  • Keywords has-patch added

#8 @kirasong
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 @markoheijnen
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

#11 @markoheijnen
10 years ago

#30874 was marked as a duplicate.

#12 @iseulde
10 years ago

  • Milestone changed from Future Release to 4.2

has-patch 4.2-early so moving to 4.2.

#13 @DrewAPicture
10 years ago

  • Priority changed from normal to low

This ticket was mentioned in Slack in #core by drew. View the logs.


10 years ago

#15 follow-up: @wonderboymusic
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 @helen
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: @joemcgill
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

#19 @obenland
9 years ago

  • Keywords 4.2-early removed

#20 in reply to: ↑ 15 @Stagger Lee
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.

Version 0, edited 9 years ago by Stagger Lee (next)

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 @azaozz
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.

Note: See TracTickets for help on using tickets.