It’s a frustrating problem that is easily solved if you put your mind to it – ignoring it is nothing short of lazy.

On the client-side, we can use JavaScript to prevent the user from submitting the form more than once. Observe:

<form action="script.php" method="post" onclick="validateForm();">
Your name? <input name="name" value=""> <input type="submit">
</form>
<script type="text/javascript">
var submitted=false;
function validateForm() {
  if (submitted) {
    alert("Please only submit the form once.");
    return false;
  } else {
    return true;
  }
}
</script>

The idea is that when the user clicks the submit button, we flag the action in ‘submitted’. If the user clicks again, the function validateForm() will check ‘submitted’ and prevent multiple submissions of the form.

But this isn’t enough – not everybody has JavaScript enabled, and assuming so would be lazy.

We need some internal detection too, and one way to detect multiple submissions would be to use PHP sessions. Observe:

<?php
  session_start();
  if ($_SESSION['formsessions'][$_POST['formsession']]) {
    // form already submitted!
    // ideally, at this point, you'd want to forward them to another page.
    exit('form submitted twice.')
  }
// mark the session as submitted.
  $_SESSION['formsessions'][$_POST['formsession']]=true;
?>

Again, we’re checking to see if the form has already been submitted. This script would require that we submit a ‘formsession’ field with the form to make it uniquely identifiable. This could be as easy as inserting the following into the form code:

<?php
  echo '<input type="hidden" name="formsession" value="'.md5(date('U').'-'.rand(1000000,9999999)).'">';
?>

With these two methods combined, no user should be able to submit the same form twice – accidentally, at least.

There’s just something so exciting about that little padlock appearing beside your domain name. To your customers it shows that you care about their online safety, and that you want them to feel safe.

But, HTTPS can be a complete pain to code, and many people go about it completely the wrong way. So here’s my entry to help those of you struggling with integrating HTTPS in PHP.

Look to the right – wouldn’t you feel safer seeing padlocks everywhere? Your customers would too. But it really doesn’t need to be everywhere. If you served 100,000 pages a day, chances are only 1,000 of those pages need to be served securely. If we were running a shop front, selling computer parts, this is how the user’s actions would look in an ideal world:

1. User types in www.yourshop.co.uk and presses enter.
2. They type ‘computer monitor lead’ into the search box and hit enter.
3. They see that you have a wide range of leads available and spot the one they want. So they click ‘Add To Cart’.
4. They notice a cool TV Tuner in the similar items section, so they click that. Then they click ‘Add To Cart’ again.
5. Now they’ve had enough of running up a bill, so they click ‘Checkout’.
6. They type in their details, such as their first name, last name and address.
7. They fill in their credit card numbers.
8. They click Process and wait.
9. Your site serves them with the Checkout Complete page.

1. Users Don’t Like Unexpected Messages

First, avoid prompting those horrible error messages that warn the user of insecure data on a secure page. These are usually present when the page includes links to images on other servers that aren’t secure – but it can also happen if you use full URLs instead of relative URLs. Example:

WRONG: <img src=”http://www.yourshop.co.uk/image/robodog.jpg”>

CORRECT: <img src=”/image/robodog.jpg”>

You see? Use relative paths and you won’t run into this problem. As for images on other websites, upload them on to your own site. Example:

Evading these error messages helps add to the user experience.

2. Make HTTPS Easy

Manually linking to HTTPS and HTTP is a nightmare, and you’ll probably always be correcting links. It also doesn’t make for good error correction. Here’s how to do it effectively.

In every script you think should be served via HTTPS, place $securePage=1 at the very beginning of the script – that’s BEFORE your config script.

In your config script, we will place HTTPS detection code to redirect if appropriate.

      if ($_SERVER['HTTPS']=='on') {
        // we are on a secure page.
        if (!$securepage) {
          // but we shouldn't be!
          $url='http://www.yourshop.co.uk'.$_SERVER['REQUEST_URI'];
          header('location: '.$url);
          exit;
        }
      } else {
        // we aren't on a secure page.
        if ($securepage) {
          // but we should be!
          $url='https://www.yourshop.co.uk'.$_SERVER['REQUEST_URI'];
          header('location: '.$url);
          exit;
        }
      }

So if we’re currently in HTTPS mode, but $securePage doesn’t equal 1, the config script will redirect to HTTP mode. And the same the other way round – if $securePage says we should be serving secure pages, config will redirect to HTTPS mode.

This is a simple yet effective way of enforcing secure behaviour. It doesn’t mean that you can’t provide full URL links where they are appropriate – and it is recommended that you do so if you can.

Let me know if you use my code in your own projects.

Since switching from a Windows server to a UNIX server, I noticed a huge increase in overall site performance – but sometimes, with no noticeable pattern, a page would take a minute to load against the average which was under a second.

After messing with the scripts and painstakingly commenting out sections of code, I discovered that the problem lie quietly in the PHP sessions – specifically the session_start function. Perhaps it has something to do with disk operations and UNIX operating systems, whatever it was it was causing some frustrating performance problems.

I decided to alter rid of all session functions and create my own version that interacted with a MySQL HEAP table – that’s a table stored in the server’s memory instead of on disk. Instantly the site performance was noticeable better, pages loaded more instantaneously.

Looking into the PHP sessions further I discovered another flaw – if your visitor was to load several pages at once, each page would pause until the previous page had finished loading. This is because no two scripts can access the same session at any given time – session access is serial, not parallel. If a page takes one minute to process and another page takes a second to process, but the heavier page is loaded first, the reader will have to wait for heavier page to finished processing because they can see the page that would have taken a second to process. This increases the queues to the web server and doesn’t do much for the user’s experience.

It may however be helpful in some instances, for example if you were altering a virtual tree structure you wouldn’t want the functions to collide in operation. For what I had been using sessions for, it wasn’t helpful at all.

I’m going to make a modular version of the alternative session code and publish it here, so come back later if you want a copy!

PHP Expert Editor is developed by Ankord Development Group, and is one of the more serious entries in this field. And at 35 EUR for a life time license, it won’t shred your wallet either. (What? You didn’t expect it to be free, did you?)

The basics of the editor make writing a PHP script a breeze, with features such as code highlighting – where the difference between HTML and PHP is blazingly obvious, and identifying quotes that have been left open isn’t a needle-in-a-haystack job anymore. But other features such as the left hand side structure that allows you to close blocks of text off and just work with the text you need make editing considerably less stressful.

PHP Expert Editor also has an FTP client built in, enabling it to access practically anything.

What else is there? A built in colour selector, all the usual HTML form tools, HTML symbols, auto indentation, macros, syntax checking and integrated script checking. Basically – yes – this is truly the mothership. Get on board.

I think the most useful feature in this editor would be its knowledge of PHP’s internal functions. When you type ‘join’, a helpful balloon appears above the cursor showing you the appropriate parameters for the function. It does it with everything, and really helps the programmer concentrate on what matters – the coding.

If you want to try it, it comes with a 30 day trial, so you don’t have anything to lose. You can download it at www.phpexperteditor.com.

Specifically, this is designed for PHP & MySQL, but in theory could be adapted to work with other platforms.

The idea is to take the large part of the data (the content) and place it into a set of tables where it can be managed by a resource system.

Suppose we have a table called ‘posts’, which stored a unique ID, title, date and content for each row. Now suppose we used this table to store the daily posts from our members. If we had 1000 members who posted daily, it wouldn’t be long before our table reached a phenomenal size.

When you query that table for a list of the entries, you’ll almost never use the content field. Separating the content from the rest of the information allows for quicker alteration of what we’ll refer to now as the ‘log’.

This calls for a system that can manage content in its bare form – text. We need to be able to take the content, submit it to a function that returns a resource-ID that we can store in the ‘log’. Then later retrieve that data using the resource-ID.

Making the system structured like this will allow for further optimisation later using a utility called MEMCACHED, but we’ll leave that for a later post.

There are many advantages to this system, that we’ll discuss in the next post.