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.

Assuming you have read the previous post, lets discuss on how to build our first PHP extension: every PHP extension is built out of minimum of 2 files, a configuration file (config.m4) which tells us what files to build and what external libraries are needed and source File(s) which will contain the actual functionality.

He builds up an example skeleton for an extension (the config.m4) and explains how the file will be phpized and configured. Next up is the php_sample.h header file where the needed modules are loaded and the sample.c file to define them. Last, but not least, comes the extension code itself that calls the printf function to output the "hello world" message.

t's one of the basics of PHP and if you read any kind of tutorial or book on the subject it's one of the first things they cover, yet I still see people no using a global 'configuration' or 'include' file. It's one of the easiest things to do and will make your life so much easier! This 'configuration' file will include anything that needs to be run on every page of the website.

They suggest that using this configuration file everywhere (including it over the entire site) can make things easier in the long run. The idea is not without problems, though. It only works until you need something custom for a certain area or page - then you have to hack it to evaluate conditions. For most simple uses, though, its a good way to share information (like database connection details) through out the application.

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

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.

Normally SimpleXML is enough to handle most XML parsing needs, but the plist XML format is just broken enough to make parsing it with SimpleXML virtually impossible. Since I hadn't played with XMLReader much, I thought it would be a good chance to give it a spin. For the anxious types, the code is available on github in my php_class_lib project, so dig right in.

His parser takes in the name of the file to fetch and a parser() method is called to do the actual work. The contents of the file are returned as an array (he includes a print_r() of that output too).

"How do I make a file downloadable through my script?" This seems to be a relatively common question on #zftalk nowadays, so here's a quick wrapup!

He compares the two ways - the usual PHP-only way of using header() calls and echoing out the file versus the more Zend Framework way - using a Response object to pull in the content, set the headers and a helper to display/render the data output.

Following up on my previous post about the differences between the mbstring and iconv international characters libraries (which resulted in a tentative conclusion that nobody knew anything about those differences), and particularly the comments by Nicola, we have combined forces (mostly efforts from Nicola, actually) to provide you with a little benchmarking, if that can help you decide.

His code for the test script is included (for you to gather your own results) and a full listing of his results comparing the effects of possible caching, running up to ten executions. You can download the text file that he ran the script on here.

Security in a PHP application includes remote and local security concerns. Discover the habits PHP developers should get into to implement Web applications that have both characteristics.

The habits in their list are:

• Validate input
• Guard your file system
• Guard your database
• Guard your session
• Guard against XSS vulnerabilities
• Guard against invalid posts
• Protect against CSRF

Each comes with their own explanation and for some, code to help you spot the mistakes and correct them.

PHP is the world's most popular server-side Web scripting language. This reference card was created to help you quickly navigate some of PHP's most commonplace features, including objectoriented programming, array and string manipulation, regular expressions, and MySQL integration.

The card (created by Jason Gilmore) is available for free download (PDF) from the DZone website.