[hadar]

OK, my problem isn’t completely solved, but Manoj was right about what was going on for me. When I upgraded php to 5.3, somehow, I left off “–with-gd” in my build (I used to build with it). So, because the GD lib was missing, the upload was failing, having nothing to do with file permissions.

Now, I can successfully upload a file, but once the file is uploaded, I get sent to the “Crop” screen, and no matter what I do there (move the crop box around, leave it alone, etc.), when I press the Crop button, again I fail. So, I can’t get the new avatar to display (yet), but at least it uploads to the correct directory.

One step closer!

[hadar]

OK, I’m one of the people who started a thread on this a couple of weeks back.

I just followed the advice above given by Manoj. I am able to upload files via Add New Media, so indeed the file permissions are correct (which I noted in my previous posts).

But, when I upload a 700×700 image, it uploads correctly but I get no thumbnail images, so perhaps that is indeed the problem.

When I upload an Avatar (175×100 in all of tests so far), the directory “1” successfully gets created under the “avatars” directory, but no files appear there.

How do I specifically test for the GD Lib error mentioned above, and even better, how do I fix it if that’s the problem?

[hadar]

Last update, then I’ll stop.

I read Trac ticket 1184. I changed permissions, that didn’t help, the correct permissions/owner was already there. I saw another forum thread about incorrect avatars ending up in the directory.

I deleted all directories under blogs.dir (none had files in them, just directories). After attempting (unsuccessfully) to upload an avatar again, I end up with the following directory structure (all blanks, no files in any directory). So, it doesn’t appear to be a permission issue, since the directories get created just fine:

wp-content/blogs.dir/1/files/avatars/1/

Now I’ll just wait…

[hadar]

I just looked at the php error log (which was not generated on the production host) and it has the following error in it:

[01-Nov-2009 10:12:23] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in /var/www/html/wp-content/plugins/buddypress/bp-core/bp-core-avatars.php on line 264

[hadar]

I just jumped through a ton of hoops to set up a Virtual Machine running CentOS to install a fresh WPMU and BuddyPress (2.8.5.2 and 1.1.2) behind APACHE this time (instead of NginX) to test the Avatar change, and watch the RewriteLog in Apache to see if I had a logic error in NginX.

Even under Apache2, when I try to upload a new Avatar, it fails with the same 404. Looking at the Apache Rewrite log, I see that the URI gets rewritten as follows:

/{DocumentRoot}/index.php

The parameter is “members/admin/profile/change-avatar/” (but I actually see that the leading “/” was stripped, but the log doesn’t actually show what’s passed). It has to be passed, because index.php alone does bring up the site homepage correctly…

[hadar]

OK, responding to my own questions, just not to create work for anyone else who ends up here in the future.

I had a bug in my NginX conf file. For all CSS files that were in subdirectories off the root, I was sending those files through PHP rather than just returning them. That caused the Content-Type to be set to “text/html”, rather than “text/css”.

That’s why it worked without a Doctype (quirks mode kicked in), and failed in Firefox and Chrome with the Doctype in.

[hadar]

One quick update to the comment immediately above this one.

I just did a fresh install of WPMU, did not even log in as admin and did not install BuddyPress. The default WPMU shows the same behavior as the above, so this can’t possibly be a BuddyPress problem.

Not that I wouldn’t appreciate your help on this, but I’m going to continue to try and solve this at the WPMU level, and move on to BP when/if I solve it…

[hadar]

I’m having the same problem. I just installed BuddyPress 1.0rc2 today, and it’s the first WPMU install for me, and obviously the first BP install as well. I’ve been running WP for over 2 years though, on the same server (different domain), with complete success.

The install seemed to go fine, and I followed the instructions to also use the BP-home theme for the WPMU home page as well (it fails with any of the 4 choices of home page themes).

The site comes up correctly in IE7. In Firefox (3.0.10) and Chrome (2.0.174.0), no CSS gets loaded.

I’m running this on CentOS 5.2, using NginX 0.7.53. WP runs perfectly.

It’s not an “access” problem. Firebug shows that the CSS file is read correctly (and I can see all of the lines in there, so NginX is serving up the CSS). But, for whatever reason, FF and Chrome both decide that it’s not CSS, and just ignore the styles completely (Firebug says that there are no style elements on the page).

Looking at the NginX debug logs, IE takes the css file with an “Accept: */*” and FF takes it with an “Accept: text/css”. Otherwise, I don’t see any obvious differences.

If I code up my own html file, and use the exact same syntax for the css <link> line that BP generates, FF will _correctly_ parse the css file.

The only thing that seems strange in the BP generated code is that the HTML fails the W3C validator for including an “id=_wpnonce” in the hidden search form field _two times_. But, if I remove one of those lines, FF still fails to parse the css.

Here are the links (the site has zero in it at the moment):

http://songsandjingles.com/wordpress-mu/

Here is a link to my “test” html file, which loads the same css file (where I added yellow as the background color in custom.css):

http://songsandjingles.com/wordpress-mu/testme.html

Just to show that the css file is accessible:

http://songsandjingles.com/wordpress-mu/wp-content/themes/buddypress-home/style.css

Any help would be greatly appreciated, thanks in advance!

P.S. The most obvious difference between my tiny HTML file and the generated one is that I have no DOCTYPE or “profile=” in mine…