Topic: Avatar image problem – other fixes don’t work

Avatar image problem – other fixes don’t work

Peter Kirn
Participant

@peterkirn

15 years, 5 months ago

I’m having issues with group and individual avatar images; they result in broken image links. I have worked through the other FAQs / fixes to no avail.

Symptom:

Uploading and cropping avatars appears to go fine – it even displays the proper thumbnail for each.

The images themselves do not appear. Also, curiously, we get URLs like:

http://noisepages.com/File%20%27wp-content/blogs.dir/1/files/avatars/21/owen3.jpg%27%20is%20not%20an%20image

In that case, in fact, I look at that directory and the other images are there, but *not* the jpg (ie, owen3.png)

libjpeg is installed, but is it possible something somewhere isn’t finding it?

So far, have investigated:

* Changing directory permissions for blogs.dir (recursively) to 777. It’s set to our user:group that Apache, etc., uses and everything else is fine.

* safe_mode is OFF

* readfile function is NOT disabled

* Standard .htaccess

* Gd/libpng/libjpeg all seem to be fine.

* Currently on BuddyPress 1.0 (final, not RC – just upgraded from RC1)

* MU 2.7.1

* FreeBSD

I will say, the jpegs seem to be what are missing. libjpeg does itself seem to be working as we can upload and crop jpegs elsewhere.

I do NOT get the permissions error message – randomly got it once but otherwise just get a message saying the image was successfully updated (eg, when I change a group avatar)

I haven’t yet tried creating an avatar from scratch to see if that goes better.

Viewing 10 replies - 1 through 10 (of 10 total)

Peter Kirn
Participant

@peterkirn

15 years, 5 months ago

Actually, one note – as I look again, cropping jpgs in the upload facility seems not to work; could that be a symptom of a libjpeg issue (which in turn might prevent those jpgs from getting created in the avatar)?
Jeff Sayre
Participant

@jeffsayre

15 years, 5 months ago
Uploading and cropping avatars appears to go fine – it even displays the proper thumbnail for each..they result in broken image links.

According to your posts, you have no problems uploading and cropping an image file. They get added to the blogs.dir directory. Otherwise, you would not be seeing them displayed, as you state.

But then you state this:

I look at that directory and the other images are there, but *not* the jpg (ie, owen3.png)

[later you state]

the jpegs seem to be what are missing. libjpeg does itself seem to be working as we can upload and crop jpegs elsewhere.

Look at the link you’ve provided. Those two-digit numbers preceded by the % sign are a two-digit hexadecimal representation of special characters in the URL encoding.
```
%20 --> equals a space

%27 --> equals an apostrophe
```
So your URL really looks like this:

noisepages.com//File 'wp-content/blogs.dir/1/files/avatars/21/owen3.jpg' is not an image

Notice the space after the word “File” and the apostrophe before the “wp-content”. You also have more special characters after the jpg file extension.

Basically, this link is stating this:

'wp-content/blogs.dir/1/files/avatars/21/owen3.jpg' is not an image

What file type are you initially uploading for use as your avatar? Is it a jpeg or png? What size?
Peter Kirn
Participant

@peterkirn

15 years, 5 months ago

Hi Jeff,

Right, that makes sense — it’s effectively coding the exception into the URL, get that.

Basically, what works:

* uploading an image that’s the correct size (regardless of format)

* uploading an image and getting as far as on-screen cropping

What doesn’t work:

* the cropped image is not getting written to the directory (jpg)

* editing avatar images is not properly updating the URL reference in the database (png)

(and then that breaks the avatar if people use the wrong image size)

I’ve just tested this by editing the avatar on one of our groups. png vs. jpg is not an issue. If it’s a size other than the correct size — i.e., if it brings up the cropping interface — it just doesn’t work. It crops the thumbnail, then the full-size image — both correctly. It just seems not to be actually writing out the file.

So, with the jpg, I get dumped to a page that says “The group avatar was successfully updated.” Except that the image hasn’t updated, and if I navigate to that directory, no jpgs whatsoever have been written. The URL is

http://noisepages.com/wp-content/blogs.dir/1/files/avatars/2/oscemote.jpg’%20is%20not%20an%20image.

— which is correct, oscemote.jpg in this case actually is not there. That seems especially odd to me, that even the uncropped jpg is apparently not getting uploaded to the directory.

With the png, I get dumped to a 404 error — it correctly creates both the full-size and thumbnail images on-screen, but at the last step I get a 404 on the group avatar editing page.

The png’s actually ARE in the directory. So I have what is apparently the full-sized image, plus the cropped one — oscemote-300×450.png

But the avatar itself isn’t actually changed in that place; the URL is still pointing at the JPG.

Peter Kirn
Participant

@peterkirn

15 years, 5 months ago

I should add, of course, that non-cropped images aren’t a possibility with the avatars per se — the avatars require cropping.

And some images seem not to be getting uploaded at all. I’m guessing the ones that I’m seeing in the directory were the ones initially uploaded when someone first created a user or group?

Is there no way to disable the cropping routine? Or to delete an image once it’s been added to a reference?
Jeff Sayre
Participant

@jeffsayre

15 years, 5 months ago
Hum, I’m at a loss as to what is going on in your particular situation.

Jpegs can be processed via the file uploader and cropper. You get a message of success, but then they are not actually written to the blogs.dir directory.

PNGs on the other hand, have issue with the file uploader and cropper. You get a 404 message but then they actual DO get written to the blogs.dir directory.

So, the permissions and ownership of the blogs.dir directory must be okay. You are able to write to this directory.
1. What are the avatar file sizes that you are attempting to upload?
2. What are the sizes of the jpg versus png files?
3. What is your setting for for maximum upload size in WPMU’s backend: â€œSite Admin > Options > Max upload file sizeâ€?
4. Do you have the png file format added to the list of accepted upload file formats? This option is found just above the setting for maximum upload size.
I created a ticket in trac a few days ago that may be of interest, but I do not think that it is the primary reason for your issue.
Peter Kirn
Participant

@peterkirn

15 years, 5 months ago

Hi Jeff, thanks for your help – I’m still investigating.

1. File size seems not to be an issue, as we’re not seeing it work properly – ever. Maybe 50-100k, typically?

2. Again, seems not to be an independent factor, and neither jpgs nor pngs are working; they’re just exhibiting different symptoms. But both show up in preview, yet neither is getting used as the avatar.

3. 15000 kb max upload size.

4. Allowable formats: jpg jpeg png gif mp3 mov avi wmv midi mid pdf zip

So I guess that rules out the easy solutions. Sounds to me like maybe this is still some strange Gd/libpng/libjpeg issue — even though they’re working elsewhere, I wonder if for some reason BP is calling them differently? Maybe time to do some PHP image processing tests, independently?

Is there anywhere in which the developer side is documented; i.e., so I can check out on the back end how BP handles this as I look at the code / functions?

Jeff Sayre
Participant

@jeffsayre

15 years, 5 months ago

The majority of the avatar handling code can be found in bp-core-avatars.php. The cropping code is found in bp-core-cssjs.php in function bp_core_add_cropper_js().

Peter Kirn
Participant

@peterkirn

15 years, 5 months ago

I’ve double-checked my GD / libpng / libjpeg install, and as near as I (and phpinfo) can tell, everything is fine.

It’s definitely failing on the cropping code. Images are all uploading successfully, but not their cropped versions. So when BP goes to look for the cropped versions that are the correct sizes, they’re not there — regardless of the size of the original file.

This also now truly rules out the upload issue (though that bug trac is interesting).

Any chance that detritus from our RC test is involved with the new BP stuff? Other things to check? I’m just running out of ideas.

John James Jacoby
Keymaster

@johnjamesjacoby

15 years, 5 months ago

Check all of your blogs.dir, 1, and uploads directory’s permissions, and see if any plugin you’ve installed previously has locked down any of them with .htaccess or .htpasswd files or modifications.

I’ve seen a few plugins (caching, or roles/capability/permissions) put strange rights on those directories, that allow the uploading of the initial image, do not allow the cropped images to get saved, and then disallow the website from accessing any image in those directories.

Physically go through each directory and manually assign the permissions yourself. Then also look for the existance of .htaccess or .htpasswd files in your wp-content/blogs.dir directory, and delete them if they exist.

Peter Kirn
Participant

@peterkirn

15 years, 5 months ago

Ah, never mind. I’ve done some more tests and the problem is that GD isn’t finding the libjpeg library – so it was the obvious problem. Because WP core uses jpeg for all its writing, well, that pretty much breaks everything. My fault.

I think I’ve also sorted out how to properly build libjpeg on a 64-bit FreeBSD system. It seems you need the ancient patches for libjpeg, as seen here…

http://cblfs.cross-lfs.org/index.php/Libjpeg