Separate Image sizes for different post types

[brandondove]

Would be nice, especially moving forward with custom post types to have the ability to set different image sizes using an additional parameter of add_image_size() for different post types: Page, Post, and Custom.

[billerickson]

I also think this would be very useful. I'm often creating post types that require multiple image sizes (like a Gallery post type), but there's no reason to resize every image uploaded to that size.

[billerickson]

getting rid of all these keywords

[markoheijnen]

I think this ticket can be closed since the problem isn't the ability to define a post type to an image size. The problem is that everything is getting created on the fly. And we should find a way to do that. See #15311

[MikeSchinkel]

Replying to markoheijnen:

I think this ticket can be closed since the problem isn't the ability to define a post type to an image size.

I will disagree with that. Our team has implemented what is effectively a register_image_type() function and it is both solving a very real need and working extremely well for us.

There are many cases in plugins you need to be limit based on image type or to validate on image type. If I need to give a user the ability to upload an image for a custom post types, let's say for a "Case Study" I would like to be able to limit them to cropping to aspect ratios that are appropriate for the "case study featured image", for example.

This requirement is pervasive in the work we are doing for our main clients. We have it built it to our plugins but we'd far prefer to see that requirement handled by an API in core, and I'm confident that core would find many uses for leveraging it over coming releases.

The problem is that everything is getting created on the fly. And we should find a way to do that. See #15311

Yes, I can see that as another issue too (one our team has also implemented), but it's a requirement that is orthogonal to image types.

[markoheijnen]

It seems you go the other direction now at the ticket described. We are talking about generate a certain image size for a certain post type.
Also that is something that can probably be done in WordPress.

I still think #15311 is the way to go. You can select there which images to auto generate and which not. This ticket will need that since it will be a pain in the beginning for adding new sizes for existing content. Since plugins need to build on the demand.

[helen]

#23105 was marked as a duplicate.

[aaronholbrook]

Coming in from #23105: ​as I suggested in the dev chat for the 3.6 roadmap today, being able to limit image sizes to specific post types is a good idea and received positive feedback from both MarkJaquith and danielbachhuber for inclusion in 3.6.

MikeSchinkel, would you be able to share your code for your register_image_type() function/etc?

[markoheijnen]

First to temper your expectations. There isn't really said in words that this should be include for 3.6.

My arguments still stands that the problem isn't in define a post type to an image size but with the ability to generate an image size on-the-fly or just by simpel code. Jkudish also mentioned this in the chat:

"what if the image is uploaded in the media library w/out being attached to a post? or what if it's attached to 2-3 different post types?".

That is from my point of view a problem that isn't easy to fix or even not fixable. In my cases I never attach an image to a post. That doesn't make sense.

As I mentioned you already can create images with WordPress without the need of add_image_size. It's even more easier now in 3.5 with (WP_Image_Editor) then ever before. I do have some ideas to make it even more easier to generate images with a few lines of code and that it's added to the metadata array of a certain image.

As conclusion is close this ticket in favor of others. Also what is next? Add an image size to a post format, maybe a taxonomy etc.

[MikeSchinkel]

Replying to aaronholbrook:

MikeSchinkel, would you be able to share your code for your register_image_type() function/etc?

I've been planning to share it after refactoring out the code not related to the core approach but client projects have continued to get in the way. It's still on my todo list though...

[wonderboymusic]

No patch in 3 years - in most scenarios, images should be completely agnostic to where they are attached. How does this work if you upload from Add Media modal vs Media Grid vs Add New Media?

[michael.ecklund]

There's also been discussion about this on [WordPress Stack Exchange chat](​http://chat.stackexchange.com/transcript/message/33588572#33588572) with some good back and fourth arguing both sides.

Just to highlight some key points here....

---

This opens up several problems:

• If I put the image inside one of my blogposts, it triggers an image resizing operation
• If I remove the image from my page it doesn't remove the now redundant landscape files
• If I upload an image in the media library without attaching it, none of these or all of these sizes are created
• This functionality instantly breaks on any plugin that uses the media_handle_sideload type functions
• Importing and exporting would need special cases to make sure that the images referenced also include references to the original image, with the content updates necessary to make sure they still work on the final install
• This doesn't account for term featured images and non-post uses and a great number of other problems, there's a separation of concerns for a reason not to mention that if the on demand generation fails, you can trigger it repeatedly to start a DOS attack

---

Adding more rules might let you optimize disk space and be more precise about certain things, such as where images can be used and what sizes they're created in. but that adds constraints, which while helpful for some, are obstacles for others.

If you just specify in the FIRST PLACE that hey. These image sizes are only available in the scope of this post type. That's the intended functionality. Those are the rules. If you don't like it, then define your own rules as deemed necessary.

---

Image is uploaded. Multiple image sizes are created based on this uploaded image.

Consider this:

• Who is specifying the need for this image size?
• What is this image size going to be used for?
• When will this image size be used?
• Why will this image size be useful?
• Where will this image size be used?

Example answer set by a WordPress Developer:

• Who is specifying the need for this image size?

The person who wrote the code adding it

• What is this image size going to be used for?

Core doesn't know that, and it's not such a simple question to answer, but the person who added the image size knows

• When will this image size be used?

The developer might have a use case idea, but nobody can be certain, afterall I might add an image size for a particular use, only to find my users really like the way it looks right aligned in a post

• Why will this image size be useful?

The developer adding that has to make that call, and we can't know every answer, but there's also the users editorial decision when presented with that option

• Where will this image size be used?

That's highly dependent on who added the image and what they wanted to use it for. It might be that the theme wants an image size to match a header for the post, but that image size might be used elsewhere. Constraining that would cause problems for existing users and sites

---

Who/what provides the information available? The theme or the plugin?

The plugin author says, "hey theme. Here's what I have for you."

The them author responds by saying, "Hey plugin, You don't have what I'm looking for, can you get me this as well please? "

\*\* ADDS NEW IMAGE SIZE \*\*

---

[netweb]

Moving reopened tickets without a milestone back to Awaiting Review for review

[swissspidy]

#28325 was marked as a duplicate.

[swissspidy]

#39813 was marked as a duplicate.

[galbaras]

It may be better to not use post types, but allow plugin and theme developers to manage things via hooks and extra parameters, with old-style calls defaulting to "everything/everywhere".

Images can have a new classification, which allows more than one selection. When uploaded, they can be designated "post image", "product image", etc.

add_image_size() can be extended to accept an array of pre_registered designations, via a new function, say add_image_designation(), which accepts a name and a title.

After an image is uploaded and classified, WordPress can generate the supposedly-correct thumbnails.

Similarly, after editing the classification of an image, WordPress can adjust the thumbnails, possibly without ever deleting files.

srcset handling can follow image classification.

It is the responsibility of the developer and the content creator to use the correct images, but WordPress can help by allowing image selection by designation when embedding with Add Media.

This can be made easier by linking content types with image designations, and then allowing only images matching the content type to be embedded.

[Howdy_McGee]

I think we could close this issue. From my understanding we could use the intermediate_image_sizes filter hook to manage image sizes per post type. In this hook we should either get the post ID or post type:

<?php
add_filter( 'intermediate_image_sizes', function( $image_sizes ) {
        
        // WordPress uses post_id and post_ID
        $request = array_change_key_case( $_REQUEST, CASE_LOWER );
        $type    = null;
        
        if( isset( $request['post_type'] ) ) {
                $type = $request['post_type'];
        } else if( isset( $request['post_id'] ) ) {
                $type = get_post_type( $request['post_id'] );
        } else if ( isset( $request['taxonomy'] ) ) {
                $type = $request['taxonomy'];
        }
                
        switch( $type ) {

                case 'post':
                        $image_sizes = array( 'thumbnail', 'medium', 'large', 'full', 'custom_size_image' );
                        break;

        }
                
        return $image_sizes;
        
} );

[galbaras]

This is a very clever, although the specific code provided isn't flexible enough to accommodate everything.

Still, we can use this idea as a way to implement the concept of registered image designations and size-to-designation mapping. Once these things are registered, the filter just needs to look up the designations for each size and compare with $request['post_type'], $request['taxonomy'], etc.

Alternatively, it may be possible to extend the intermediate_image_sizes filter to accept an array of designations (must be passed through a cascade of functions), or at least the context (e.g. 'post' or 'category').