FileUpload 1.4.0 Released

Tim

This is a feature release
- Thumbnails (thanks @Mark!)
- Ability to insert uploaded pictures into the post (thanks @Mark!)

TiGR

Yeah!

Great job, Tim!

TiGR

Hmm... When I uploaded file, it showed up thumbnail.

When I clicked insert image, it inserted, but after posting it does not show up any longer. If you open that link, vanilla shows standard not found error.

TiGR

Aha!

Direct link name is /uploads/FileUpload/X/filename.jpg
But inserted image link is /uploads/FileUpload/X/X.jpg - this one gives an error.

greenlizard

I have a feature suggestion:

Ability to limit uploads per category. So, if you only want to allow file uploads in one category, you can.

Raize

Thank you, much appreciated

ChrisP

Hi @Tim,

I upgraded my Vanilla from rc3 to the latest version as you suggested. I followed the instructions at http://vanillaforums.org/page/UpgradeInstructions, except that I didn't back up my files because our forum and database is brand new anyway.

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.

Thanks,
Chris

Doudou

@Tim Great !!!!!!!
Thanks for this feature !

How can i change the size of the thumbnails ?

Caramboo

It seems that the thumbnails are defined in CSS, there's no image file resizing going on at all. Check out the 32px entries at the bottom of css/fileupload.css

Tim

Vanilla Wallpaper!

TiGR

Try uploading and inserting image into post.

Tim

pettifoggist

Is there any way to make it so that the link doesn't force the file to download and instead would open like a normal link?

TiGR

Okay, I've finally figured it out.

I have caching optimizations, such as .htaccess file in uploads with the following content:

ExpiresActive on
ExpiresDefault "access plus 1 year"
Header set Cache-Control "max-age=15552000, public"

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.

So, there are at least 2 bugs:

1. Vanilla Not Found returning status 200.
2. Inserting image with non-existent url.

TiGR

Also, few considerations:

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.

igot2b

awesome work. this is looking really good!

i just noticed, that when you have the "CLEditor jQuery WYSIWYG - plugin" active, it won't add anything to the comment-box. do you think you could somehow make this also work with this plugin?

best regards

TiGR

@Tim, just a question: I have a custom theme, and just have noticed that your plugin tries to fetch it's images not from it's own directory, but from my theme directory. Is that ok?

Tim

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.

This might be a good point. I can change the way files are named.

Method

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.

Thanks a lot for all the effort and time you put into all of this!

Cheers

judgej

@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.

Familiar

I have a thumbnail class written for a different framework that uses this: http://phpthumb.gxdlabs.com/

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.