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

[scribu]

Goals:

0. Have a solid API for working with intermediate image size definitions.

1. Don't hardcode default image sizes; register them like any other.

2. Introduce a 'pregenerate' arg, which will allow defining an image size that will not be automatically generated right after upload.

Related tickets: #15311, #21810

[scribu]

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

[scribu]

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

[prettyboymp]

Patch works well, also fixes #19889

[prettyboymp]

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?

[scribu]

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.

[prettyboymp]

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

[scribu]

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.

[scribu]

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

[scribu]

Related: #19393

[scribu]

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.

[scribu]

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

[scribu]

#19889 was marked as a duplicate.

[nacin]

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.

[prettyboymp]

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.

[markoheijnen]

#23019 was marked as a duplicate.

[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.

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

[anatolbroder]

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.