File upload issues after 3.8.4 P1 upgrade from 3.6
 

I just recently upgraded from 3.6 to 3.8.4 P1, and after doing so, I'm having an issue with file uploads - specifically, any uploaded files that are run through a thumbnailing system - avatars, Photopost vbGallery thumbnails, vBadvanced Dynamics thumbnails, etc. Some are vb, some are add-ons. But they all have the same problem, and all of them seemed to work fine before the upgrade, and no server changes were made.

It seems that any file being uploaded and thumbnailed is created with insufficient file permissions. If I go in and set the entire directory permissions to 777 recursively, it fixes the existing thumbnails in all sections. But any new ones that are uploaded keep having the same problem.

Can anyone give me some place to look? I've asked in the vb support forums but haven't received a reply, and I'm sure the reply I will receive from them is that it's an "add-on" issue. How could an add-on be causing how a file is created?

Have you tried turning off all your add-ons and seeing if you still have this issue?

What happens when you upload a file via Admin CP > Maintenance > Diagnostics > Upload

I'm trying to avoid turning off all add-ons, in order to prevent further service interruptions.

Here are the results of the diagnostics:

file_uploads: On
open_basedir: None
safe_mode: Off
upload_tmp_dir: /tmp
upload_max_filesize: 2.00 MB

No errors occurred while opening the uploaded file for reading.

--------------- Added [DATE]1256590932[/DATE] at [TIME]1256590932[/TIME] ---------------

Just disabled all add-ons by editing the config file and adding this:
define('DISABLE_HOOKS', true);

Saved the file, cleared browser cache/cookies, logged back in, tried uploading a new custom avatar, and the custom avatar shows up as a broken image file. Doesn't look like it's a problem with add-ons.

I assume you have the avatars stored in the file system? Have you double-checked those directory paths?

I don't think vbulletin does a thing to change directory permissions which is why it seems strange that this would be a default vbulletin issue.

I recently moved avatars to the file system (after we upgraded to 3.8) because a few members were having this problem, plus I've been wanting to move them for a while. After moving them, all avatars were broken, which told me that the directory had the wrong permissions. I set the directory permissions at that point, so yes, the directory paths are correct, otherwise I can't see how they'd be showing up at all at this point.

Unfortunately, I didn't try duplicating the error with my own account before I moved avatars to the file system. I did, however, try uploading an avatar for a user who was having trouble in admincp and found that I could see the avatar in admincp (before avatars were moved to the file system) but saw a broken image in his posts/profile. At that point I tried reverting templates, which didn't fix the problem. I then moved the avatars over to the file system.

The problem lies in the file permissions of new avatars that are uploaded - they're being created with the wrong permissions. There is no problem with existing avatars after I fixed the permissions. The developer at vbadanced couldn't figure this out either. Again, this only started being a problem after we upgraded to 3.8 from 3.6. Something must have changed in vb.

Check the source code. It would be interesting to see the image source in there. Then, see if it is the correct path for your site - can you view the avatar directly in your browser? What are the permissions on the avatar folder? Are you using the default avatar folder they supply with the software?

The source code for a broken avatar looks like this:
http://www.mysite.com/forums/customa...tar53481_5.gif

If you view the image directly, you get a 403 error, since the permissions are wrong. The avatar directory permissions are set to 0777. And yes, I'm using the default directory supplied by the script.

So you are actually having the full path to the avatar added into the source code? On my site, it looks like this (note the relative path, not the full path):

That's being spit out by this template code:

I know what template it is being spit out in. What I find weird is that the full path is being spit out instead of the relative path. That isn't how it is supposed to be in default vbulletin. I don't know that that is the issue, but it is rather strange.