The NETTUTS.com site has a new tutorial/screencast posted looking at their method for opening up uploaded zip files with PHP:

ThemeForest has a nice feature; It allows the authors to upload zip files containing screenshots of their themes. A script then extracts these files and displays the images accordingly. Though I doubt that the developers used PHP to accomplish this task...that's what we're going to use!

They create a simple form with one field - a file input - and write some basic PHP around it. The script ensures that it was a zip file that was uploaded (based on the mime type) and passes it through a ZipArchive class to do the hard work. This class and the rest of the source can be downloaded from the site.

Laknath Semage submitted a new blog post he's written up about working with large file uploads in your PHP applications.

If we want to do large file uploads or database updates with PHP there are few configurations to be done to default settings and I'm putting this as a note to myself (I'm always keep forgetting this) as well as to any one who may find this useful like when importing a large backup file through phpMyAdmin.

There's four php.ini settings he recommends checking as well as two values to change if you do have the need to upload a large import file back into a phpMyAdmin installation (ExecTimeLimit, MemoryLimit).

With the recent released of the 1.7 version of the Zend Framework Rob Allen wanted to post about a new form element type that integrates some much needed functionality - Zen_Form_Element_File.

Now that Zend Framework 1.7 has been released, I thought I'd take a look at the built in file upload element, Zend_Form_Element_File, and see how it can be used. This is how to use it in its most basic form.

The form in this example is similar to his previous example and the simple code is included for the form, the controller and the view.

That's all there is to it for simple uploading of forms. There are still a few fairly important bugs in the component that we'll have to wait for 1.7.2 for. Specifically the Count validator doesn't always work as you'd expect and don't use getValues() and receive() as it isn't yet clever enough to know not to call move_uploaded_file() more than once.

The Web Development Blog has a recent tutorial posted talking about a free option for the TinyMCE tool to work with uploading images.

TinyMCE is a great online WYSIWYG editor which is used for a lot of projects, for example this Wordpress blog application (the content backend). [...] Sometimes the Image manager too looks too big for some projects and than is the following (free) solution an option. You can download your copy from the TinyMCE website.

He shows how to include the plugin (so the resulting TinyMCE instance can include it) and the PHP code to do the handling for the upload, based on this upload class. The end result is a simple, integrated feature that lets you upload a few different kinds of images.

The ProDevTips blog has posted the fifth part of their look at using Doctrine with PHP. This time they focus on file uploads.

It's time to take a look at how file uploads can be integrated into the Doctrine validation and CRUD process. We will have a product in the form of a digital download as an example, it will have a screenshot image that can be maximum 250 pixels wide and high. The download itself will be a zipped file.

They set up their table definitions first and set up a few validation functions (update, insert and for the file data) to work on top of that. Custom upload/uploadImage and save methods handle the user's submission while a simple delete method makes removing images easy.

Recently on his blog Cormac has posted a quick little tutorial on making things a bit faster when rejecting file uploads in PHP that are just a bit too large.

Discovered today you can report to a user if the file(s) he/she is uploading is too large without having to wait for the file to finish uploading by checking $_FILES.

The key is the "error" field in the $_FILES array that actually returns its value before the upload is finished if the size of the file is larger than the MAX_FILE_SIZE set in the POSTed information of the form. The Content-length header is sent before the actual payload (the file upload data) so PHP can interpret that before the upload starts and kick it back with an error if it's too large.

The Total PHP site has another introductory tutorial posted showing you how to correctly delete files in your PHP scripts.

Following our tutorials on uploading files and listing files, this tutorial will walk you through deleting files from a directory. This is done using the unlink() function.

Their example is pretty simple (as is the concept) - they show how to check to be sure that the file you want to remove isn't in use/open and then issue the unlink to remove it from the file system.

On the Zend Developer Zone today there's a new tutorial (by Jack Herrington) talking about working with Adobe AIR and Javascript to make a desktop application for uploading images (or any other files) to a remote server.

To solve the upload problem, most of the big services have dedicated upload applications that run on all the different platforms. But it takes a lot of work to develop them, especially when they have to run on both Macintosh and Windows. Or is it so tough? As it turns out, Adobe AIR technology makes it possible to write applications for any platform using just HTML and JavaScript. It also offers access to cool desktop features, notably drag and drop.

The tutorial shows how to make the application with the HTML/Javascript version of an AIR app (as opposed to Flex) that lets you drag and drop files into it to be uploaded. They make the basic file upload form first as a foundation then extend it to make it accept the remote request (via POST) from the AIR application to handle the uploads. Javascript code and screenshots are included.

Thanks to it being posted on reddit, the traffic to a certain post on Michael Kimsal's blog gave him a crash (literally?) course in high load management on a WordPress blog.

The blog post was voted up on reddit, and the server got slammed. So slammed, in fact, that it was unusable for a few hours while I investigated the problem. I didn't know the post was on reddit, but I knew I was getting some traffic.

He spent some time trying to get the Apache server to finally die off and give him back his machine, at least enough to get a feel for what was going on. Part of his problem was not having APC installed like he thought and the other part - WordPress. While friendly on the outside, it's apparently somewhat lacking on the inside.

On his blog today Michael Kimsal asks a question that hasn't come up much in recent months - with all of the advancements browsers are adding in, why aren't there better hooks for measuring file downloads?

This current tirade stems from implementing a file upload progress meter in PHP5. Yes, PHP5.2 has some hook, and there's a PECL extension. [...] I realize this is partially a PHP issue I'm ranting about, but it's ultimately a hacky workaround to a basic piece of functionality that browsers should support.

He mentions an example where he basically directly asked a member of the IE team about it. It wasn't greeted seriously and still hasn't managed to be included in most of the popular browsers of today.