chris_d_adams

Hmm.. removing this line shows the image, but I’m now unable see the a new version of the cropped image in the back end admin after doing this.

I’m able to see the new photo in the file system, and hitting the url directly shows the updated photo, but when displayed in the WP admin interface and the actual crop screen, the old image is still persisting.

I’m assuming the radom part of the url was referring to some kind of caching before, but I don’t know enough about caching and php to go any further than this.

Any ideas on where to look to work out how to debug this?

I get this behavior when WP-cache switched on and with it off, and I’m using WordPress 3.1.1 and php 5.3.4 on OS X for development.

Thanks the plugin otherwise – apart from this wrinkle, it’s a lovely piece of work ??

I’ve had a similar issue here, which I resolved by removing the ?radom parameter from the API call in the function user_avatar_fetch_avatar in user-avatar.php, so the output url moves from this:

https://example.com/wp-content/plugins/user-avatar/user-avatar-pic.php?id=1&w=150&radom=1303064666

To this:

https://example.com/wp-content/plugins/user-avatar/user-avatar-pic.php?id=1&w=150

What does radom refer to here in this plugin ?

I don’t see any references to it anywhere else in the code, and I had no luck googling for the phrase either.

stvwlf, I just wanted to say thanks for flagging up the database table naming issue here in the forums – it helped me work out what was going wrong when a site I moved across had stopped working.

C

Oh, hang on, found it.

The database table prefix on the previous host had a load of autogenerated crap like wp_43h2ac2_posts because it was an automated script like fantastico.

I had been a bit overzealous when renaming the database tables, and took the whole prefix off, which confused the app.

Silly mistake, but hopefully somebody will learn from my folly.

Have a good weekend!