Fork me on GitHub
Current releases are 2.1.1 (2 Aug 2014) and 2.0.18.13 (5 Aug 2014)
Ready for 2.1? Find out if your favorite plugins are compatible.
The 2.0 branch will no longer receive updates after Dec 2014.

FileUpload 1.4.0 Released

TimTim Lord of Servers Vanilla Staff
edited November 2010 in Vanilla 2.0 Help
This discussion is related to the FileUpload addon.
This is a feature release
- Thumbnails (thanks @Mark!)
- Ability to insert uploaded pictures into the post (thanks @Mark!)

Vanilla Forums Senior Developer [GitHub, Twitter, About.me]

«1

Comments

  • 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.
  • TiGRTiGR
    edited November 2010
    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.
  • 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.
  • edited November 2010
    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
  • @Tim Great !!!!!!!
    Thanks for this feature !

    How can i change the size of the thumbnails ?
  • 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
  • TimTim Lord of Servers Vanilla Staff
    Vanilla Wallpaper!

    Vanilla Forums Senior Developer [GitHub, Twitter, About.me]

  • Try uploading and inserting image into post.
  • TimTim Lord of Servers Vanilla Staff
  • 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?
  • TiGRTiGR
    edited November 2010
    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.
  • 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.
  • 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
  • @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?
  • TimTim Lord of Servers Vanilla Staff

    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.

    Vanilla Forums Senior Developer [GitHub, Twitter, About.me]

  • 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
  • judgejjudgej
    edited November 2010
    @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.
  • 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.
  • judgejjudgej
    edited November 2010
    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.
  • This release fixes a number of issues with Internet Explorer, which I could not get to work at all in previous versions (the "Attach a file" link being unresponsive to mouse clicks, for a start).

    Thank you :-)
  • judgejjudgej
    edited November 2010
    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.
  • TimTim Lord of Servers Vanilla Staff
    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.

    Vanilla Forums Senior Developer [GitHub, Twitter, About.me]

  • TimTim Lord of Servers Vanilla Staff
    All files will be served indirectly.

    Vanilla Forums Senior Developer [GitHub, Twitter, About.me]

  • I was trying to figure out how to block access to uploads/FileUpload/
    .htaccess
    DenyFromAll
  • TimTim Lord of Servers Vanilla Staff
    Obviously. But what I meant is, a way that works for everyone who meets our current minimum requirements, one of which is *not* htaccess.

    Vanilla Forums Senior Developer [GitHub, Twitter, About.me]

  • 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.
  • raykrayk New
    edited November 2010
    Nice update, insert image is very welcome!

    There is no insert image button when you go to edit a post...?

    The other nitpick is when you insert an image into the post the attached images thumbnails still appear - makes post look a little messy for an image heavy/art site.

    Cheers.
  • Awesome update, great ideas. Looking forward to improvements as well, like the ones @rayk mentioned
«1
Sign In or Register to comment.