Everything seemed to work just fine- until I tried to navigate to the main page. I'm getting the same FastCGI error I was getting before (which is when I tried the rc3 thinking it was the latest release). My webhost says they're fully capable of handling FastCGi and I have no idea how to troubleshoot this because of the non-descript error. Strange thing is, the dashboard is still fine- I never closed the window from the upgrade. I just can't get to the main page, or to /discussions, etc. I even installed and enabled FileUpload 1.4 without trouble. Still no luck with the main page.

Update: I can view the activity page and individual posts even... When I clear my cookies, I can access the main page, but when I enter my username and password, I get the same error. Looks like it's just the discussions page I can't access.

Any ideas? I have searched the community pages for a FastCGi error without luck. I'll be happy to ask this question elsewhere if it's more appropriate- I'm just not sure where to turn next.

The problem is that when I've uploaded a file and clicked "insert image", direct image url somehow returned 404 vanilla error (File wasn't there yet?).

So, anytime I've been trying to refresh that image, browser received only 304 status, and took that "image" from the cache. After I've cleared the cache it started working again.

Okay, here is how it works:

1. Pre-requesties: using Chrome which is mad about caching, good server-side caching, visual editor plugin and prettyurl option enabled.2. You upload file. At this step, file is in /uploads/FileUpload/scratch/something...3. You click instert image button. SInce we're using visual editor, the image is shown immediately. The problem is, that the image url looks like /uploads/FIleUpload/X/X.jpg. That file isn't there, and since we have pretty URLs enabled and RewriteCond %{REQUEST_FILENAME} !-f in htaccess file, we get Vanilla not found which is wrongly returning status 200.

1. Directory structure is not optimal. If we have 5000 uploaded files, we'd get 5000 directories in /uploads/FIleUpload/. Some hosts don't like when user has too much files or directories in one directory. You might use something like this: sprintf('%02x/%02x/%02x', $id/10000, $id/100%100, $id%0x100). That would easily hold 16 millions of images with maximum 256 directories in each directory.2. Urls are predictable. This is wrong when you want to restrict access to uploads for some roles. Say, you have subforum visible for moderators only. Now, if you upload something there you'd like not to let others see it. That's why other boards add something to path. say, time(), so that path looks like /uploads/1-1289639698.jpg. Random string would be even better.

1. Directory structure is not optimal. If we have 5000 uploaded files, we'd get 5000 directories in /uploads/FIleUpload/. Some hosts don't like when user has too much files or directories in one directory. You might use something like this: sprintf('%02x/%02x/%02x', $id/10000, $id/100%100, $id%0x100). That would easily hold 16 millions of images with maximum 256 directories in each directory.

You shouldn't get 5000 folders.

I used a modulus function to spread the file load over 20 directories (upgradeable with a config parameter). Each directory can hold (by operating system limit) ~ 65,000 files. This means 1.3M files by default, again, upgradeable.

2. Urls are predictable. This is wrong when you want to restrict access to uploads for some roles. Say, you have subforum visible for moderators only. Now, if you upload something there you'd like not to let others see it. That's why other boards add something to path. say, time(), so that path looks like /uploads/1-1289639698.jpg. Random string would be even better.

I really like the new update, however we tend to post large image files (usually in the range of 40-80MB each), with many posts having multiples of these. The new thumbnail feature really peaked my interest until I found they are not true thumbnails and simply a style applied to an image tag. I had to manually modify the link_files.php view to enable my forum to be .. viewable as nearly every browser crumbles under the weight of any image over a few tens of MB, not to mention the MASSIVE bandwidth overhead just to visit a post. Anyhow, I personally don't have the time ATM to code up my own thumbnail generator, but it would be awesome to have GD create a small thumbnail (preferably customizable dimensions) for this display.

@Method Totally agree there. The full size uploaded file should never be downloaded without the user's consent. If there is an image to download, then as a user I would like to be told there is an uploaded image available of some size decided by the uploader. A thumbnail showing me what it would look like would be nice, but the original file - no way. If resizing the image only by CSS is the way it works, then the thumbnail feature should be disabled for now, until it can be a proper resized image; it is a show-stopper IMO.

Resizing images on the server can also run into format and memory issues, so resizing should be done in a thread of its own (i.e. not the uploading thread, because crashing that with an "out of memory" error can leave stuff half-uploaded). Being able to detect resizing issues and putting in a default general thumbnail is always a good move - but not so easy in a platform-independent way.

It includes a caching routine, and also stores files based on an MD5 hash and the time uploaded. It's been used extensively on production servers and so far it's been bullet proof. I can see about adapting it if it would be worth the trouble and another solution isn't in the works.

phpthumb, I think, is the "defacto standard" for any PHP application. It is reliable, easy to used, and flexible.

I have used it in a small script that gets invoked automatically if a thumbnail does not exist, in order to create one (and cache it) on-the-fly.

A directory can be set up through htaccess so that if you try to access MyFile-icon-small.gif and it does not exist, then phpthumb can be invoked to look for MyFile.gif and then create a thumbnail from it and write it to MyFile-icon-small.gif. That will only get called up once, since the second time the "icon-small" file is accessed, it already exists. What size "icon-small" represents is up to your application.

Another problem with using the original images for the thumbnails, is that it means direct HTTP access must be given to those images.

At the moment, downloading an image - or any file for that matter - goes through the FileUpload module and so it is possible to check whether a user has permissions to download the file. If the user has view privileges on a category in which the file is attached to a post, then the user is permitted to download the file; if not, the the user is not permitted to download the file (I would consider files attached to a post to be a part of that post, so should only be accessible through that post, taking into account the access rights a user has to that post). At least, I hope it works this way.

The site owner should be able to block all direct access to uploads/FileUpload/ to prevent people scanning those folders (using numeric filenames) to see what has been uploaded there. If that is done, the thumbnails from the source images cannot be accessed.

-- Jason

Edit: but with a little trickery, perhaps attempting to access images directly in uploads/FileUpload/ could actually just return the thumbnail by default? A bit of mod_rewrite and phpthumb would do it. It does not hide them completely from unprivileged prying eyes, but it's better than allowing free access to the World to download the original uploaded documents and files.

I'm working on this plugin today and have already implemented most of what you say. I was trying to figure out how to block access to uploads/FileUpload/ but I guess I *can* just leave that up to the site administrator.

Cool. I agree, leave it up to the administrator to block the folder, but it may be worth throwing in a htaccess just for completeness, along with a note in the readme for people using other platforms and to tell people where to copy the htaccess to.