Often as a site grows, its performance degrades sharply. This can happen for many reasons, and is typical for a site that continually undergoes maintenance. As a project ages, the content often grows as well. More data, more code revisions, more ideas to turn into code for the site, etc.

I’m exploring this subject because a site of mine is in need of a performance boost. It was a snappy little site when I first launched it, but I’ve had many more ideas since then, and I’ve implemented almost all of them. Now regular browsing through the site is noticeable slower.

I’ve got a short list of performance enhancing ideas that I’m going to explore below.

Separating CSS and JS Files

For starters, if you have inline CSS or JS, you should separate these into separate files. This is a huge performance win, because a browser can cache mystyles.css or javastuff.js, but can’t cache it if it’s included inline in your page source code. Most performance wins happen client side - taking advantage of caching is often more efficient than making slight changes to server side code, though this isn’t a rule that’s set in stone; You could have terrible server side code that slows down the site too. My site in question already has the CSS and JS files separated, but it’s worth mentioning in case you haven’t done this.

Minifying CSS and JS Files

This is something that enterprise many sites do, so I thought I would go ahead and do this. Basically, it means removing spaces,tabs, and line returns wherever possible so that the file size is smaller, but the code executes as normal. When minifying a CSS file, I prefer to leave one CSS selector per line, and then listing each CSS property after it. This reduces file size, but makes the file still human readable/editable.

Here is an example of a fully minified CSS file from MSN - http://tk2.stc.s-msn.com/br/hp/11/en-us/css/hp_1.css - I think this is overdoing it, and doing it this way is probably done through an automated script, as this would be next to impossible for a developer to edit in a development environment.

For complex sites, this is going to be a better win than for simple sites. I saw about a 20% decrease in file size. For very, very simple sites (read very), using an external CSS file can slow things down because of the server disk access time of retrieving the external CSS file. The original Google page, for example, only has a few lines of CSS, and therefore uses inline CSS. For anything more complicated, include it in an external file.

Reducing Image Use

Many blogs and news oriented sites use too many images. This slows things down for first time readers, who don’t have the images cached. A good tool to examine load times of everything on your site is Firebug, a plugin for Firefox. You can get the latest version of Firebug here. The image below is a screen capture of one of the features in Firebug that lets you examine exactly how long everything took to load. If your site is nearing half a megabyte (~500kb), it’s time to put less on your pages, or use smaller images.

Using Less Database Queries

This is very important on some sites, and irrelevant on others. If you are using a basic installation of Wordpress, for example, there really aren’t too many ways for an average person to speed it up, without writing the developers and telling them to use less queries next release. For heavily customized sites based on existing platforms and fully custom database driven sites, database queries can be the make or break of your site performance. Basic rule: if you are writing your own queries, and you don’t know how they perform, then you shouldn’t be writing your own queries. Having said that, never outright trust queries from other somewhat experienced developers. Developing for my firm, a Fortune 500 company, we have often encountered popular plugins for Wordpress or modules for Drupal that have queries in them that are written poorly. Just because another developer made it, doesn’t mean they did it right.

Another way to use less queries, is to outright display less content. This is easy to accomplish if you’re using a blog platform. If you’ve got 20 posts a page, reduce this number. The number of queries your blog site makes is directly proportional to the number of posts or entries it is trying to display.

Better Hosting Plan or Better Hardware

This isn’t an option for me, because the next level of hosting plans with GoDaddy is out of my current budget range. For others, however, it may be an option. It’s worth looking into.

Wordpress, the engine that is behind the post you are currently reading, is easy to upgrade with most hosting environments. However, upgrades can get tricky in locked-down enterprise environments.

For the most secure environment, the MYSQL database user that is used by Wordpress (hardcoded in your wp-config.php file) to retrieve and set information should not have Drop, Alter, and Create database privileges. If it did, malicious code would have an easier time disrupting the database. This is a problem because upgrading Wordpress usually involves some major additions or changes to the database structure, for which these privileges are needed.

So what is the solution? Basically it is running the upgrade as the root user. But, hardcoding root credentials in your wp-config.php file for a little bit is not good security practice, even if you change it back afterward. What you need to do is run an SQL script with all the database statements that are required for upgrade directly on the MYSQL server, or by using the MYSQL command line client.

Capturing the upgrade sequence is a little more difficult. Most enterprise installations have a development environment with looser security, possibly only accessible from inside the firewall of your organization. If your development environment is setup with a database user that does have alter, drop, and create credentials you’re in good shape.

Open up the /wp-includes/wp-db.php file and find the query() function. This is the function that Wordpress calls before each and every database call. On the first line of the function, add this line:

error_log($query);

This will output each query into your PHP error log file. Empty this file before attempting an upgrade on your development environment. Wordpress upgrades involve replacing all core files, and then logging in to the admin interface and upgrading the database by clicking a prominent upgrade button. After you have done this, the error log file will contain all the queries run by the upgrade.

There are more queries in here than are necessary to upgrade Wordpress. Delete all select queries, leaving a combination of alter, drop, create, or insert statements. Rename the error log file upgrade.sql and you’ve got the entire database upgrade in a ready to run script.

Publish the changed files up to your live environment. Your site will stay up even if a database change is required in the back end - this is a feature of Wordpress allowing for easier upgrades without site downtime. Next, run your upgrade.sql script with root privileges, or send it to your DBA team to run. You’re all upgraded, and you kept your site secure the entire time.

This same process can be used for upgrades to Wordpress Plugins, which often also require Alter, Create, and Drop statements to their tables.

Security is an important part of PHP programming, and PHP provides several tools for securing database queries and HTML display. However, knowing which function to use and when to use it can be somewhat confusing, as there’s many details to pay attention to. It’s important not to leave your website open to cross-site scripting or SQL injection attacks.

This example and explanation will focus on a common web scenario - a user submitting data via a form, being asked to confirm it, and then being displayed the data after it is stored in the database.

1. Initial User Input

In this scenario, a user will be presented an input box for which they can add a review about a particular product on a public facing website. The user is not allowed to use html, similar to the restrictions on product reviews on Amazon.com. The user inserts their review into the input box and then clicks submit.

2. User Input Preview and Cross Site Scripting Prevention

Now, we want to show the user their review and have them confirm it before we add it to the database. This is a prime example of a situation that leaves a website open for a XSS (cross-site scripting) attack. We don’t know what the user entered on the previous page, and they could be purposely entering malicious content. Because what they entered in going to be output to the screen, if they input raw PHP code, it could get executed unknowingly by our server. To prevent this, we need to html encode all potentially dangerous characters for display on the screen.

I would recommend using htmlentities() to do this, and use the ENT_QUOTES option as shown below, which means that both single and double quotes will also be encoded. Because we also decided that we wouldn’t allow HTML, we’ll want to strip that HTML before displaying the results, to give the user an accurate preview. Before doing any of this, we’ll have to grab the submitted data from the submitted form - this tutorial won’t cover this, but there are plenty of web tutorials available for doing this.

<?php
 
//strip HTML tags from input data
$input_data = strip_tags($input_data);
 
//turn all characters into their html equivalent
$preview_data = htmlentities($input_data, ENT_QUOTES);
 
//...display $preview_data 
 
?>

3. Database Insert and SQL Injection Protection

Now, let’s say the user previews above data, and clicks accept, which will send this data to another script for entry into the database. Protecting your database from SQL injection requires different steps than protecting against cross-site scripting.

It is very likely that you don’t want to store the user’s data in HTML encoded form. Let’s say you are using a varchar(32) column in your database, and you had an input box that was 32 characters long. If you were trying to store the HTML equivalent of this in your database, you would need a column that was much larger to guarantee that data didn’t get lost. This is because the HTML equivalent of a single character is often many characters long. For example, a double quote (”) becomes ", and an ampersand (&) becomes &. We need to guard against single quotes, because these can cause an SQL injection problem, depending on how your database is setup. Consider this example:

<?php
 
$name = "George'); DELETE FROM mytable; INSERT INTO mytable (name) VALUES ('you got hacked";
 
$sql = "INSERT INTO mytable (name) VALUES ('$name')";
 
//...run the $sql query
 
?>

If your SQL server allows more than one SQL command on a single query request, you’ve just lost lots of data. While it’s a good idea to lock down your database server so it doesn’t allow this, you always want to secure your code independently of the database, in case you change your hosting setup later.

To secure your script, you can use the addslashes() function which will escape both single and double quotes, by adding backslashes before them, to prevent multiple queries from being executed. You’ll also want to test for the length of the input field, as forged form requests are easy as can be using tools like Firebug. Here is example code that will accomplish that:

<?php
 
//escape trouble characters
$name = addslashes($name);
 
//make sure not longer than expected length
$name = substr($name, 0, 32);
 
$sql = "INSERT INTO mytable (name) VALUES ('$name')";
 
//...run the $sql query
 
?>

Note that there is the possibility of valid user input being cut off when being inserted into the database. If the user used all 32 characters in the input box, and a single quote was one of them, then the above code would trim off the last character. You may want to prevent this by using a 28 max character input box for a varchar(32) column, giving the user 4 opportunities to use an escaped character without having their input cut off.

4. Retrieving and Displaying the Data From the Database

Now that the data is safely in the database, everything is safe right? Wrong. We elected not to store HTML encoded data from users. This means that we are still at risk from a Cross Site Scripting attack every time we query and then display the data. What you’ll probably want to do is create a function that sanitizes database data before being displayed on the screen. No only should you HTML encode the data, but you’ll also want to remove the backslashes you added earlier, as these aren’t meant to be displayed. Here’s what your function could look like:

<?php 
 
function sanitize_data($input_data) {
  return htmlentities(stripslashes($input_data), ENT_QUOTES);
}
 
?>

Creating blog posts is extremely easy in Wordpress, but adding simple thumbnails to your posts is not. I’m not talking about adding images within the post content, but adding them to your theme so they display in a standardized way in your blog loop, and on individual post pages.

The problem is that though Wordpress allows inserting images within posts, there is no way to “attach” these images to the post, so that theme designers can pull standardized images out for display. By making a few changes to your Wordpress configuration and your theme templates, and by using the Post Thumbnails plugin that I have written, you will be able to add thumbnails to your site in an intelligent way.

Wordpress Configuration

First step is to login to your Wordpress admin dashboard and navigate to the Settings -> Miscellaneous page. Here you will need to change:

- Uncheck the “Organize my uploads into month- and year-based folders.”

- Change the Wordpress thumbnail size to your desired size. This is important! Take careful thought when making this decision – you will break old post’s thumbnails if you chose to change this value later. I recommend 50×50 pixels.

Plugin Installation

Download the Post Thumbnail plugin using this link. Unzip it and place the file within your wp-content/plugins/ directory. Navigate to the Plugins menu within the Wordpress admin dashboard and activate this plugin.

You’re going to need a default post thumbnail to be used when no image is associated with a post. Upload an image that is the same size as the thumbnail size you chose above to the wp-admin/uploads folder, or the same folder you have chosen for uploads if you’re using a custom location. On most installations that folder would be wp-content/uploads/.

After you’ve uploaded the image, paste the name into the first line of code in the plugin PHP file:

define('DEFAULT_POST_THUMBNAIL', 'default_thumbnail_file.jpg');

Change the above default_thumbnail_file.jpg to whatever your image was called.

Plugin Usage

After the plugin has been activated, you will notice a new box titled Post Thumbnail on the Wordpress Write and Edit screens. To get a thumbnail attached to your post, upload an image using Wordpress’ default image uploading mechanism, which is a button next to the Add Media label near the top of those screens. This opens up a popup window for uploading images. Upload your image, but you don’t need to insert it into the post. Instead copy the file name (ex. myimage.jpg) and then click on the X to close the window.

Next, paste the file name into the Source Image input field in the Post Thumbnail box and click save. After saving, you will notice that an image name will be displayed in the Generated Thumbnail box. This is the thumbnail version of your source image, that Wordpress resized for you when you initially uploaded the image.

Adding the Thumbnail to Your Theme

Now that thumbnails are being attached to posts, we need to modify our theme to display them. It’s up to you to decide where you want to place them, but I would recommend adding the thumbnail to your template wherever you use the Wordpress loop. Below is a code snippet that inserts a thumbnail into the Default Wordpress theme’s index.php file, so thumbnails will show up on the main page of your site. Only one new line needs to be added.

<?php while (have_posts()) : the_post(); ?>
  <div class="post" id="post-<?php the_ID(); ?>">
    <h2>
    <!-- Begin New Code-->
    <div style="float:left; margin:5px;">
      <?php echo get_post_thumbnail(get_the_ID()); ?>
    </div>
    <!-- End New Code-->
    <a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to 
    <?php the_title_attribute(); ?>"><?php the_title(); ?></a></h2>
    <small>
      <?php the_time('F jS, Y') ?> <!-- by <?php the_author() ?> -->
    </small>
 
    <div class="entry">
      <?php the_content('Read the rest of this entry &raquo;'); ?>
    </div>
 
    <p class="postmetadata"><?php the_tags('Tags: ', ', ', '<br />'); ?> 
    Posted in <?php the_category(', ') ?> | 
    <?php edit_post_link('Edit', '', ' | '); ?>  
    <?php comments_popup_link('No Comments &#187;', 
    '1 Comment &#187;', '% Comments &#187;'); ?>
    </p>
  </div>
<?php endwhile; ?>

Here’s what my above post looked like with the above template code:

Other templates like single.php and archive.php in the Default theme have very similar code where you can also insert the thumbnail. Your theme may differ, but usage is very simple. Just call the following function in your template wherever you want to display the thumbnail:

<?php echo get_post_thumbnail(get_the_ID()); ?>

There has been much discussion about a recent bug/issue with Wordpress that prevents scheduled posts from working properly. The problem is somewhat unrelated to Wordpress itself, and is primarily a hosting setup issue. Scheduled posts are published via the use of a cron script. Wordpress attempts to call the cron script with an fsockopen() function call. Many popular hosts disable the use of fopen() in their PHP configuration, which also disables the fsockopen() function, preventing your cron from firing which prevents your scheduled posts from being published.

A more robust way of programming this part of the code would be to try other functions like curl on failure of the original fsockopen() call. If curl is unavailable, then the calling script should just execute the code contained within the wp-cron.php file itself, instead of trying to make an http request to execute it.

I’ve put together a simple fix for sites that cannot use the fsockopen() function. It’s a simple addition, and just requires attention when upgrading. Steps for upgrading are detailed below the fix.

Open up your wp-cron.php file and copy the contents following the “if ( $_GET['check'] != wp_hash(’187425′) ) exit;” line.

Now you are going to have to paste these lines at the very end of the spawn_cron() function in wp-includes/cron.php. After pasting them in you are going to have to change the “if ( $argyle )” clause to be an if/else clause. This will cause the else clause to execute when fsockopen() fails.

In Wordpress 2.6.3, the spawn_cron() function within the wp-includes/cron.php file will now look like this:

function spawn_cron() {
  $crons = _get_cron_array();
 
  if ( !is_array($crons) )
    return;
 
  $keys = array_keys( $crons );
  if ( array_shift( $keys ) > time() )
    return;
 
  $cron_url = get_option( 'siteurl' ) . '/wp-cron.php';
  $parts = parse_url( $cron_url );
 
  if ($parts['scheme'] == 'https') {
    // support for SSL was added in 4.3.0
    if (version_compare(phpversion(), '4.3.0', '>=') && function_exists('openssl_open')) {
      $port = isset($parts['port']) ? $parts['port'] : 443;
      $argyle = @fsockopen('ssl://' . $parts['host'], $port, $errno, $errstr, 0.01);
    } else {
      return false;
    }
  } else {
    $port = isset($parts['port']) ? $parts['port'] : 80;
    $argyle = @ fsockopen( $parts['host'], $port, $errno, $errstr, 0.01 );
  }
 
  if ( $argyle ) {
    fputs( $argyle, 
      "GET {$parts['path']}?check=" . wp_hash('187425') . " HTTP/1.0\r\n"
      . "Host: {$_SERVER['HTTP_HOST']}\r\n\r\n"
    );
  }
  else {
    //BEGIN COPIED wp-cron.php CONTENTS
    if ( get_option('doing_cron') > time() )
      exit;
 
    update_option('doing_cron', time() + 30);
 
    $crons = _get_cron_array();
    $keys = array_keys($crons);
    if (!is_array($crons) || $keys[0] > time())
      return;
 
    foreach ($crons as $timestamp => $cronhooks) {
      if ($timestamp > time()) break;
      foreach ($cronhooks as $hook => $keys) {
        foreach ($keys as $key => $args) {
          $schedule = $args['schedule'];
          if ($schedule != false) {
            $new_args = array($timestamp, $schedule, $hook, $args['args']);
            call_user_func_array('wp_reschedule_event', $new_args);
          }
          wp_unschedule_event($timestamp, $hook, $args['args']);
          do_action_ref_array($hook, $args['args']);
        }
      }
    }
 
    update_option('doing_cron', 0);
    //END COPIED wp-cron.php CONTENTS
  }
}

Upgrading

It is very important to remember that you’ll have to take special precautions when upgrading. When upgrading, you are going to have to perform the same copy/paste and alter within the wp-includes/cron.php file. Take whatever the contents of the wp-cron.php file are and copy them after the above mentioned hash check line.

I recently came across the need to efficiently parse a string and find what was in between two “marker” strings. I was parsing a logfile with a particular preset format. The line looked like this:

$str = '2008-10-07_00:00:19 - ip:[213.21.198.231] page:[/phpsimplechat/documentation_usage.php]';

I wanted to be able to easily pull out the ip and page information in a straight-forward way without repeating code. After a little tinkering I came up with a get_token() function that accomplished my goal nicely. The function is below:

function get_token($start_token, $end_token, $haystack, $offset = 0) {
 
	$start = stripos($haystack, $start_token, $offset);
	$end = stripos(substr($haystack, $start), $end_token);
 
	if ($start !== false && $end !== false) {
		$start_pos = $start + strlen($start_token);
		$end_pos = $end - strlen($end_token);
		return substr($haystack, $start_pos, $end_pos);
	}
	return false;
}

Let’s take my above example - if I want to pull out the ip and page information from the given string, I only need to implement the below code:

$str = '2008-10-07_00:00:19 - ip:[213.21.198.231] page:[/phpsimplechat/documentation_usage.php]';
$ip = get_token('ip:[', ']', $str);
$page = get_token('page:[', ']', $str);

The optional offset argument allows you to specify how many characters into the $haystack that you want to start looking;

Here is another example usage in which we want to pull the title out of some HTML code.

$str = 'This is the body';
$title = get_token('', $str);

Those programmers who took computer science classes in C++ or Java and then started looking at popular open source PHP scripts may be surprised that the coding standards are somewhat different from what they are used to. Unfortunately, it’s hard to nail down good coding standards for PHP because it has so many syntaxes and does so many things. On one side, PHP is a serious object-oriented language and demanding of java-like syntax, but on another it’s a scripting language and very close to HTML.

One of the older and widely adopted PHP coding standards is based on Todd Hoff’s C++ Coding Standard and is available at http://www.dagbladet.no/development/phpcodingstandard/. Though it is widely used, and (as of the time of writing this) the number one result for “php coding standards” on Google, I give this the least cred because not only was it adopted from a C++ standard but it was not put together by an open source community or company.

The two “most official” coding standards are the PEAR PHP Standards (http://pear.php.net/manual/en/standards.php) and the Zend Framework Coding Standard for PHP (http://framework.zend.com/manual/en/coding-standard.html).

There are also other PHP Standards the are specific to certain projects, like Drupal (http://drupal.org/coding-standards) or Wordpress (http://codex.wordpress.org/WordPress_Coding_Standards), and are certainly valid as these frameworks have thousands of developers adding to their codebase, but they tend to be less detailed the above “official” coding standards.

I personally like the Zend standards the best, as they are the most detailed and easy to follow, but I actually prefer the variable and function naming convention of the Wordpress standard which uses all lowercase words separated by underscores (my_function()) as opposed to the more popular Java style function names (myFunction()) used by the other standards.

At some point in the future, I may write my own coding standards and publish them on this site, combining the best elements from each standard.

PHP provides the mail() function for easy sending of mail from your PHP server. The problem is that sending HTML email (the most popular format for emails) is not easily done using native PHP functions. I’ve provided below a somewhat foolproof function that will allow you to send HTML emails.

Simply pass in a to address, from address, from name (which is used as a nickname in email clients instead of displaying the sender’s email address), subject, and a properly formatted HTML email message.

If you are sending to multiple recipients, you can pass the $to_email parameter in as an array of multiple email addresses.

HTML Email Function

function send_email ($to_email, $from_email, $from_name, $subject, $msg) {
	//split up to email array, if given
	if (is_array($to_email)) {
		$to_email_string = implode(', ', $to_email);
	}
	else {
		$to_email_string = $to_email;
	}
 
	//Assemble headers
	$headers  = 'MIME-Version: 1.0' . "\r\n";
	$headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
	$headers .= "From: $from_name <$from_email>" . "\r\n";
 
	//send via PHP's mail() function
	mail($to_email_string, $subject, $msg, $headers);
}

Usage

You call the function like this:

send_email("me@gmail.com", "roger@att.com", "Roger", "Hello There", 
  "<html>Hello There <strong>Bob</strong>! How are you doing</html>!");

Or, alternately, you call it like this when sending to multiple email addresses:

send_email(array("me@gmail.com", "sal@gmail.com"), "roger@att.com", "Roger", 
  "Hello There", "<html>Hello There <strong>Bob</strong>! How are you doing</html>!");

HTML Email Formatting

Remember that formatting HTML for email is different than for webpages. Do not use a CSS file and do not declare CSS in the head of your document. Instead, use either inline CSS or “Old School” HTML like font tags for formatting. Also, don’t use JavaScript, as major email clients don’t support it.

Though it may seem obvious, remember that images and links within your HTML email need to be full, absolute paths to their world wide web accessible location. No relative links!

Here’s another PHP function I cannot live without - I add this into my standard PHP functions include on all projects. Often when displaying text, I am forced to abbreviate the text to a certain number of characters. You might jump in a decide to use substring() on your text to achieve this abbreviation, but that can cause several problems. The most blatant is that you will often split the text right in the middle of a word. In addition, if there are any HTML tags in the text, they could get cut in the middle too, or have the closing tag left off completely, potentially breaking the display or exposing the remaining part of the tag.

As a solution to these problems, I have written a function that only trims on the last space before the number of characters you specify, so it will never cut words in half. Also, it strips out HTML tags before doing the character trim, preventing possible display issues. And, as a convenience it adds ellipses (the …) to all trimmed text, as a visual cue to the reader that the text has been abbreviated.

<?php
/**
 * trims text to a space then adds ellipses if desired
 * @param string $input text to trim
 * @param int $length in characters to trim to
 * @param bool $ellipses if ellipses (...) are to be added
 * @param bool $strip_html if html tags are to be stripped
 * @return string 
 */
function trim_text($input, $length, $ellipses = true, $strip_html = true) {
	//strip tags, if desired
	if ($strip_html) {
		$input = strip_tags($input);
	}
 
	//no need to trim, already shorter than trim length
	if (strlen($input) <= $length) {
		return $input;
	}
 
	//find last space within length
	$last_space = strrpos(substr($input, 0, $length), ' ');
	$trimmed_text = substr($input, 0, $last_space);
 
	//add ellipses (...)
	if ($ellipses) {
		$trimmed_text .= '...';
	}
 
	return $trimmed_text;
}
?>

Having a secure area to a PHP site is a common website requirement. Implementing the secure area, on the other hand, can be difficult and confusing. I’ve put together a basic security framework that you can use for your PHP based website.

What this framework is:

• Simply coded & easy to understand
• Secure enough for most sites, blogs, and internally accessed (intranet) sites.

What this framework is NOT:

• Secure enough for sites involving e-commerce transactions and sensitive personal information.

Note the “NOT” clause above - this implementation is not for securing sensitive data. Most people implementing this framework will be doing it on unsecure sites (sites NOT using the HTTPS secure socket layer), causing user passwords to be sent from script to script in plaintext, which is vulneable to intrusion.

How the PHP security flow works

This framework works as follows:

• User submits login form containing name and passsword to login processor script
• Login processor form compares name and password to stored value
• If name and password do not match expected value, send user back to login form
• If name and password match expected value, set a session variable containing a unique hash value, and forward user to secure page

When a user tries to access a secure page, this happens:

• Security code checks session variable with user hash and compares to expected value.
• If the hash values match, continue displaying page.
• If the hash values do not match, send user to login form.

Seems simple right? It is! To implement the above workflow you’re going to need to use the code I have included below.

Login Form

Below is the login form code. Note that you must set the destination of the form to match the name of your check login script (login processor.)

<?php
/*
* FILE: login.php
*/
?>
<html>
<head>
  <title>Login</title>
</head>
<body>
  <form name="login-form" method="post" action="check_login.php">
    <p>User: <input type="textfield" id="user" name="user"/></p>
    <p>Password: <input type="password" id="pass" name="pass"/></p>
    <p><input type="submit" name="Submit" value="Submit"></p>
</form>
</body>
</html>

Login Processor

The login processor has the main chunk of your security code. This is the script that decides whether you have a correct username and password, and what to do after logging in. Note that this code uses an include of login functions to accompish its purpose. These login functions are shown later in this article.

<?php
/*
* FILE: check_login.php
*/
 
session_start();
 
//include our login functions.
require('login_functions.php');
 
//retrieve post data
$user = trim($_POST['user']);
$pass = trim($_POST['pass']);
 
 
/*
* Basic Login Logic
*/
 
clear_login_state();
 
if (!empty($user) && !empty($pass)) {
 
  if (check_login_correct($user, $pass)) {
 
    //set appropiate session vars
    login_user($user);
 
    //redirect to secured page
    send_to_page('secure_page.php');
  }
  else {
    //wrong user or password supplied, send back to login
    send_to_page('login.php');
  }
}
else {
  //no user or password supplied, send back to login
  send_to_page('login.php');
}
?>

Login Functions

The above Login Processor code uses some important functions to accomplish the secure login. These functions are enclosed in their own file and included by the above code.

<?php
/*
* FILE: login_functions.php
*/
 
function check_login_correct($user, $pass) {
  /**
  * This function is for you to fill in.
  * Typically, you would compare the user's password 
  * to the password stored in the database, and then return
  * either true or false, depending on the result.
  */
 
  if ($user == 'admin' && $pass == 'Chelsea') { return true; }
 
  return false;
}
 
function login_user($user) {
  session_regenerate_id();
 
  //set the user session variable, for later app use
  $_SESSION['user'] = $user;
 
  //set the hash session variable
  $_SESSION['hash'] = calculate_secure_hash($user);
}
 
//function sends the user to a page. Note this must be called 
//in the header, before any page output (echo's, html, print, etc) 
function send_to_page($page) {
  header("Location: $page");
  die("Redirect Failed");
}
 
//clears login state (logs you out) by unsetting login variables
//must be called in header, before any page output (echo's, html, print, etc) 
function clear_login_state() {
  session_unset();
}
 
function calculate_secure_hash($user) {
  //the security of your system is based on the hash seed below - change often
  $hash_seed = 'this_is_a_secret';	
  return md5($_SERVER['HTTP_USER_AGENT'] . $hash_seed . $user);
}
 
function check_logged_in() {
 
  //retrieve session vars
  $found_hash = $_SESSION['hash'];
  $user = $_SESSION['user'];
 
  //must not be empty
  if (!empty($found_hash) && !empty($user)) {
 
    //recalculate the hash
    $calculated_hash = calculate_secure_hash($user);
 
    //if recalculated hash matches, we have a logged in user
    if ($calculated_hash != $found_hash) {
      send_to_page('login.php');
    }
  }
  else {
    send_to_page('login.php');
  }
}
 
?>

Secure Page Code

Okay, so we have successfully logged a user in - now what? Well, for each secure page accessed you have to reverify the hash value. On each secure page, you’re going to need to setup the top of your page (PHP script) like this:

<?php
/*
* FILE: secure_page.php
*/
 
session_start();
 
//include our login functions.
require('login_functions.php');
 
//do security check
check_logged_in();
 
//now, display the page's content...
echo "You are viewing a secured page!";
 
?>