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

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

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

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

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

Patch works well, also fixes #19889

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?

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.

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

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.

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

Related: #19393

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.

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

#19889 was marked as a duplicate.

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.

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.

#23019 was marked as a duplicate.

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.

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.