Instead of move_uploaded_file(), you'd load the file into the image processing library, resize it, and save it out.
eg. using GD, start with imagecreatefromgif(), imagecreatefromjpeg() or imagecreatefrompng() (depending on what format you've got), then create a new image of the desired thumbnail size using imagecreatetruecolor() and resize the original image into it using imagecopyresampled(). Finally save the results using imagegif()/imagejpeg()/imagepng() depending on what format you want.
Determining the target size is pretty easy if you just want a fixed width whilst retaining the aspect ratio: new_height= round_to_whole_pixels(new_width*original_height/original_width). However it is worth putting some sanity checks in: say someone uploads a 1x2000 pixel image. Aiming for a width of (say) 200 pixels, you'd then be blowing it up to 200x400000, an enormous image that might eat all your server's memory! So have a max_height as well.
Finally, your script as it stands contains too many severe security holes to list. Before you put anything like that on the public internet you need to learn about directory traversal attacks, SQL injection, HTML injection (XSS) and file upload type sniffing vulnerabilities (eg. embedding JavaScript in HTML disguised as an image file).
ETA:
Do you think this web site covers most bases?
Not quite, but it's a start. This advice:
When you place any uploaded files in your upload folder, rename the file to some random names and track the filename in the database.
is very important. You can never trust a filename submitted by the user. Filenames are more complicated than you think, and even if they're not trying to be malicious, there are many weird ways filenames can go wrong:
some browsers submit file leafnames, some whole paths, and you don't know the format of filepaths on the client machine (directory separators on various platforms include ‘/’, ‘\’, ‘:’, ‘.’ and probably others).
what's going to happen if the given filenames contain disallowed characters? Control characters? Unicode characters?
if you're on a Windows server, try to create files with innocuous-looking but reserved names like ‘com’ and you'll come a cropper. Also Windows silently throws away trailing spaces and dots in a way that can easily confuse your scripts.
The latter is a potential security hole in the script you linked. It checks for ‘bad’ file extensions like ‘.php’ at the end of the filename. But if you uploaded a file called ‘x.php ’ (with a space) to a Windows server it would happily accept it and save it as ‘x.php’. (There is also a bug in the script, as it uses ‘.’ in a regular expression, which stands for any character. So the filename ‘poo.potatophp’ would be taken as having a .php extension.)
As usual, whitelisting is better than blacklisting. Allowing only eg. ‘.jpeg’ extensions is more likely to work than disallowing known-bad ones. However, this is still insufficient, because there is no guarantee a submitted JPEG file will actually have the extension ‘.jpeg’. On Windows it might have an extension ‘.jpg’ or ‘.pjpeg’ or something else completely that happens to be mapped to JPEG on the client machine. On Mac or Linux it might have no filename extension at all!
So to sum up: it is best to ignore any filename/path submitted with file upload fields. Maybe you can have a look at it to guess what format the file might be in if you don't already know, but you can't rely on that and you should never ever take the user's word for it and actually save it under that name.
The page also does not cover the ‘HTML disguised as an image file’ case I mentioned. If you allow anyone to upload files that you don't completely trust with full access to everything on your site, you need to worry about this. You can read about it here. See more discussion of PHP file upload script risks here.
ETA2:
I have seen a lot of suggestions of uploading above the web directory. Yet my script will still display these files to the visitors of the web site.
Yeah, that's a good place to start. By taking control of the serving process into your own hands you avoid any problems with the webserver handling filetypes in unexpected ways, you can use your own known-safe filenames, and by having your script add a “Content-Disposition: attachment” header, you can mostly prevent browsers from treating active content like JavaScript as originating from your site's security context, causing cross-site scripting problems.
The drawback of this method is that serving a file through PHP is much, much slower than letting the web server do it. You can improve matters by implementing a load of HTTP cacheing header stuff in your file serving script, but it's a lot of work and it still won't be anywhere near as fast as a typical webserver written in C and maybe using kernel-level network efficiency hacks. For a file you serve up occasionally, that's no problem. For a popular image being viewed all the time on a busy site, it's no good at all.
Also, there used to be some issues where Flash would ignore the Content-Disposition header, which could still cause sneaky files to XSS via that plugin. These are fixed now, but who knows what other plugins and odd browser behaviours might be out there. So for safety, it may be best to serve your untrusted user-uploaded files from a different hostname, eg. a subdomain like data.example.com. This stops cookies and authentication details leaking across the two security contexts. If you go for a webserver-based way of spitting out files, you definitely need to take this precaution.
I just want to get this done, its way too complicated
Yeah, it looks like a deceptively simple task, but it's really not. Some very high-profile web sites have suffered with security problems due to untrusted uploads; if Microsoft and Google's web guys can't always get it right, it probably is quite complicated...
It doesn't help that (as usual for PHP) 99% of the tutorials out there covering this sort of thing are utter crap.