WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 2 years 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 3 years ago.
22100.2.diff (10.9 KB) - added by scribu 3 years ago.
22100.3.diff (10.7 KB) - added by scribu 3 years ago.
22100.4.diff (10.8 KB) - added by scribu 3 years ago.

Download all attachments as: .zip

Change History (36)

@scribu3 years ago

comment:1 @scribu3 years 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 @scribu3 years ago

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

comment:3 @ocean903 years ago

  • Cc ocean90 added

@scribu3 years ago

comment:4 @scribu3 years ago

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

comment:5 @scribu3 years ago

  • Description modified (diff)

comment:6 @prettyboymp3 years ago

  • Cc mpretty@… added

comment:7 @prettyboymp3 years ago

Patch works well, also fixes #19889

comment:8 @skithund3 years ago

  • Cc toni.viemero@… added

comment:9 @Mamaduka3 years ago

  • Cc georgemamadashvili@… added

comment:10 @prettyboymp3 years 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 @scribu3 years 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 @goto103 years ago

  • Cc dromsey@… added

comment:13 @prettyboymp3 years ago

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

comment:14 @greenshady3 years ago

  • Cc justin@… added

comment:15 @johnbillion3 years ago

  • Cc johnbillion added

comment:16 @scribu3 years 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 3 years ago by scribu (previous) (diff)

@scribu3 years ago

comment:17 @scribu3 years ago

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

comment:18 @scribu3 years ago

  • Description modified (diff)

comment:19 @scribu3 years ago

Related: #19393

comment:20 @bradt3 years ago

  • Cc brad@… added

comment:21 @scribu3 years 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.

@scribu3 years ago

comment:22 @scribu3 years ago

Pretty happy with 22100.4.diff:

  • 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
Last edited 3 years ago by scribu (previous) (diff)

comment:23 @scribu3 years ago

#19889 was marked as a duplicate.

comment:24 @nacin3 years 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 @prettyboymp3 years 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 @markoheijnen3 years ago

#23019 was marked as a duplicate.

comment:27 follow-up: @markoheijnen3 years 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 @anatolbroder3 years 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 @scribu3 years ago

  • Milestone changed from Future Release to 3.6

comment:30 @scribu3 years ago

  • Keywords needs-refresh added

comment:31 @SergeyBiryukov2 years ago

  • Milestone changed from 3.6 to Future Release

comment:32 @mau2 years ago

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