Multiple custom image sizes with retroactive image reprocessing

[markjaquith]

You should be able to add multiple custom image sizes. And whenever you change or add a size, WordPress should offer to retroactively create images of that size for all your old uploads.

[Viper007Bond]

Previous work: ​http://wordpress.org/extend/plugins/regenerate-thumbnails/

[leogermani]

In this first patch I implement the posibility to add new custom image sizes to WordPress.

• It was made upon the patch submited on ticket: #10263 (my patch replaces this one)
• It does not "retroactively create images of that size for all your old uploads" yet.
• Ive put some css styles in the elements cause I was not sure where to put them (and there were really few of them)

[leogermani]

First patch to this ticket

[leogermani]

Second version of the patch. Works when javascript is disabled

[scribu]

Looks good.

It solves the first half of the problem. :)

[leogermani]

Good,

I can implement the second half, but I wanted more opinions on how it should work. I dont think it is a good idea to make it regenerate all images automatically on every change, because it is too heavy. Here are the approaches I am considering:

1. Have a button "Regenerate images" where the user clicks whenever he wants to regenerate all images thumbs

2. Whenever you change the values of a size, a box appears at the top of the screen informing that the changes do not apply to old images, but if (s)he wants to regenerate, 'click here'

In both cases I am thinking to do this trhough ajax so user have a constant feedback on each file beeing processed and is able to cancel the routine.

Opinions?

Leo

[scribu]

I think the second option would make more sense.

You have to use some combination of AJAX and possibly wp-cron to prevent timeouts and other limits.

Plugins that use this approach: Intense Debate, WP DB Backup.

Maybe you can work with Viper007Bond to improve the Regenerate Thumbnails plugin and then consider including it in core.

[leogermani]

The thing with the second option is that if the user dont click on the regenerate button as soon as he changes the values, he misses the chance and have to change the values again if he wants to reprocess the images. Perhaps leaving the 2 actions can be good.

Now one question. If we decide on an ajax approach. How would it work whithout javascript? Do you think it could be a JS-enabled-only feature?

[scribu]

Replying to leogermani:

The thing with the second option is that if the user dont click on the regenerate button as soon as he changes the values, he misses the chance and have to change the values again if he wants to reprocess the images. Perhaps leaving the 2 actions can be good.

Agree.

Now one question. If we decide on an ajax approach. How would it work whithout javascript? Do you think it could be a JS-enabled-only feature?

Actually, the AJAX would only be used to update the status without refreshing the page. The crunching would be done in the background anyway. Withot JS, the user would just see a static notice: "Regenerating images: 25% done." or something like that.

[scribu]

A plugin that regenerates the thumbs through AJAX has sprung up:

​AJAX Thumbnail Rebuild

[leogermani]

New patch (3). Retroactive image reprocessing

Added the regenerate all thumbnails funcionality

1. I did without ajax (at least for the moment). When I finished it I didnt see so much the need for an ajax alternative

2. I created a function called wp_update_thumbs - I though it was worth to have it so we can use in other places in the code, such as in the manage media page, I think there could be there a button to regenerate the thumbs for each image. It could be a button for each image and a bulk action

3. It patches the new "Edit Image" feature too

[leogermani]

Regenerate thumbnails

[scribu]

Patch needs refresh (patch rev: 11953, trunk rev: 12055)

Although I would really like this patch commited, 2.9 is already in feature freeze.

[leogermani]

updated to last trunk

[markjaquith]

I think it's too late for this for 2.9. I have another way I'd like to do it that doesn't involve laborious "rebuilding." I'd like WP's image attachment HTML output functions to check for the existence of a file in a specified size and build it on the fly if it doesn't exist.

[scribu]

Replying to markjaquith:

I think it's too late for this for 2.9. I have another way I'd like to do it that doesn't involve laborious "rebuilding." I'd like WP's image attachment HTML output functions to check for the existence of a file in a specified size and build it on the fly if it doesn't exist.

Sort of like TimThumb, right? The only issue would be: how do you get rid of files that aren't used anymore?

[scribu]

Replying to scribu:

The only issue would be: how do you get rid of files that aren't used anymore?

Right, a wp-cron job that regularly scans files using fileatime() will do.

[westi]

Discussed on Oct 22nd dev chat. Summary:

• Good idea to improve this area of WordPress
• Not sure about exact details or the reprocessing
• Need to discuss some more exactly what we want here.

[miqrogroove]

Replying to scribu:

how do you get rid of files that aren't used anymore?

Maybe a better question is why are thumbnails generated even when they are not used?

[Viper007Bond]

Replying to miqrogroove:

Replying to scribu:

how do you get rid of files that aren't used anymore?

Maybe a better question is why are thumbnails generated even when they are not used?

Because it's slow, complicated, and generally bad to generate them on the fly unless you have a good server.

[miqrogroove]

I keep forgetting the Media Gallery uses the small thumbnails. Anyway, I see there hasn't been agreement on whether or not to regenerate custom sizes on the fly. Let me just add that when I was working on the thumbnail system for XMB, we determined mass thumbnail regeneration was too CPU intensive to be viable in most environments. At that point we abandoned the idea as being counterproductive.

[leogermani]

Just to tell that I didnt give up on that.... I want to wait 2.9 release and then update the patch to the last trunk. I dont like the idea of the regenerating proccess beeing in the core too, so I will remove it.

I would really like more people to comment on that... I think this is a very good feature to go into 3.0

Leo

[miqrogroove]

Replying to leogermani:

I would really like more people to comment on that... I think this is a very good feature to go into 3.0

IMHO, being able to specify the image size in the post editor is the most needed feature. If I upload a 2000 x 2000 image, I'm given only the options defined in image settings. Regardless of how many choices are available, I might want something different. Currently it uses HTML attribute sizing, which is useless to an experienced web author. I'm not sure if that's on-topic though. The feature described by this ticket has more to do with thumbnails for theme changes?

[leogermani]

Screenshot of the Media option screen with the patch applied

[leogermani]

screenshot: adding a new size

[leogermani]

screenshot: setting the new size and saving

[leogermani]

screenshot: The Patch in action, add a picture screen shows the new size option for insertion

[leogermani]

Replying to miqrogroove:

The feature described by this ticket has more to do with thumbnails for theme changes?

Ive attached some screenshots to this ticket to make it easier to understand what this patch is all about.

It allows you to create many custom sizes. When you upload a picture, WP will generate copies of this image in all sizes you configured (if possible).

When you add a picture to a post, you will have the option to insert your sizes.

This patch also fixes ticket #10263

It is not updated to the latest trunk. I nedd to know if its going into 3.0 or not, so I can update the patch

[ShaneF]

All 'media' based new features are on hold and pushed to 3.1.x. Because of the SOW set for 3.0 this does not fall into that category.

[Denis-de-Bernardy]

see also #11895

[scribu]

A plugin for custom image sizes:

​Additional image sizes

[nacin]

Closing this as a duplicate of #15311 which is a more complete body of research and pool of ideas.