What is the most efficient way to group a bunch of file uploads together on the following screen? I currently have http://blueimp.github.io/jQuery-File-Upload/ implemented on one of my websites, and I use a hidden field with some random generated id that gets passed into the next page. This has proven to be unreliable, and I was wondering if someone had a better way of making sure all of the XHR files responses are grouped together on the next page?
Thanks.
Not 100% sure what you mean by grouping the files, but if you want to make sure the files are legit, perhaps using a SESSION key will help.
I am building a website where I am uploading images to my ftp folder through PHP script. Now I want to display those images on to my HTML pages. I was thinking about using PHP and getting array of all the images from my ftp folder and then display them using image view.
Please tell me if I am doing this the wrong way and if there is any other better alternatives to it. I was reading php manual for ftp_nlist and ftp_rawlist but did not understand.
Well it may depend on how many images you have in there. Probably the most "correct" way to do it would be to store the filenames in a DB. You could scan the entire folder, but for every single request that's potentially a lot of overhead rather than just grabbing them out of a DB.
Are you manually uploading the images? Give us more details on how that works and we can better serve you. If you're using a script to upload images (I've had lots of projects where that's the case), then you can just have the script insert those filepaths into the DB for you. If not, (you're manually uploading them), or if indeed there are not a large number of files, then scanning the folder wouldn't necessarily be a bad thing. I've used that method on smaller projects myself.
Read up on the php readdir function in the docs (which actually works a lot like mysql_fetch_assoc, ironically)- That will provide you with an excellent way to go without setting up a DB. For an approach where an upload script handles it, I recommend a DB. Without more info, it's hard to say.
Good luck!
I am planning to do a photo album website, So each user may upload as many number of images. What is the best way to keep track of images for an individual user. What should be the server configuration to handle this part.
-Lokesh
Depending on the amount of images, you will probably want to store them on a static domain. Then, have a table in whatever database you are using to store the paths to each of the images for each user.
Well like many design topics there are lots of different ways to go about it. Two ways that come to mind right now are as follows.
you could simply have a directory created on the server for each user and then have the images each use uploads saved into that directory. Ofcourse you'd want to make sure they didn't over write any existing images with images of the same name. You could do this by warning them about conflicting names or by adding some sort of noce string (like a time stamp) to the end of of the file name. This is a pretty straight forward solution and means that you can login to your server and see all the images each user has uploaded right there for you to do anything you like with.
Another idea would be to save the images in a database. This can be done by serializing the images to a string and storing it in a database. This is nice becaues it means you don't have to worry about handling directories and duplicate file names. You will have to deserialize each image when you want to display it which will put your DB under load so for a very high traffic volume site this might not really be the way to go.
There are ofcourse combinations of these ideas and many others. It really comes down to working out which solution best fits your exact needs.
I am (still) attempting to upload large files <200mb via a html form using php.
During my research into this I have come across the term "chunking", I understand that this process can break the file into handy sizes such as 5mb and reassemble them into the full file at the server side.
My problem seems to be where I can begin? I seem unable to find the correct resources by googling (Or perhaps I'm suffering from not knowing which terms to search for).
So what I'm hoping for today is a chance to educate myself with the basics, a direction in which to look would be very helpful. I don't really want to download a plug-in or anything like that, I would prefer to learn by experimentation.
EDIT to add: Although the two answers below would appear to be correct, this takes me into the realm of stuff that I can't do as a designer...If anyone reading this can suggest a different approach I would appreciate it.
Web browsers do not split uploads into chunks. For this you'll have to use your own "chunking" client: a Flash program or a Java applet.
You can take a look at JUpload. There are also examples in the wiki.
From SourceForge :
Multiple File Upload Applet (JUpload) takes care of the limitation posed by traditional HTML upload forms by allowing you to upload a whole directory and the files within it with a single click. Optionally, it allows simple picture management.
Here's a bit of history first: Recently finished an application that allows me to upload images and store them in a directory, it also stores the information of that file in a database. Database stores the location, name and gives it an ID (auto_increment).
Okay, so what I'm doing now is allowing people to insert images into posts. Throwing a few ideas around on the best way to do this, as the application I designed allows people to move files around, and I don't want images in posts to break if an image is moved to a different directory (hence the storing of IDs).
What I'm thinking of doing is when linking to images, instead of linking to the file directly, I link it like so:
<img src="/path/to/functions.php?method=media&id=<IMG_ID_HERE>" alt="" />
So it takes the ID, searches the database, then from there determines the mime type and what not, then spits out the image.
So really, my question is: Is this the most efficient way?
Note that on a single page there could be from 3 to 30 images, all making a call to this function.
Doing that should be fine as long as you are aware of your memory limitations configured by both PHP and the web server. (Though you'll run into those problems merely by receiving the file first)
Otherwise, if you're strict about this being just for images, it could prove more efficient to go with Mike B's approach. Design a static area and just drop the images off in there, and record those locations in the records for their associated post. It's less work, and less to worry about... and I'm willing to bet your web server is better at serving files than most developer's custom application code will be.
Normally, I would recommend keeping the src of an image static (instead of a php script). But if you're allowing users to move them around the filesystem you need a way to track them
Some form of caching would help reduce the number of database calls required to fetch the filesystem location of each image. Should be pretty easy to put an indefinite TTL on the cache and invalidate upon the image being moved.
I don't think you should worry about that, what you have planned sounds fine.
But if you want to go out of your way to minimise requests or whatever, you could instead do the following: when someone embeds an image in a post, replace the anchor tag with some special character sequence, like [MYIMAGE=1234] or something. Then when a page with one or more posts is viewed, search through all the posts to find all the [MYIMAGE=] sequences, query the database to get all of the images' locations, and then output the posts with the [MYIMAGE=] sequences replaced with the appropriate anchor tags. You might or might not want to make sure users cannot directly add [MYIMAGE=] tags to their submitted content.
The way you have suggested will work, and it's arguably the nicest solution, but I should warn you that I've tried something similar before and it completely fell apart under load. The database seemed to be keeping up, but the script would start to time out and the image wouldn't arrive. That was probably down to some particular server configuration, but it's worth bearing in mind.
Depending on how much access you have to the server it's running on, you could just create a symlink whenever the user moves a file. It's a little messy but it'll be fast and reliable, and will also handle collisions if a user moves a file to where another one used to be.
Use the format proposed by Hammerite, and use [MYIMAGE=1234] tags (or something similar).
You can then fetch the id-path mappings before display, and replace the [MYIMAGE] tags with proper tags which link to images directly. This will yield much better performance than outputting images using php.
You could even bypass the database completely, and simply use image paths like (for example) /images/hash(IMAGEID).jpg.
(If there are different file formats, use [MYIMAGE=1234.png], so you can append png/jpg/whatever without a database call)
If the need arises to change the image locations, output method, or anything else, you only need to change the method where [MYIMAGE] tags are converted to full file paths.