WordPress.org

Make WordPress Core

Opened 22 months ago

Last modified 12 months ago

#22100 new enhancement

Treat built-in image sizes the same as custom image sizes

Reported by: scribu Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Media Keywords: has-patch needs-refresh
Focuses: Cc:

Description (last modified by scribu)

Goals:

  1. Have a solid API for working with intermediate image size definitions.
  1. Don't hardcode default image sizes; register them like any other.
  1. Introduce a 'pregenerate' arg, which will allow defining an image size that will not be automatically generated right after upload.

Related tickets: #15311, #21810

Attachments (4)

22100.diff (9.8 KB) - added by scribu 22 months ago.
22100.2.diff (10.9 KB) - added by scribu 22 months ago.
22100.3.diff (10.7 KB) - added by scribu 21 months ago.
22100.4.diff (10.8 KB) - added by scribu 21 months ago.

Download all attachments as: .zip

Change History (36)

scribu22 months ago

comment:1 scribu22 months ago

  • Keywords has-patch added

22100.diff is a first stab at register_image_size(), image_size_exists() etc.

TODO: generate the post-thumbnail size during set_post_thumbnail(), to avoid CPU spikes:

http://core.trac.wordpress.org/ticket/21961#comment:3

comment:2 scribu22 months ago

  • Summary changed from Introduce register_image_size() to Get rid of $_wp_additional_image_sizes

comment:3 ocean9022 months ago

  • Cc ocean90 added

scribu22 months ago

comment:4 scribu22 months ago

22100.2.diff makes add_image_size() accept an array of arguments, to avoid the hassle of deprecating it.

comment:5 scribu22 months ago

  • Description modified (diff)

comment:6 prettyboymp22 months ago

  • Cc mpretty@… added

comment:7 prettyboymp22 months ago

Patch works well, also fixes #19889

comment:8 skithund22 months ago

  • Cc toni.viemero@… added

comment:9 Mamaduka22 months ago

  • Cc georgemamadashvili@… added

comment:10 prettyboymp22 months ago

Noticed that the wp_numeric_to_assoc() function was labeled as '@since 3.6.0'. Does that mean that this is very unlikely to be included in 3.5 even though it fixes #19889?

comment:11 scribu22 months ago

  • Milestone changed from Awaiting Review to 3.5

Well, the patch was meant as a more general effort to clean up the intermediate image sizes API, but it seems simple enough to make it in 3.5.

comment:12 goto1022 months ago

  • Cc dromsey@… added

comment:13 prettyboymp21 months ago

Added patch to #15311 which uses 22100.2.diff as a base to add the late image generation.

comment:14 greenshady21 months ago

  • Cc justin@… added

comment:15 johnbillion21 months ago

  • Cc johnbillion added

comment:16 scribu21 months ago

So, there's 3 kinds of behaviours:

1) Always generate size, immediately after upload.

This is what the 'pregenerate' flag currently enables.

2) Generate file after a certain condition is met, but before it will be actually needed on the front-end.

This is what needs to be implemented for 'post-thumbnail', during set_post_thumbnail().

Doing the generation via AJAX seems like overhead, but it might actually make sense in some cases.

3) Generate file right before it's needed. See #15311.

Anyway, for 3.5, we'll probably just continue to always pre-generate post thumbnails and get rid of the 'pregenerate' flag for now, since I'm not exactly happy with the name and the use-case isn't obvious either.

Last edited 21 months ago by scribu (previous) (diff)

scribu21 months ago

comment:17 scribu21 months ago

22100.3.diff gets rid of 'pregenerate' and sets @since tags to 3.5.

comment:18 scribu21 months ago

  • Description modified (diff)

comment:20 bradt21 months ago

  • Cc brad@… added

comment:21 scribu21 months ago

  • Summary changed from Get rid of $_wp_additional_image_sizes to Treat built-in image sizes the same as custom image sizes

In the devchat today, the consensus was that removing the $wp_additional_image_sizes global is not worth the grief it will cause for third-party devs that had to access it directly until now.

So, instead of introducing a new $wp_image_sizes global, I'm going to update the patch to use the existing one. The only difference in structure is that one stores objects, while the other stores associative arrays.

scribu21 months ago

comment:22 scribu21 months ago

Pretty happy with 22100.4.diff:

  • still uses $_wp_additional_image_sizes, so no back-compat worries
  • allows arbitrary data to be stored per image size, just like for post type or taxonomy objects
  • made argument order in get_intermediate_image_sizes() saner
Version 0, edited 21 months ago by scribu (next)

comment:23 scribu20 months ago

#19889 was marked as a duplicate.

comment:24 nacin20 months ago

  • Milestone changed from 3.5 to Future Release

This would be nice, but it's not necessary for 3.5, and would be coming in a bit late (and was close to original freeze when it was worked up). Feel free to revive early in the future.

comment:25 prettyboymp20 months ago

If this is getting bumped to Future Release, can we consider one of the patches to fix #19889? We're currently having to patch all of our WP installs or have the client not use the image editor.

comment:26 markoheijnen19 months ago

#23019 was marked as a duplicate.

comment:27 follow-up: markoheijnen19 months ago

In tickets #23009 and #23019 was brought up that crop isn't always a boolean. This isn't a big thing but would be awesome that this is also taken care of in this ticket.

Also curious if we can mark this for 3.6 or not.

comment:28 in reply to: ↑ 27 anatolbroder19 months ago

  • Cc anatol@… added

Replying to markoheijnen:

In tickets #23009 and #23019 was brought up that crop isn't always a boolean. This isn't a big thing but would be awesome that this is also taken care of in this ticket.

Not only the crop but height and width have a not appropriate type too. Just write (int) or (bool) before the get_option. Thanks.

comment:29 scribu19 months ago

  • Milestone changed from Future Release to 3.6

comment:30 scribu18 months ago

  • Keywords needs-refresh added

comment:31 SergeyBiryukov14 months ago

  • Milestone changed from 3.6 to Future Release

comment:32 mau12 months ago

  • Cc ngomau@… added
Note: See TracTickets for help on using tickets.