You Are Here: Home »Articles »   Writing Portable Websites

Writing Portable Websites (Part 1)

Introduction

Moving a website to a new domain or server can sometimes be work enough. Finding that it doesn't work as intended or simply doesn't work in it's new 'home' can be a complete headache. Granted, this can be down to differences in the server configuration that are beyond your control, but a little thought when creating your site can mean that if or when you need move domain, server or host, it can be a relatively painless experience.

Here we'll look at a couple of basic ways to plan for unforseen changes, in addition to making sure that these and also planned changes have a limited effect on your users.

Domains

We'll start with domain names and an example.

A friend once asked if I knew of a script that would run through each of their web pages and exchange a certain block of text for another (like notepad's 'replace' function) and I was curious as to why they needed to do this. The reason was that his web host had suddenly vanished, along with access to the sites domain they had registered on his belhalf, meaning his only real option was to register a new domain and upload the sites most recent backup to there. Problem was, at the time of writing the site, each of the pages links had been hard-coded with the domain name, eg: old-domain.com/page and with 30+ pages each hosting 10-12 links you can see the problem.

Obviously, the chance of this happening to you is slim, but you may need to migrate to another domain for other reasons and this is where PHP's constant variables can be useful.

Should I ever move netcode devbits to another domain, there are only three lines of code I need edit to ensure all links to pages within the site link to the new domain. These are held in a config file that's called into each page. They are three constant variables, one for the database, one for the default root server path and a third for the domain itself, which looks a little like this.

define('LOCAL_BASE_URL', 'http://devbits.net/');

This line basically assigns the value 'http://devbits.net' to the identifier LOCAL_BASE_URL, and any link within the site where the full domain is needed is then simply coded as:

<a href="<?= LOCAL_BASE_URL ?>" /></a>

Now should we need to move to a new domain, we can simply update the LOCAL_BASE_URL constant from the config file and don't need to painfully search each page for instances of the old domain.

Keep the complex stuff in one place

Another method to make your life easier when moving your site around, either within itself or to a new location is to keep the majority of your pages as simple as you can, by this I mean keeping away from the use of includes and functions in general pages.

This means when you want to duplicate or move content to another site, it's not going to be crippled by a missing funtion or page it's trying to call that's no longer there. Additionally, the less you have to edit the files that hold your main backend and complex code the better, as there's less chance you'll screw something up.

The tutorials, articles and many other pages here for example contain only plain text and some minimal formatting such as headers, paragraphs and 'pre' tags for code posting. All of this is just basic HTML so the pages could easily be uploaded to another site, maintain their format and be viewed without errors.

Errors & Logging

The bigger and more popular your site, the more relevance this will have, but knowing exactly where to find detail of what errors your site is generating and also knowing when a particular page or file was last changed can be a huge help when moving and updating your site, and also an advantage for general management.

Chances are you'll already have the ability to view errors such as database errors somehow, but these logs are not always easily accessible and often log vast amounts of minor errors or warnings that are not of huge importance. One option is to consider creating an error log and writing specific information to it from the selected scripts or functions you want to monitor for problems.

Here's a simple function, similar to one I use here for this exact purpose

function write_sql_error($error_text)
{
 # friendly message for the user receiving the error
 print "sorry! there was an error connecting to the database - please try later.\n";

    # I sometimes use this to print into the page source so I can view errors externally
    # don't uncomment unless you set your own $debug variable
    # if($debug) print "<!-- $error_text -->";

      # LOCAL_DOC_ROOT & LOCAL_DATE_FORMAT are constants I have set in a config file
      # replace with you own document root path and whichever date & time format you want to write into the log		 
      $log = fopen(LOCAL_DOC_ROOT.'/logfiles/error.log', 'a');
      fputs($log, date(''.LOCAL_DATE_FORMAT.'', time()). ': ' .$error_text. "\n");
      fclose($log);
}

We can then call the function in whichever database queries we choose

QUERY or die(write_sql_error('Failed Query To: database_name - '.mysql_error().' : '.mysql_errno().''));

Moving on to recording the last time a page was changed, more of a general site management tip but as I do a lot website management externally (simply browsing the site as a user would to find issues, rather than from 'inside' the pages) this has been very useful in the past.

A simple function for recording a pages last modified time you could call into any pages you choose

function last_mod() {
         # as with the logging fuction above, replace LOCAL_DATE_FORMAT with whichever date & time format you want
         print "\n<!-- Last Modified: ".date(LOCAL_DATE_FORMAT, filemtime($_SERVER['SCRIPT_FILENAME']))." -->\n";
}

Obviously, there's nothing stopping you printing this to the page itself for users to view rather than just in the source, useful in a list, project or something else that's updated often.

Don't destroy old links

This is more for the benefit of your users rather than you, but over time, it's almost certain that the design of your site will change in a way that means some old links no longer take you anywhere. For example, you may decide to move domain.com/about.php into domain.com/personal/about.php or domain.com/pics to domain.com/pictures

Eventually, the search engines will update their listing to the current version of your pages and the correct links, but that still leaves links that have been posted on other sites or forums, bookmarked by users or held in various cached files, so this is where you should consider the use of Apache's mod_rewrite function to ensure people never get lost or presented with an error whey they try to find a certain page.

A good way to check if people are making requests for your old pages and if so, which ones, is simply to check your site stats or error logs for detail of any 404 (not found) pages that have been served. Here are a couple of examples of entries from my .htaccess file that redirect requests for old page or file names to the current location

RewriteRule ^ref/(.*) resources/$1
RewriteRule ^tutorials/php/(.*) tutorials/php_mysql/$1

These simply redirect any requests for devbits.net/ref/something - The location for the reference pages in an older version of the site to devbits.net/resources/something - The current location for the resources pages on the site, and likewise, requests for the old tutorials/php folder to the current tutorials/php_mysql location.

If you're unfamilliar with the use of mod_rewrite or .htaccess files, take a look at the hotlinking tutorial which has the code to get you started.

Hopefully, this is a good starting point for you to make your site more manageable and prepare for the unknown. Additional ideas will be posted in future parts of this article.