Modular Website Design

Modular design is pretty much what it sounds like – designing code modules that can be reused multiple times (i.e., on multiple pages or even multiple sites). The most obvious modules that may come to mind are the site’s header, footer and sidebar(s) but as you become more comfortable coding in this style you will quickly see many other opportunities to use modular design.

The first thing to do before writing any code is decide on the site architecture. An architectural approach that has worked well for me includes the following directories:

  • root – index, favicon, robots.txt, “verification” files (e.g. for Google webmaster), sitemap.xml and any other files that must be in the root
  • images – self explanatory
  • includes – files that are called by other php files to accomplish some task (e.g. CSS, JavaScript, login, registration, DB setup/add/edit code, etc.)
  • admin – phpMyAdmin, and custom scripts to manage the site
  • stats – I used to use AWStats for traffic log analysis but you can use any program you find desirable. Most web hosting providers offer pre-installed stats programs which may or may not be sufficient but thanks to Google Analytics, this directory is becoming less necessary.
  • files – a place to store any files that you might want to make downloadable.
  • menu – if you use a menu system that consists of multiple files you might want to place them all in a distinct directory, though you could just as easily keep them in the includes directory.
  • rss – a place to store your RSS feed files.
  • miscellaneous directories – these are added as needed, usually for complete third-party scripts you wish to use (e.g. FCKeditor, phpAddEdit, phpList, phpBB, etc.)

With this approach, there is basically one main file, called index.php and all pages are accessed or created via that file, typically though a switch statement. As an example, assume we have a very simple three page site with the main page, an about us page and a content page. In this case, we might create a variable called $page and access each page like follows:

/index.php

/index.php?page=about

/index.php?page=content

Now, in our index.php code, we might do the following:

$page = $_GET["page"];

<header stuff here>

<sidebar stuff here>

switch ($subpage) {
   case "about":
       include("/includes/about.inc.php");
       break;
   case "content":
       <some code here to display content from a database, for example>
       break;
   default:
       break;
}

<footer stuff here>

There are some advantages to this approach. First, it is clean and easy to maintain since you will end up editing less files, oftentimes only the index file. Likewise it is pretty easy to add new pages. And, most importantly, it is very easy to change the look and feel of your site since the main look and feel elements (header, sidebar(s), footer) are all created in or included from the index file. You can even offer multiple designs customizable to a user’s preference if you wanted. Two potential downsides are that if you are working with a site that has many pages or the need for lots of code, the file could get a bit large, though I haven’t had that become a problem yet.[1] Second, as you need to do SEO work on URLs and/or pass more variables to certain pages, the coding required can get a bit more complicated. Still, I think the pros far outweigh the cons.

Speaking of SEO issues, many people want to keyword stuff their URLs and avoid pages that look like index.php?page=content&id=1. Fortunately, this can be easily accomplished via the redirect statement in an .htaccess file.


[1] For more info on page size, read the NetMechanic article, “Every Byte Counts (Towards Page File Size)” by Larisa Thomason.

Like this content? Why not share it?
Share on FacebookTweet about this on TwitterShare on LinkedInBuffer this pagePin on PinterestShare on Redditshare on TumblrShare on StumbleUpon
There Are No Comments
Click to Add the First »