We have recently built a Flash Game – Traitors – for the Top Gear website:

The game, sponsored by Nissan, requires the user to speed through 3 levels controlling their speed by repeatedly pressing X-Y buttons as fast as they can and using their booster. For the purpose of data submission and receiving data while interacting with the webserver we decided to use AMFPHP which is open-source implementation of the Action Message Format (AMF) and allows binary serialisation of Action Script (AS2 and AS3) native types and objects to be sent directly to server side services. Phew…

The crux of this is the ease of implementing data transfers to and from the webserver (less code on both client application and on the webserver) and the efficiency of the resultant transfer (the data being transferred is binary format which is also compressed further in AMF3 so the amount of data being transferred is smaller). This is brilliant for rapid development (which we do a lot of) and performance of the finished article.

For instance, on the webserver you don’t have to loop through a database recordset, compose some XML and return that XML to Flash which would then load and parse the XML: you can essentially return the recordset directly from php to Flash and the query is automatically converted to the corresponding ActionScript type. There are several processes being skipped and the data being transferred is far smaller (being compressed binary as opposed to XML).

There are many PHP users out there who probably don’t come from a computer science background; after all, it is probably the most accessible server-side technology out there so why shouldn’t more people have access to building dynamic, data-driven web sites/applications? However combine this with the very nature of the PHP rapid application development model and various PHP frameworks/content management systems and there are possible (and well documented) security issues. My guess is that some people are just not aware of these issues due to inexperience, others overlook them in their rush to get the job done quickly and some might even think because they are using a pre-built framework/CMS that the issues have already been taken care of. Classic asp had similar issues which were dealt with in the rollout of asp.net (particularly v2.0 onwards).

I’m not going to list all the issues (well known ones include cross-site scripting vulnerabilities, SQL injection and session hijacking) but suffice to say there is much online discussion (some productive and some not so) and additionally a rather decent book: ‘Essential PHP Security’ by Chris Shiflett available from Amazon and other good bookstores.

• Recruitment: the majority of web design / new media courses include server side modules and universities tend to use PHP; therefore it’s easier to recruit and employ a graduate who has already received some formal training and doesn’t require re-skilling
• Open standard: with plenty of support and knowledge available plus with cost benefits which we can pass onto our customers
• Hosting: cost effective web and database hosting
• Rapid development: with the multitude of support and understanding out there we can quickly build upon others peoples ideas and knowledge

I’d be interested in other’s opinions / additions to this list…. I am sure there are many.

Once we’d made the decision, we mulled over several options. One was to source a pre-made content management system and the latter a PHP framework. Having looked at various CMS we installed and trialed DRUPAL (http://drupal.org/). Our initial thoughts were that we could release CMS driven sites pretty quickly and easily and concentrate on the UI design and front end design aspects. However, it became clear that for a business so used to providing bespoke builds with initial business analysis and design that we were not comfortable with having too much of the development control taken out of our hands – and that is how it seemed with DRUPAL. Additionally, DRUPAL is all things to all men in the CMS world but our belief is that our customers would prefer a little less complexity: we are used to building CMS from the ground up to enable our customers to perform the tasks they require easily and with minimal training. Our worry was that we would potentially be delivering something that performed the task but was not quite what our customers were envisaging. I’d also say that there was a potential danger in us losing part of what makes us good at what we do – sitting down with a customer and listening to what it is they want and then suggesting a solution with impartiality (ie: using the best technology for the job).

So our search moved on and we researched several PHP frameworks in the belief that we could find a happy medium between ‘from the ground up’ development and using an off the shelf CMS, providing us the flexibility and freedom to offer fully bespoke, customised solutions but allowing us to build rapidly and effectively using pre-built modules that can be plugged into your own business entities. Based on several recommendations and a good few months trialing we have settled on using CodeIgniter (http://codeigniter.com/) and have begun to build our own CMS around the framework. Thus far I am happy to report it is just the job and we have had a great deal of success. Soon we will post some more specific information about the projects involved.