[Plugin: Regenerate Thumbnails] Broken badly!!!

“undefined” is the full and exact error message? How weird.

If you use Firefox, can you install the Firebug addon and see what the result of the AJAX request is? You can find it under the “Net” tab and then by expanding one of the AJAX requests while the plugin is running.

Here’s a video on how to do that:

https://screencast.com/t/KgVxwgJjaPD

You’re in luck: I use firefox and yes, firebug is up and running… and I didn’t need that screencast either. ??

Sooo, let’s dig into it…

As for what ajax returns: something I would call “a json-ed array with empty positions”. Therefore, I guess the “undefined” is a logical return we’re seeing.

Trying to narrow it down yesterday, I detected the plugin does not have a hard time doing an “initial run” on new images (as they work), but as soon as a “rerun” occurs, even those working images render non-working, returning the same “undefined” results.

My best guess – for what it’s worth – is that the plugin fails parsing the META of the images somehow. Probable a de-json thingy, where some data get’s lost due to a parsing-problem. Why? Because in case of “undefined”, none of the “undefined” images get scaled and the meta stored back in the database kills thumbnail usage by only returning the original, full-size image later on.

Love me or hate me, but I created a fresh install on my home server… created some posts, adding post-thumbnails to it. First run: all ok… 2nd run: all “undefined”, post_thumbnails return original images, not resized ones.

Wrapping it up:

-> Create a post, add a post-thumbnail to it. Works.
-> Run the plugin. Seems to work fine…
-> Checking the post… post_thumbnail(); returns the original size image, no thumb (although the thumbnail itself exists on the server)
-> Rerun the plugin again… the “undefined” message shows up AND (as before) post_thumbnail(); returns the original size image, no thumb (although the thumbnail itself exists on the server).

I might be wrong – but as said: my best guess is that there’s something wrong while the plugin parses the post-image-meta for the first time. When the plugin writes it back to the database – the thumbnail info is allready lost, so the original, full-size image data gets stored… but nothing else. Reruns of the plugin seem to be a quite good proof of that.

What you should know: I recently (last week as far as I remember) updated the plugin and I updated wordpress to 3.0.2 two days ago.

Before that, all worked. Since I can’t find anything buggy in wordpress itself that can reproduce the error, I think the answer might be found in the difference between your previous plugin version and the current one (which allready seems to be supporting the upcoming WP 3.1). If I were in a devteam with you, I would simply ask: “what did you change”?

Wow, long message. Hope it helps you. If you need any more infos, please feel invited to contact me. I will try to do my best to provide useable feedback. (Please feel invited to drop an e-mail to “e-sushi” at “gmx.net” or simply find the rest of my contact info at e-sushi.net)

If I were in a devteam with you, I would simply ask: “what did you change”?

2.1.3: https://plugins.trac.www.ads-software.com/changeset/316860/regenerate-thumbnails

2.1.2: https://plugins.trac.www.ads-software.com/changeset/316344/regenerate-thumbnails

The changes made in 2.1.3 are unlikely to affect this, but the 2.1.2 changes could possibly. I develop my plugins using WordPress trunk (which is 3.1 alpha currently), but I’ve also tested this plugin under 3.0.2 and I can’t reproduce your issue. It regenerates previously uploaded images just fine.

Either way, my plugin uses two core WordPress plugins to do the work. One to re-do the thumbnails and spit back the meta data array and another function to save that meta data. It’s identical to when you first upload an image as far as I know.

So I have no idea. ??

Looking at the changeset for 2.1.2, perhaps wp_generate_attachment_metadata() is spitting back a WP_Error with a blank error message? Hmm.

You can find a few older versions of the plugin here:

https://www.ads-software.com/extend/plugins/regenerate-thumbnails/download/

Since I nailed it down to the mySQL metadata stuff being messed up, your idea could be showing the direction of a solution to the problem.

I’ll check on the older plugin this weekend, trying to reproduce the thing. Also, I’ll test both WP 3.0.1 and WP 3.0.2 to see if it’s the core or the plugin. Who knows, something “slipped through” in the 3.0.2 release…

Thank’s for your feedback though! I’ll keep this thread open until I can post some results from my testing-frenzy in a day or two.

Erm… after re-reading your answers… please note that this error/issue seems to affect “post_thumbnails” and not “ye regular images” you can set using the “media” options set of WordPress. Maybe there’s something different in the way both images are handled (functions.php thumbnail configurations and WP meta-options) which causes the issue when stuff gets (re)stored in the database as json serialized meta.

The issue itself doesn’t seem to kill the images… it simply seems to “forget about the thumbnails”, resulting in the fact that wordpress simply returns the code for the original image instead of the thumbnail… in other words: post_thumbnail() returns the full-size image, ignoring any “functions.php” thumbnail setting. Rerunning the plugin doesn’t fix it either. Once the plugin runs for the first time, the meta is mixed up… as said, making wordpress return the original, full-size images.

In the end, this might even prove that it’s the meta for sure that is getting messed up.

Post thumbnails vs. normal images shouldn’t matter.

Forgetting the thumbnails is because the meta data returned is used to keep track of what size thumbnails exist. When post_thumbnail() goes to get a thumbnail, it uses the fullsize because it doesn’t think any thumbnails exist because of the improper meta data.

‘kay, so that’s where the problem is then.

Meanwhile, I opted out of the plugin and created my own script. As it turns out, not all that hard. Thank you anyway… and good luck bug-hunting!

Wait, so some code you wrote is working fine but mine is still broken? Can you share the code you’re using? I’m using the WordPress API (essentially copy/pasted out of core), so I don’t know why mine wouldn’t work. ??

Any updates on this? I have the same issue.

I have two thumbnail sizes:
‘add_theme_support( ‘post-thumbnails’ );
set_post_thumbnail_size(200, 100, true);
add_image_size( ‘related-thumbnail’, 100, 100, true ); // W, H, hard crop mode true

And if I regenerate one at a time, only the most recently generated size displays properly. If I regenerate both thumbnail sizes at the same time, only the 200×100 thumbnail works properly.

Sorry, wrong plugin. Ignore the above post. I was using AJAX thumbnail rebuild and got them confused.

(On a side note, I just deactivated AJAX Thumbnail Rebuild & installed and activated Regenerate Thumbnails, but after clicking regenerate all thumbnails, it takes me to the page where you’re supposed to wait for the progress, but nothing happens. So I’m not having luck with either it seems ?? oh well. WP 3.0.3 Regenerate Thumbnails 2.1.3.

One cool thing that AJAX Thumbnail Rebuild has that might be cool for RegenThumb is a listing of what image sizes your theme has defined, and tick boxes to select to regenerate all images of just the given sizes desired. Cheers.

On a side note, I just deactivated AJAX Thumbnail Rebuild & installed and activated Regenerate Thumbnails, but after clicking regenerate all thumbnails, it takes me to the page where you’re supposed to wait for the progress, but nothing happens.

Sounds like you either have it installed incorrectly (and the Javascript file can’t load) or another plugin is breaking my plugin’s Javascript. Checking your browser’s Javascript error console should tell you what’s going on.

One cool thing that AJAX Thumbnail Rebuild has that might be cool for RegenThumb is a listing of what image sizes your theme has defined, and tick boxes to select to regenerate all images of just the given sizes desired. Cheers.

My plugin uses the internal WordPress API to generate the thumbnails and to update the meta data for the upload and I’m pretty sure these functions don’t have the ability to selectively make thumbnail sizes. I would have to move away from using the API and that would be a bad idea (a lot more likely to break in the future or be incompatible with other plugins).

It’s best how it is.

hi,
your version 2.1.3 is broken!

i downgraded to 2.1.2 and everything worked right!

i’m using wordpress 3.0.3.

thanks for the plugin btw ??

Broken in what way? …

Broken in what way? …

But regenerating the thumbnails simply outputs “undefined” for all images, destroying all “thumbnail meta” stored in the database.

In answer to these: plugin v2.1.3 does not handle an error contained in the AJAX response, replacing it with “Undefined”. Specifically, the plugin does not display an error shown in the AJAX response (shown in Firefox w/ Firebug) which is thrown by the imagejpeg function in wp-includes/media.php:

<b>Warning</b>: imagejpeg() [function.imagejpeg]: Unable to open ‘/path_truncated/wp-content/uploads/2010/11/filename.jpg’ for writing in <b>/path_truncated/wp-includes/media.php</b> on line <b>453</b>

In this case, the status msg “Undefined” was caused by an error in the WP imagejpeg function, due to 755 permissions on the directory “../uploads/2010/11”. The directory 2010 and subdir 11 were both created manually, after manual (re)installation of wordpress and manual (re)creation of the uploads folder, and manual (re)FTP of all attachment image files.

To summarise, seems like a fix is needed in the plugins parsing of the AJAX response.

@alex M. (Viper007Bond)

Since more people are having the same problem as I do, a small question: did you fix that META-bug yet?

(JustAsking)