Those Damn Backslashes!
October 7, 2008 – 7:19 am
I’ve just finished writing my first proper php and mysql based online shop site – complete with shopping basket and checkout. It was an interesting process and i learnt a lot from it. I’m very pleased with the result – as is my client – and it will be a nice addition to my portfolio.
One of the main things i learnt was that i need to be more organised for the planning stage. I need to sit down with a pen and some paper and map out a page flow and what exactly happens on each page. I did do a little of that for this job, but not in nearly as much depth as i should have done. But, of course, until you’ve done a job like this and started to play with what you’ve done so far, it can be hard to visualise exactly what you’re going to need.
In future i’ll write down all the steps a customer’s likely to go through on their way to a purchase – or on their way to not buying anything, if that’s what they end up doing. If i’d done that for this job, it would have saved me time. But, more importantly, it would probably have allowed me to identify which chunks of code i could make reusable with a small amount of extra effort at the time of first coding them.
There are lots of sections of the over 5000 lines of code in this project that could have been made reusable, but mostly they were just sufficiently different to make it more trouble that it would have been worth. As a result, there are very few functions and only one class – my first object oriented php5 class! There’s one chunk that i wanted to rewrite into a class, but i haven’t yet, because its use varies a bit too much. But having it as a class would be handy in future, so i’ll definitely do it when i get a few moments spare.
One thing that bugged me a lot during the last stages of development of this site – once there was some decently diverse data to test it with – was backslashes. Using mysqli_real_escape_string(), to make sure all user input data gets sanitized before using it in a mysql statement, means you’ve got to unescape all those strings before you use that data again. I didn’t think about this until my client started writing descriptions of the photos – which included inverted commas.
It’s a simple matter to use stripslashes() to fix the problem, but when the issue affects pre-filled input fields in an edit form, the backslashes can multiply at an alarming rate before you use it, as each time you save the form data every backslash gets escaped again! And every time i thought i’d fixed the problem, it would pop up again somewhere else. Luckily for me one of the photos the client uploaded during the secondary testing phase had an inverted comma in the title – and that title’s used all over the place, in headers, thumbnail titles, <img> tags, and breadcrumbs, so it wouldn’t have been a good look if i’d discovered it after the site went live.
All in all, it was an interesting and satisfying – if sometimes rather stressful – process. And i’m very happy with the result. However, i’m not entirely happy with the state of the code that lies behind it. It’s a bit too messy for my liking – and not yet well enough commented. I changed my views on some aspects of coding style in the process of writing it, and i haven’t quite decided on all the style-related issues yet, although reading other people’s ideas on php coding style has helped. Over the next few days, i’ll be going through my code and commenting as much as possible – before i forget how it all works – and i’ll try not to break too much in the process! 
If you’d like to check out the result of my labours, it’s at http://AutographedMusicPhotos.com