The Google Chart API is quite powerful and easy to use, with many customisations available. For my projects i’ve been using the ‘simple encoding‘ method for passing chart data to the Google Chart API. After doing a search on the Internet for a PHP script that converts the data into the encoded string and failing miserably I decided to write my own. This simple PHP function to convert a numerical array of data into the encoded string. Read more…

Happy new year everybody! I’d thought I’d start off the new year with a little present for you all.. the new version of my PHP Form Processor. Thanks to Andrew Dunn for some excellent ideas on how to improve the processor, as well as for tweaking bits of code here and there, I’m able to bring you version 2 of the form processor.

The last few months has seen some additional functionality added, as well as fixing a few bugs here and there. Version 2 of the processor is fully backwards compatible with version 1, so don’t panic!

Here’s a brief summary of the changes:

• Callbacks added to radio buttons
• All functions now declared as public or private respectively
• A configuration system, which lets you change the behaviour of the form processor
• The ability to echo the form output or save it to a variable (useful for templating systems)
• A text transform rule has been added, which allows you to set text to be lowercase, uppercase or uppercase the first letter of each word
• A minimum length rule has been added, which allows you to set the minimum number of characters a user must enter
• A maximum length rule has been added, which allows you to set the maximum number of characters a user must enter
• Cleaned up the code
• Swapped exit() statements with exceptions, so these can be caught and handled if necessary

I’ve also created a few example forms to show the functionality of the form processor. Please take a look at the PHP Form Processor article for full details.

Gavin Holt is also doing a series of articles demonstrating practical usage of the form processor. Check it out for some excellent ideas and usage examples.

DOWNLOAD THE PHP FORM PROCESSOR

Ever since I started building websites I’ve found making forms to be time consuming, tedious and generally boring, and I’m pretty sure most web developers are in a similar situation.

First of all you have your HTML form, which then submits all the data to PHP to be validated etc. You have to write the validation rules for each form field in PHP, and then come up with a system of reporting errors back to the user. With large forms this can get extremely complicated!

Around two years ago I came across a form validator by Simon Willison. This basically let you write the entire form and it’s validation rules in the html. These rules are then read by PHP, applied to the relevant form fields and so on. It’s a very elegant solution that makes building forms much easier and faster, as well as easier to debug and maintain. I’ve been using this script for the last 2 years and have made various changes to the script along the way to suit my purposes.

However, the script does have it’s down-points. It uses the PHP 4 XML library which to be honest is rubbish! It causes the code to become extremely bloated and unable to handle certain characters such as ampersands (&). This means that as soon as a user enters an ampersand or a character like a dollar, the script would crash!

The script also only supported textfields, and didn’t provide support for radio buttons, checkboxes and select drop-down lists.

With all these positives and negatives in mind I’ve built my own PHP Form Processor from scratch, which I think does the job quite nicely. The script is open source and I’ve provided a tutorial and several example forms on how to use it.

The script also protects your forms against CSRF (Cross-site request forgery) and form manipulation. Anyway, without futher ado, here is the tutorial.. Read more…

Using Sessions in PHP can be extremely useful, and is almost a requirement when making dynamic web applications. However, sessions do have drawbacks, and one of these is security. When a session is created, it gets written to a file on the server. If the server you are using has other hosting accounts, they will also be using the same directory as your session files. If you’re storing any personal information about your website visitors, you have quite a serious problem.

For this reason, I would strongly suggest storing your sessions in a database. This tightens security considerably, and also allows for a wealth of new possibilities, such as running SQL queries on the database to see how many users are logged in. It is also the only logical solution if you are using multiple servers that need to access the same user sessions.

Read more…