The Back Burner

I’ve been developing websites with PHP for about 5 years now and I blush to confess that I have only just discovered I can use bind parameters with SQL, instead of painstakingly building up my SQL statements by concatenating strings, while remembering to deal appropriately with all potentially dangerous characters to avoid the risk of crashes or hacks.

Bind parameters are an unreservedly Good Thing. Not only do they make your SQL more readable, maintainable, and portable, but they also protect against the dreaded SQL injection which is the scourge of badly coded PHP websites developed by people who don’t know any better. And as if that wasn’t enough they can improve performance too.

I am no fan of reinventing the wheel, so since I first started using PHP I have used the open-source ADODB database abstraction library for database access. I like it because it’s fast and lightweight compared to its better-known competitor PEAR::DB. Tutorials are thin on the ground though, and I confess I only discovered its support for bind parameters recently, by reading between the lines of the documentation while looking up something else. Since then I’ve been gradually refactoring existing code — whenever I need to edit some code for some other reason I have a look for any embedded SQL and add some data-binding goodness to it. This is simple to do with ADODB. For example:

Before:

$SQL = "SELECT column1, column2, column3 FROM Tablename WHERE column1 = '$myvalue'";
$Result = $DB->GetRow($SQL);

having first carefully cleaned the contents of $myvalue of course!

After:

$SQL = "SELECT column1, column2, column3 FROM Tablename WHERE column1 = ?";
$Result = $DB->GetRow($SQL, array($myvalue));

Note I didn’t need to quote the string in the SQL statement, and the database library deals with any escaping necessary, in the appropriate style for the database being used — no MySQL-specific code here! In addition the SQL statement is pre-compiled — if you are going to execute the same statement a number of times with different values each time (e.g. when doing multiple inserts), this can really boost performance.

So what’s not to like? I don’t know why this technique isn’t better known among PHP developers. For example here is a lengthy thread discussing SQL injection, involving some apparently quite knowledgeable developers, and yet bind parameters are never mentioned; everyone pins their hopes on the stupidly named PHP function mysql_real_escape_string. Perhaps this will change now that support for binding is built into the PDO database access layer in PHP 5. Even if you are still using PHP 4.x you owe it to yourself to try a database abstraction library instead of endlessly hard-coding for one specific database engine.

Of course I should add that none of this means you can dispense with proper data validation before writing it to the database: the golden rule still remains “Never trust user input”!

These days practically every website has a “contact us” form allowing visitors to send email to the site owner without exposing the recipient’s email address to the world.

Lately I’ve been investigating ways that spammers can hijack these forms to send spam without the site owner’s knowledge. The fact is that it’s alarmingly easy to use an insecure form as a spamming engine, using a technique known as “header injection” — and the resulting spams will be clearly identified as coming from your site, resulting in possible blacklisting of the server, or even having your site shut down by your webhost for spamming.

The good news is that once you know exactly how the spammers can exploit the holes, it’s quite easy to guard against them. My researches soon turned up a page with a technical explanation of the topic. And from there I moved on to sites with examples of techniques for addressing vulnerabilities. Armed with this information it didn’t take me long to knock up a PHP function for processing all input from forms to strip out anything potentially dangerous. And knowing what I know now, I’d be reluctant to use any of the many free “form to mail” scripts without carefully checking whether they are vulnerable to this exploit.

I should stress that although the examples I’ve used are PHP, this problem is not a weakness of any particular scripting language or web server software — it’s simply a result of the fact that when standards for email headers were developed, the Internet was a kinder, gentler place than it is now, and spam wasn’t even a blip on the horizon.

Every January, assorted pundits claim, “This is the year Linux will conquer the desktop!” Every year, they are proved wrong, and Windows continues to power 95% of desktop PCs (web servers are another matter; a very sizable majority of those run some flavour of Unix).

Well, my experience so far suggests that Linux is ready for the desktop — kind of. Using Xandros for everyday tasks is barely distinguishable from using Windows, and many mainstream PC users would be quite happy with it. I had no trouble at all finding replacements for mainstream Windows applications; Xandros comes with pretty much everything you need out of the box. For someone who makes fairly basic use of an office suite, as I do, the free Open Office is a more than adequate replacement for Microsoft Office, and it will save in Microsoft formats, so you can continue to exchange documents with MS Office users.

As for web browsers, you are spoilt for choice — the only unavailable choice, of course, being Microsoft’s very own Internet Explorer! I carried on using Opera, just as I did on Windows, but I could have chosen Firefox or Konqueror. Email was slightly more difficult, since Eudora, the indispensable email client I’ve been using since 1996, is only available for Windows and Mac. I tried Thunderbird, the companion email program to Firefox, didn’t like it, and ended up using Opera’s built-in email facility. It’s idiosyncratic but it has some interesting features, including threading and excellent search and filtering capabilities. For those wedded to Outlook, Evolution is said to be a good alternative.

I’ve already covered text editors in a previous post — Quanta Plus is simply the best editor I’ve ever used, on any platform. Linux has a built-in firewall, and as for anti-virus — I don’t bother!

All of those cover about 90% of my daily work. But what I find I really miss from Windows is the selection of handy little utilities I’d accumulated over the years, that chugged unobtrusively away in the background, helping me manage my workload. It’s turned out to be very hard to find good open-source replacements for these. Of course I could run them using Windows emulation software, but this seems to me to defeat the object of switching. Coming up next: my review of utilities I’ve discovered so far.

A few years ago, when dynamic, interactive websites were not as common as they are now, we decided to showcase our database skills by setting up a simple demonstration website that would allow site visitors to edit the content online. Looking around for some suitable application I hit on my small collection of recipes that I’d been emailing to friends, and the Archetype recipe database was born.

I created two versions — the “play” versions, that visitors could edit, and a live uneditable version that contained myoriginal recipes. I’ve since found it a genuinely useful application — when I find a recipe in a magazine or on a website that I particularly like, I add it to the website and I can then easily find it again, no matter where I am.

But rather embarrassingly, it seems a lot of other people find it useful too. Our website is supposed to promote our web design services, but the recipe pages have become by far the most popular on the site — without bringing in hordes of prospects eager for us to make them a dynamic website too! Looking at the stats for search terms used to find our site is revealing:

… and so it goes on. I’m sure it can’t do our site much good in the search engines, in terms of ranking highly for web design!

But perhaps I should see this as an opportunity. When I realised how popular these pages were, I thought I might as well put some Amazon ads on them, but those have earned me about one cookbook every three years. Now I’ve decided to try putting Google AdSense ads on them — we’ll see if those do any better. So it’s turned out to be a useful space for experimentation with revenue models, and it helps me get aninsight into the economics of web publishing.

More generally, looking at the terms people use to find your site can be a useful exercise. It may alert you to new services you could offer them, if they are searching for products and services related to your business, but which you don’t currently offer. Hmm, on this evidence maybe we should start bottling and selling lemon butter sauce …

A well-known fact about the history of the microcomputer is that it took a “killer application” to make it worth buying a PC: something so useful that it justified the cost of the computer. Back in the early 1980s, that killer app was Visicalc, the first-ever spreadsheet application, which had Apple II computers pouring off the shelves, snapped up by eager accountants.

In a similar way, my Xandros PC sat on the spare desk, providing a development web server and little else, until I found my very own killer app which justified moving that PC onto my desk and dumping the Windows PC on the spare one. The application that did this for me was Quanta Plus — a web editor.

A web editor? But there are dozens of great web editors for Windows! Surely you don’t need Linux just to run an editor? Well, it’s not quite as simple as that. I spend nearly all my working hours editing program code in a text editor — no fancy WYSIWYG tools for me. Since 1993 and Windows 3.1, that editor has been TextPad, which had got welded into the core of my being. I tried other, allegedly superior text editors from time to time but somehow I just couldn’t get along with them and always found myself back with simple, reliable, uncluttered TextPad. It wasn’t perfect, further development seemed to have ground to a halt, but I knew every quirk and feature and it was tuned for just one job — editing text files quickly and efficiently. In fact it was one reason the Linux box was still on the spare desk — I tried half a dozen Linux editors and didn’t like any of them.

Then in October a student on an Open University course I teach said that he couldn’t imagine creating web pages without Quanta. Out of curiosity I visited the site and thought it was worth a try.

I was just starting work on a large PHP website, so it seemed sensible to try Quanta for this. I started it up, had a quick scan through the help files, and set up my first project. Two hours later I was completely hooked. It was one of those rare occasions when you find an application that thinks exactly the way you do. It was the “tipping point” … and within days the Linux box was on my desk with Windows relegated to the outer darkness.

It is interesting to see how something you never knew you needed can prove itself indispensable!

I’ve had a spare computer by my side running Linux for a couple of years now. I started out with a very old, slow PC that struggled to run an ancient version of Red Hat Linux. It was unusable as a desktop machine, but did the job as a development web server for testing sites before unleashing them onto a live server.

When I upgraded my desktop PC (or rather Steve bought a new PC and I got his cast-off, the normal pattern in our office) I decided it was a good opportunity to try Linux on a more realistic platform: my discarded 733 MHz Pentium III. I didn’t want to spend days fiddling about trying to get things working though, so after due research online I plumped for recently-released Xandros, trumpeted as a newbie-friendly release.

It certainly did what it said on the box: I popped the Xandros CD into the drive, clicked a few buttons, and then left it to install. Within half an hour I had a working system — it was easier to install than Windows! I was favourably impressed by the fact that everything worked immediately: all devices recognised, Internet connection working, even file-sharing with the Windows PCs on the network was easily achieved. And it looked very nice too, with a desktop environment barely distinguishable from Windows.

After that, I installed XAMPP, a one-stop way of getting Apache, PHP and MySQL running so that I could continue to use the PC as a development server. That too went smoothly … it seemed Linux was truly “ready for the desktop” — but Xandros stayed on the spare desk and I continued to work on my trusty Windows 2000 PC.

Next instalment: the application that convinced me to push the Windows PC aside and put the Linux box on my desk!

Yes, blogs are *so* 2005! But our plan to start an email newsletter for clients was overtaken by events. Nowadays it makes much more sense to create a blog which can be syndicated via RSS, avoiding all the problems associated with inboxes overflowing with spam. And I was shamed into it by the fact that Glenn had me set up a blog for him in November, and I still hadn’t done anything about the one I’d been meaning to do myself for months.

The plan is to post stuff that will be useful to us or our clients. Currently there is no definite posting schedule — I’ll just post when I feel I have something useful to say.

A further purpose of this blog is to show what you can do with free or open-source tools. Although I could easily have installed blog software on our server and spent hours customising it, I’ve deliberately chosen to use a free service to create the blog. It took me about ten minutes to set up this blog — I hope that over the weeks you’ll see it evolve to blend with our existing website, as well as gaining new features.

It’s called The Back Burner because … well, it’s been on the back burner for a long time!

Once you’ve established the purpose of your website, and who will be using it, you can start to plan the basic structure of the site, which will determine the all-important site navigation system.

Too many sites reflect the internal politics of the committee that created them — don’t let yours fall into this trap! The structure of the site should reflect the perspective of your target audience, not your own internal organization. If you have identified several audiences (e.g. investors, customers, employees) you may need to offer different paths through the site to help them find what they need.

So your next job is to create a structure which will support the site’s objectives. Always keep in mind that visitors to your site are looking for information. Its purpose should be immediately obvious, and it should be easy to navigate. Great content is no use if people can’t find it!

The first thing you need to do is to establish a “content inventory” by asking yourself two questions:

• What sort of information are my visitors looking for? Remember different audiences may have different requirements.
• What will visitors want to do? This could include buying goods, searching for information, personalising content, signing up for a newsletter …

Make a list of all the ideas you come up with, if necessary categorized by audience. Then check that these ideas are consistent with the goals of the site — throw out any that aren’t. The next step is to take all these elements and organize them into a logical structure. Use whatever means you are comfortable with for this — it might be a flowchart, a mind map diagram, or even a collection of index cards which you can shuffle about on a table and divide into piles representing different sections of the site. It can also be helpful to visualize your site using a metaphor — for example, if you are selling groceries, a supermarket is an obvious organizational model. It’s a good idea to involve people from different parts of your organization in this process — they will bring valuable perspectives which you may have overlooked.

Once you are happy with your structure, draw up a formal site plan and get everyone involved to agree on it. This document will ultimately determine the basic navigational structure which will be used for every page on the site. You (or your designer) will also be able to use it to create a list of all the pages which need to be created, and the elements they must include. This list will later be used to allocate tasks and manage the development process.

The major navigation elements of the site should now be obvious. For example, you have probably identified major sections of the site which should be accessible from every page. If the site is quite small, this may be all the navigation you need. If you have a deep, many-layered structure, you will probably want to add a sub-menu of items specific to each section, to avoid cluttering every page with a confusing mass of options.

A well-defined site structure means you know from the outset what the scope of the project is, and it makes designing consistent page layouts and templates a much easier task. In the long run, it will simplify maintenance and updating of the site, so you can keep content fresh and add new features in response to customer demand without busting your budget. Result — more happy customers and a boost to your bottom line!

So you’ve decided to create a new Web site, or renovate your existing one. We all know that in Internet time, the best time to launch a new project is always last week, so it’s very tempting to plunge straight in, call your web designer, and fix up a meeting. But stop and reflect before you grab that phone. Here are three questions you should ask yourself first, whether you are creating the site yourself or paying a professional to do it for you. In the long run you’ll save yourself both time and money.

What is the site for?

Yes, this sounds like a dumb question. But you must have visited websites where even after viewing three or four pages, you couldn’t work out what the point was! If you aren’t clear about your goals, your visitors won’t be either. So the very first thing you should do is to define the purpose of your site. Try to distil out the essence of your site into a single short paragraph — or even a single sentence. If you can’t do this, your site will lack focus. For example, “The goal of this site is to generate leads for Product X”. Of course the site may have other, subsidiary objectives — if that’s the case note these down too, so that you can take them into account during the design process.

Who are you trying to reach?

Now you know what your site is for, imagine the people who will use it. Try to get inside their heads — how old are they? Are they male or female? What are their interests? What other sites do they visit? What do they want from you? Some people find it helpful to invent characters representing different types of visitor, and picture them using the site.

If you are revamping an existing site you already have some very valuable information about your customers in your server log files. Use a log analysis package to identify which are the most and least popular pages or sections of your site. The terms people entered into search engines to find you are a good indicator of their interests. And looking at the paths people take through your site can often indicate where navigation is confusing, or suggest areas that could be expanded.

Whatever the overall goal of your site, remember it must please the end users if it is to succeed — look at it from their point of view, and try to provide information and services of value to them.

How will you know you have succeeded?

It’s easy to say “The goal of my site is to sell more widgets”. Or “We want to increase page views and hence advertising revenue.” But how will you know when you have achieved your goal? Try to come up with some specific, measurable objectives related to your primary goal. For example, “We expect the new website to increase sales of widgets by 30% in the first 6 months”. This is important for at least two reasons:

• It gives you a specific target to aim for. If everyone working on the project keeps this target in mind, it will focus their efforts on the tasks that need to be done to achieve it. And with proper planning, you can evaluate how the designer’s proposals will advance your goals. If that cool 500K Flash movie on the home page doesn’t contribute to a specific objective, then dump it!
• It gives you something to measure results against. If after 6 months sales have only increased by 10%, what went wrong? Were your objectives realistic? What could you have done differently? Of course if sales increase by 60%, you can give yourself a well-earned pat on the back!

It needn’t take a long time to come up with answers to these questions. Doing this preliminary groundwork will help your web designer come up with an appropriate solution, and save you expensive consultancy time. And while this approach doesn’t guarantee success, it will greatly improve your chances of building a website that works.