Web Site Cookbook | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The process of designing a web site does not start in Photoshop, Dreamweaver, or your favorite text editor. Before the first line of code is written and the first image is optimized, a web site must have a home on the Internet and a virtual provenance of sorts that legitimizes its existence along with the millions of sites that have come before. Web sites must have a domain name, as well as disk space on a web server, to join the ever-growing club of online resources. In this chapter, we'll untangle the choices that confront web site builders during the process of getting a new web site off the ground.

You need to register a new domain name for your web site.

Choose the right domain name and registrar for your web site after weighing factors such as budget and goals for organizational identity.

Choosing a new domain name for a web site can often seem like shopping on the last day of an end-of-season sale at a popular clothing store. The best choices were long ago snapped up by the early shoppers. Like a picked-over pile of extra-small beige golf shirts, the remaining choices may not be a perfect fit for your planned web site.

Check the registrar of your choice to see if the domain name you want is already registered. Assuming for a minute that you will not be able to acquire your first choice (or second, or even third), here are some guidelines to consider when registering a brand new domain name:

Consider using your company or organization's short branding message or marketing slogan as your domain name. For example, if Wal-Mart's deep pockets and legions of lawyers were not able to wrest ownership of walmart.com from a hypothetical cyber squatter, they might consider alwayslowprices.com an acceptable alternative.
Try to come up with an action-oriented phrase or common aphorism that dovetails with the mission of your web site, and build your web site around that domain. For example, a site that promotes good health through good diet might register

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The process of designing a web site does not start in Photoshop, Dreamweaver, or your favorite text editor. Before the first line of code is written and the first image is optimized, a web site must have a home on the Internet and a virtual provenance of sorts that legitimizes its existence along with the millions of sites that have come before. Web sites must have a domain name, as well as disk space on a web server, to join the ever-growing club of online resources. In this chapter, we'll untangle the choices that confront web site builders during the process of getting a new web site off the ground.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to register a new domain name for your web site.

Choose the right domain name and registrar for your web site after weighing factors such as budget and goals for organizational identity.

Choosing a new domain name for a web site can often seem like shopping on the last day of an end-of-season sale at a popular clothing store. The best choices were long ago snapped up by the early shoppers. Like a picked-over pile of extra-small beige golf shirts, the remaining choices may not be a perfect fit for your planned web site.

Check the registrar of your choice to see if the domain name you want is already registered. Assuming for a minute that you will not be able to acquire your first choice (or second, or even third), here are some guidelines to consider when registering a brand new domain name:

Consider using your company or organization's short branding message or marketing slogan as your domain name. For example, if Wal-Mart's deep pockets and legions of lawyers were not able to wrest ownership of walmart.com from a hypothetical cyber squatter, they might consider alwayslowprices.com an acceptable alternative.
Try to come up with an action-oriented phrase or common aphorism that dovetails with the mission of your web site, and build your web site around that domain. For example, a site that promotes good health through good diet might register anappleaday.com.
Try adding your city, state, or other local identifier to your already-taken first or second choice to find an acceptable alternative that you can claim for your own, such as austinwebdesign.com or youngstownyoga.com.
Avoid using hyphens and long acronyms in your domain name. You might be tempted to register an alternative domain name by tweaking your already-taken first choice with hyphens between key words, or by reducing your business name to an alphabet-soup acronym of unrelated letters. Don't do it. A fair share of your potential site visitors will trip over these grammatical stumbling blocks, leaving your web site lost in cyberspace. For example,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to protect the investment you made in a domain name for your web site.

Learn how the domain registration system works and keep your domain from being neglected or stolen by:

Knowing the expiration date
Keeping contact information up to date
Enabling domain security features
Choosing a strong domain management password
Registering your domain name as a trademark
Reading every email your registrar sends to you carefully
Consolidating multiple domains
Registering domain name variants
Using a domain-name monitoring service
Planning ahead if you move your domain to another host
Setting up a third-party, backup DNS service

When comparing a web site to a car, as in Recipe 1.1, you should take into account one key distinction: cars depreciate in value the more you use them. But once you build a functioning web site at your domain—with growing traffic and name recognition—that domain becomes many times more valuable to you than the nominal fee you paid to register it. For that reason, you should treat your domain name as a valuable asset to your business or organization.

The process of choosing a registrar, name service, and hosting provider can be complicated considering all the overlapping options that a web site builder must sort out before making a decision. But the process of losing a domain name can be deceptively simple—with the emphasis on deceptive—and can happen right under the nose of the careless domain name owner.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to narrow down the myriad web hosting choices to the best one for your web site.

First, consider which web server software and platform your site will be built on; open source Apache and Microsoft's Internet Information Servers (IIS) are by far the most common, although a handful of other web server applications offer special options for companies with particular web site needs. Then think about what features you may need—such as an e-commerce platform, SQL database, secure shell access, or phone-based tech support—to determine whether you should pay for a third-party hosting service or become your own webmaster and host the site yourself.

Ten dollars a month will buy you a lot of web hosting, and $100 a month will buy you more than you ever knew you needed. Free hosting is worth just a little less than what you pay for it. And hosting your own site, especially if you've got real work to do, may ruin what little love for computers you may have. Before you let your cousin Mickey host your site from the server farm in his basement or jump at the first web hosting deal you find, spend time doing some long-range planning about how your web site may grow and change.

About 85 percent of the sites on the web these days are running either Apache, an open source and free descendant of the httpd code that served the first web pages, or IIS, a commercial application from Microsoft that is built into server versions of Windows. The rest of the web is covered by lesser-known server software such as Lotus Domino from IBM, Netscape Enterprise Server, Zeus, and StarNine's WebStar (among others).

Rather than present a biased pro and con of the two leading choices, here are some neutral observations and facts about Apache and IIS:

Large corporations overwhelmingly favor IIS for their web sites.
Apache has about 70 percent of the total web server marker, according to Netcraft.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to display the contents of one or more shared files in the body of your web pages.

Configure your web server to parse include tags for all files, or rename your files using the server-side include (SSI) friendly suffix for files that will be parsed.

A typical web server installation will have the module for parsing SSI tags enabled by default. If you have the ability to open and modify your Apache configuration file, check to make sure the following two lines are not commented out.

The location of Apache's configuration file—httpd.conf—is set at installation. The default location is /etc/httpd/conf/httpd.conf. A commented, or inactive, line in the configuration file is preceded by a pound sign (#).

The two lines you're looking for should be near the top of the file:

	LoadModule includes_module libexec/httpd/mod_include.so

and:

	AddModule mod_include.c

Any change you make to the file will require a web server restart to take effect (see Recipe 1.9). A file's suffix determines if it is eligible for parsing. Typically, files ending with .shtml are parsed for includes, but files ending with the more familiar .html will not. Since most web page editors create files ending in .html—and most visitors to your site will assume that pages on your site end with .html—it's a good idea to stick with that naming convention and enable SSIs on .html files, too.

Now, go back to the Apache configuration file, where you should find two lines together like this:

	AddType text/html .html
	AddHandler server-parsed .shtml

On that second line you want to add ".html" so it reads like this:

	AddHandler server-parsed .shtml .html

If you don't have access to the master configuration file, you can still change the way Apache parses the files for your site with an .htaccess file. Just create the file in your web site root directory and paste in the first and third lines of code above, like this:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to tell your web server the name of the default page for a given directory or all directories on your web site.

Add or modify the DirectoryIndex entry in your httpd.conf file, or a specific direc-tory's .htaccess file. List the files that should be treated as default pages in the order you wish them to be served:

	DirectoryIndex index.php index.html index.htm index.php3 welcome.html

When a visitor to your web site requests a URL without a specific filename—say, http://yourwebsite.com/news/—the web server needs to decide which page to send back to the browser. The file can have any name, and be a static file or one that is dynamically generated. Regardless of how the file is created, if it's missing when requested, then your visitors will see an ugly list of every other file in the directory or, worse, a 403 Forbidden error telling them they don't have permission to access the directory.

For more about denying auto-indexing of a directory, see Recipe 5.5.

As you saw in Recipe 1.4 on server-side includes, the setting that determines the name of a directory's default page resides in the main Apache configuration file, and may be overridden by an .htaccess file. Apache configuration changes listed in an .htaccess file apply to all of the files in the same directory and to all of the files in subdirectories below it that don't have their own .htaccess file.

The line to look for in the configuration file—or to add to an .htaccess file—looks something like this:

	DirectoryIndex index.php index.html index.htm index.php3 welcome.html

The setting can contain more than one default file option, listed in descending order of priority. In this example, the server will look for index.php first, then index.html, and so on down the line.

Recipe 1.4 on using configuration files to enable SSIs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to make sure that your web site can be accessed both with and without the "www" prefix.

If your web site won't load without the "www" prefix—or it won't load with "www"—then you may need to make a change to your DNS record. Some hosting providers allow customers with higher end accounts to change their own DNS records, but use caution if your account includes this feature and you're not sure what you're doing. If you're in doubt, contact your hosting company for clarification or guidance.

If you have access to the command-line network tools nslookup or dig, either on your own PC or through a Telnet shell provided by your hosting account, you can investigate the details of the various listings in your DNS record without changing them. Some web-based tools (see the "See Also" section in this Recipe) can access the same DNS record information if you do not have access to dig or nslookup.

In the example below, a dig request on www.daddison.com shows it to be a CNAME, or canonical name, listing for daddison.com. A CNAME listing is an alias to the main, or A RECORD, listing in the domain name's DNS record. Requests for either web site address—with or without the "www"—are answered with my web site:

	Lookup has started …

	; <<>> DiG 9.2.2 <<>> www.daddison.com any
	;; global options: printcmd
	;; Got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40212
	;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

	;; QUESTION SECTION:
	;www.daddison.com. IN ANY

	;; ANSWER SECTION:
	www.daddison.com. 3600 IN CNAME daddison.com.

	;; AUTHORITY SECTION:
	daddison.com.     3600 IN NS ns22.pair.com.
	daddison.com.     3600 IN NS ns0000.ns0.com.

	;; ADDITIONAL SECTION:
	ns0000.ns0.com.   7110 IN A 216.92.61.2

	;; Query time: 98 msec
	;; SERVER: 151.164.20.201#53(151.164.20.201)
	;; WHEN: Wed Apr 20 15:50:18 2005
	;; MSG SIZE rcvd: 113

In the classic 1963 farce "It's a Mad, Mad, Mad, Mad World," an all-star cast from Hollywood's Golden Age raced against each other to find a treasure hidden under a big "W." In the late 1990s, during the Internet's first (we hope) Golden Age, legions of dot-com entrepreneurs also sought riches, in this case, under "www." With the wisdom of hindsight—and perhaps with a renewed appreciation for the farcical and tongue-tying nature of hyper-alliterative repetition—many web sites now present themselves on the World Wide Web

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to place some files out of the reach of HTTP requests.

Put your web pages in a directory one level below your login's home directory and create and use directories at the same level as the "web root" to hide private files.

I'm always a little annoyed when I FTP or Telnet into a new client's web server for the first time and find that the home directory for the hosting account and the root directory for the web site are one and the same. Such setups are typical of basic hosting accounts and likely keep tech support calls to a minimum by eliminating the need for novice and do-it-yourself web designers to remember file paths on the web server when uploading their web pages. Just FTP into your web server and the site files are right there in front of you.

In these bare-bones web site setups, any file that gets uploaded to the hosting account home directory, or that is created by an automated process on the web site, can potentially be viewed and downloaded over the web. Sensitive or restricted data can include files containing your weblog, email list, or credit card merchant account passwords, database login information or backups, downloadable files that are only made available to authorized site visitors, auto-generated order logs containing confidential information about your online customers, or future versions of important pages on your site to be published at a later date.

Restricted file permissions and password-protected directories are among the other popular methods of keeping private files out of reach of browser requests. But keeping files in a directory that's not even part of your web site (password protected or not) makes worrying about unauthorized web access unnecessary.

First, you'll need to relocate your web site's root directory with a few Apache rewrite rules placed in an .htaccess file, a technique first encountered in Recipe 1.6. You can start using this technique with either a new or existing web site. The changes will be immediate and transparent to your visitors.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to publish or change files overnight while you're sleeping.

Use your web server's built-in task scheduling utility, cron, to do the work for you.

Web designers like their sleep just like anyone else—maybe more. The last thing any of us want to do is stay up late or get up early to post new information on a web site according to the boss or marketing department's schedule.

Fortunately, Unix-based web servers come with a built-in task-scheduling utility called cron that can do everything from executing simple file operations—like copying an updated web page from a private directory to a public one—to running complete scripts with instructions for more complex site maintenance routines. Let's look at the basics of cron and how you can use it to do simple site updates when you're otherwise busy having a life.

Say, for example, that your company's public relations department is working on an important news release for a new product announcement. The release is embargoed (held back from public view) until Wednesday morning, but they give you the final text of the release on Monday to build a page for the web site. The PR department wants the release to be posted on the site at 6:00 a.m. Eastern Standard Time, but your office is in Denver—two hours behind the East Coast—and you plan to be watching the back of your eyelids at that time. It's cron to the rescue!

First, create the updated web page (newsrelease.html) and upload it to your web server. If you're feeling lucky, and don't think that URL-fishing site visitors or Google will find the page before the embargo date, put the new page in a new public directory on your web site. If you're worried about your job security, you're paranoid, or both, put the file in a directory that is password protected, hidden, or outside the root web site directory on the server. Either way, cron will be able to find and move the file when the time comes.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to restart the HTTP daemon that processes requests for web pages on your server.

At the command-line prompt for your server, issue the apachectl graceful command, or the appropriate restart command for your web server.

Restarting your web server has come up in several of the topics covered in this chapter. When you modify the configuration file for Apache, you have to restart it for any changes to take effect.

Basic webhosting accounts usually share Apache server processes with other web sites, so if that's the case with your web site, your provider may not want or allow you to restart Apache. Web designers with higher priced virtual server accounts, or accounts running on a dedicated server, have Apache all to themselves and usually can issue the commands for stopping and starting it as needed.

Later versions for Apache install with a control script called apachectl. With it, you can start, stop, and restart the HTTP daemon on your dedicated server or "virtual server" account.

Finding the script

You should be able to use apachectl at the command-line prompt to your web server by typing its name followed by a space and stop, start, or graceful. If that does not work, you will have to specify the full path to the script. To locate the script on your server, use one of these commands:

	find / -name apachectl

or:

	which apachectl

Stopping and starting Apache

The results of the commands apachectl stop and apachectl start are self-evident.

The stop command immediately turns off the server, cutting off connections that may still be in the process of downloading pages from your web site.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to see programs your web server is running and user requests for web pages.

Use command-line tools to get a real-time snapshot of web server activity:

tail: Returns the last part of a file, such as most recent connection entries from the web server logfile
grep: Searches for a pattern in a file, such as specific filenames or error codes from the web server logfile
ps: Reports on the status of web server processes

Almost any decent web hosting account will record connections to your web site in logfiles that you can view and process. A good hosting provider may even help you automate the task of purging the connection records—or log rolling—so the files do not consume your account's disk quota, and give you access to web site statistics software, such as Analog or Urchin, that will generate easy-to-read reports about activity on your web site.

If you're serious about your web site, then you should take advantage of the tools available to you and review web site traffic reports often to understand how visitors get to your site, what's popular, and what's working (or not working). How to look at and use web site traffic reports is covered in Recipe 9.9.

The access and error logs that provide the raw material for traffic reports are constantly updated. Traffic reports themselves, on the other hand, are usually generated less frequently—daily, or even weekly, in some cases. A situation may arise when you can't wait for the next traffic report to be created. You need to get an up-to-the-minute picture of the who, what, and how many of your web site's current activity. Here are some command-line tools you can use to take your web site's pulse.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to set up a small web site and are willing to sacrifice some customization options in favor of saving money and getting it online quickly.

Employ a combination of free or inexpensive resources available on the Web to build a low-cost site that's easy to maintain. The ingredients for this Recipe are:

A domain parked at a registrar that allows you to forward requests for the domain to another URL
A small amount of free hosting space provided by your internet service provider, school, employer, or other reliable web server operator
One or more blogs hosted by Blogger (or another free blogging service)
A free Flickr account for storing and sharing images you want to display on your site
A free del.icio.us account for managing links on the site, including its navigation
A Google-based site search form

Although the rest of this book is devoted to in-depth solutions for building a substantial, highly customized web site, there are times when you need to get something online fast, cheaply, and under control. Fortunately, a slew of free or inexpensive web services have become available recently (some referred to under the banner of Web 2.0) that make doing so fairly easy.

As I explained in Recipe 1.1, web sites start with a domain name. Expect to pay $5 to $10 for a one-year registration, although you may find a cheaper deal for a domain in one of the newer top-level domains (such as .info or .biz) if you shop around. For this Recipe, I registered the domain dougaddison.info at GoDaddy.com (http://www.godaddy.com). When choosing a registrar for the site, make sure you can "park" the domain on their DNS servers for free (or a nominal fee) and forward requests for the domain to another URL. In addition to free parking and forwarding, GoDaddy also lets registrants "mask" the forwarded domain, which means that the browser location window will always display the domain name (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

By the time your web site launches you might finally be ready to let your visitors (collectively) start thinking about the site more than you have been. That's why a good web site starts with good planning. While it's tempting to start designing and coding right away, the more complex your project, the more you'll benefit from written documentation that helps you set a course for the work ahead of you. Planning can take various forms: the functional specification demands answers to questions such as who will use the site and what they will do. A flowchart helps smooth out an online transaction or process. Setting up and following specific coding standards for seemingly minor site details—page titles, file and directory names, and variables—provides a consistent experience on your web site. All together, these practices ensure that the web site you launch will be useful and enjoyable for the people who visit.

Before we begin, a warning to readers: this chapter is heavy on explanations and light on code. Although you might prefer to skip to a more code-oriented chapter, I urge you to study the Recipes in this chapter to understand why this early stage is critical. Good web site builders (many of whom learned the hard way) know that it's a waste of everyone's time and money to spend days writing great code, only to find out that it does all the wrong things.

You need to determine the purpose and goals for your site.

Write a functional specification that describes a road map for creating an online experience and get all the stakeholders interested in your web site's success to read the spec, approve it, and follow it.

A functional specification document can vary from a two-page outline for a small, quick turnaround web design project to a lengthy, multipart treatise for a complex web application. Regardless of the size and scope of your project, a functional specification for a web site should:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

By the time your web site launches you might finally be ready to let your visitors (collectively) start thinking about the site more than you have been. That's why a good web site starts with good planning. While it's tempting to start designing and coding right away, the more complex your project, the more you'll benefit from written documentation that helps you set a course for the work ahead of you. Planning can take various forms: the functional specification demands answers to questions such as who will use the site and what they will do. A flowchart helps smooth out an online transaction or process. Setting up and following specific coding standards for seemingly minor site details—page titles, file and directory names, and variables—provides a consistent experience on your web site. All together, these practices ensure that the web site you launch will be useful and enjoyable for the people who visit.

Before we begin, a warning to readers: this chapter is heavy on explanations and light on code. Although you might prefer to skip to a more code-oriented chapter, I urge you to study the Recipes in this chapter to understand why this early stage is critical. Good web site builders (many of whom learned the hard way) know that it's a waste of everyone's time and money to spend days writing great code, only to find out that it does all the wrong things.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to determine the purpose and goals for your site.

Write a functional specification that describes a road map for creating an online experience and get all the stakeholders interested in your web site's success to read the spec, approve it, and follow it.

A functional specification document can vary from a two-page outline for a small, quick turnaround web design project to a lengthy, multipart treatise for a complex web application. Regardless of the size and scope of your project, a functional specification for a web site should:

Identify the audience
State the goals of the web site
Establish a method for measuring success
Define interaction points
Describe the site both textually and visually
List key decisions to be made
Identify and assess similar sites
Outline a schedule
Provide a guide for testing

Most of your web site projects will benefit from some kind of blueprint to guide your work and manage the expectations of those for whom you're working. A functional specification document can do just that. By unifying the needs of users, the capabilities of available technology, the vision for a new site's look-and-feel, and the business needs of those who are paying the bills, a functional spec makes a web site project go much more smoothly than a project that proceeds without one. For web site builders at the crossroads of these oft-competing interests, a functional spec offers a useful tool for avoiding "feature-creep" along the way and deflecting criticism and complaints when the project it defines is complete.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to compile a list of documents, images, and other source files that you will need in order to build a site.

Create a content inventory or checklist to determine what text, images, and other assets are available and need to be part of the site. Your list should answer these questions:

Who has the original materials?
What formats are the materials in?
Who will acquire, create, and approve the new material?
What has to be resized, edited, or optimized for online use?
How often will content be updated, and by whom?

Compiling a content inventory, like writing a functional specification (detailed in Recipe 2.1), is a key step in successfully making your web site concept a reality. But these two tasks can create a "chicken-and-egg" dilemma for a web designer. By that, I mean it's hard to devise a navigational structure for the functional specification without a clear idea of the available content—and you might not know what content you'll need without knowing how the site will be organized.

You might want to integrate the two tasks so one informs the other. That way, a content inventory can help refine the decisions and responsibilities identified by the functional specification. That said, you'll want to be careful not to let the complete opus of available material dictate how to structure a site. Don't feel compelled to shoehorn every company newsletter article and holiday party photo into the site. It's almost always easier to add content than take it away (see Recipe 9.1).

Like the functional spec, a content inventory is a tool for managing expectations and developing a schedule for completing a web site project. Table 2-1 shows a list of a few of the typical

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need a plan for putting site assets in their proper place, so you and others who work on the site can easily find and update the right file at a later date.

Group your files by content, method of creation, and access level, and then create directories on your web server where they can be uploaded and modified as needed.

From a command-shell prompt, you can create a directory with the Unix mkdir command. A full-featured FTP client or WYSIWYG site management applications should offer a menu command for creating directories on a remote server as well.

Don't build a site where every file commingles with every other file in an unorganized mess at the top file level of your web server. Well-planned web site organization requires a lot of advance planning, but pays dividends as your site grows and changes. Try to mirror your web site's navigation—the links and buttons that visitors follow through your site—but keep in mind some of the limits of the server file system as you do.

Unlike the folders you create on your desktop PC, web site directory names should not contain spaces. The server will convert spaces to the unaesthetic (but not unusable) encoding %20. Likewise, avoid special characters: The server might mistake ampersands (&) and questions marks (?) for delimiters in a CGI script argument; the number (or pound) sign (#) is used in HTML markup to create a link to another section of the same web page. Hyphens and underscore characters are safe, but—as you saw in Recipe 1.1—they add an unnecessary stumbling block to people trying to memorize a URL or recite it over the phone. Best to leave them out, if possible. Finally, use all lowercase; on Unix servers, the directory and filenames that make up a URL are case sensitive.

Every site should have separate directories for the supporting files that are not linked to directly on your site, such as GIFs, JPEGs, and PNGs (in /images), server-side includes (in

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to name web page files so they convey meaningful information to your visitors—as well as you and others who work on the site.

Web server file naming should follow the same guidelines discussed in Recipe 2.3: you should avoid spaces and special characters, use other punctuation sparingly, and keep them all lowercase. Unlike a web site directory—whose primary, if not only, purpose is to organize and contain site files—the files themselves are on the site for a variety of reasons. A one-size-fits-all naming scheme won't work. The right way to name a downloadable PDF file differs from the right way to name a GIF file of the site logo because the two files have different purposes.

Despite their differences, all the files on your site should have names that:

Have a valid file extension, such as .html, .gif, or .pdf
Convey something about the source, contents, or nature of the file
Follow a logical and consistent scheme across similar files

The various files on your site come together on pages, the Web's most basic building block. As files themselves, your HTML pages have filenaming requirements depending on where they exist in the site structure. I'll cover some of those issues first, and then address some additional guidelines to consider when naming supporting files such as images and downloads.

Index pages

As its name suggests, the index page offers an overview of the contents of the directory and provides links to the other pages in it. If a directory of files requires a main page, call it index.html. Although it's possible to modify or override the server's configuration to use an alternate filename for the main page in a directory or entire site (see Recipe 1.5), you should employ this technique sparingly. Don't set up custom directory home pages that reiterate the directory name—for example

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to give meaningful and reliable titles to your web pages so they are easily distinguished from one another in search results and browser history lists.

Set up a scheme for formatting the content that goes between the <title> tags in your web page code and follow it throughout your site. The title goes in the head section of the HTML code, like this:

	<head>
	…meta tags…
	 <title>page title information</title>
	…CSS styles and other head content…
	</head>

Other guidelines to follow include:

Maintain a consistent format.
Use specific language.
Make page titles unique.
Keep page titles brief.

The page title is one of the most important and overlooked web page elements. Often without knowing so, web surfers use page titles to get to your web site and move around on it once there. In general, page titles are the linked text that appears in a list of search results (see Figure 2-6). They're also used to keep a running archive of recently visited pages, available through a browser's History or Go menu.

Web designers often neglect writing a useful (or any) page title for a variety of reasons. First, they may be focused on the content and design of a page's main section, and, after completing that, they forget to go back and add a page title. Likewise, their web page editor may have a default page title such as "Untitled" or "Designed with Adobe GoLive," but this title is just as useless as having no title at all, if it doesn't get changed to something more meaningful. Second, many content management and shopping cart systems do not provide a way to give unique page titles to dynamically generated pages, so every page gets created with the generic "Article" or "Catalog Item" page title.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to follow a dependable pattern for naming variables in your web site scripts.

Develop coding guidelines that make sense to you, your team, and your web site, and then stick to them.

In general, a good variable naming scheme:

Uses unique, concise terms
Limits abbreviations
Avoids reserved words in its programming language
Serves as a form of self-documentation

Variables are used to store alphanumeric values that will be manipulated by a script or program. Variables can have a constant value defined permanently in the code, or be changed from one value to another through logic or input from a user.

For example, a PHP script might take a Fahrenheit temperature value entered on a web site form (call it $temp), perform a calculation on the variable to convert it to Celsius, and then echo the same variable (with a new value) back to the user.

The variable name $temp has several disadvantages (that's why I chose it). As a generic abbreviation for temperature, $temp easily could be misconstrued as representing a temporary value (or the user's temperament) by another programmer reviewing the code.

If you find that you have to use abbreviations or shorthand for your variables, compile a glossary and add it to a central comment block in your script.

While the name $temp meets the simple needs for a hypothetical temperature converter, it becomes woefully inadequate as soon as you try to add other functionality to the converter. Say, for example, that you improve the script to accept two temperature values from a user—the current indoor temperature and the current outdoor temperature. Which one of the two should be $temp

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to create a backup, mirror, or offline copy of your web site.

Use the Unix utility wget to mirror the files on the server to another location either by HTTP with this command:

	wget --mirror http://yourwebsite.com

or by FTP:

	wget --mirror ftp://username:password@yourwebsite.com

Alternatively, you can use GUI-based utilities on your PC. Some choices are listed in the "See Also" section of this Recipe.

With wget, you can perform heroic feats of webmastering, whether it's copying a single file from one site to another, or an entire site to another server.

When spidering a site over HTTP, wget will only copy files it finds links to. Unused images and old web pages still lingering on the server will be skipped. Using FTP, wget will copy everything.

Some scenarios where wget can be indispensable include:

Keeping frequently updated pages or images in sync on two sites: Say you want to display a real-time webcam image on your site, but don't want to (or can't) use an absolute URL to the site where the camera saves the image in the image tag's src attribute. (Perhaps the other site's server is slower or less reliable than yours, or outside linking to the image has been disabled, as described in Recipe 5.5.) With wget, you can specify the URL of the file, a local directory on your server where it should be copied, and the number of times to retry a flaky HTTP connection. Combined with cron (see Recipe 1.8), wget can perform its connect-and-copy task as often as you (or your system administrator) want it to.
Setting up a mirror version of a site: Because wget

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to turn complex content management system, blog, or shopping cart URLs into easy-to-remember URLs.

Use mod_rewrite rules in an .htaccess file to invisibly turn simple URLs into complex query strings that return dynamic pages to the visitor's browser. For example, an e-commerce site that sells men and women's clothes might offer a variety of men's shoes, such as boots, oxfords, sandals, and loafers.

A URL for the list of loafers might look like this:

http://mensandwomensclothes.com/store/list.php?type=mens&cat=shoes&subcat=loafers

Using rewrite rules, you can tidy up the URL to something like this:

http://mensandwomensclothes.com/store/mens/shoes/loafers/

A rewrite rule in the .htaccess file that you create or modify in the /store directory takes care of converting the clean URL to the more complex query string that the store template (list.php) needs to generate the list of loafers from the store database. Here's the code for the rewrite rule:

	RewriteEngine On
	Options +FollowSymLinks
	RewriteRule ^(.*)/(.*)/(.*)/$ /store/list.php?type=$1&cat=$2&subcat=$3

Assuming the mod_rewrite module has been compiled into your installation of Apache (typically, it has), the first line (RewriteEngine On) prepares the module for the rewrite rule or rules to follow. The second line (Options +FollowSymLinks) can be left out if it's already in the main Apache configuration file (typically, httpd.conf).

The third line contains the rule. Three consecutive wildcard search patterns followed by a slash—(.*)/—match the structure of the simple URL. The patterns would match other clean URLS, too, such as …womens/skirts/mini/ or …mens/hats/ stetsons/. Note that the URL has to end with a slash (marked by the $ at the end of the search pattern) for a successful match.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to map out how visitors to your web site will interact with a complex form or tool.

Use the standard flowchart symbols (see Figure 2-7) to create a diagram for the web site process.

Figure 2-7: Common flowchart symbols for diagramming a process

Time to get out your No. 2 pencils. Although software such as Visio and OmniGraffle can make your flowchart look more presentable, the place to start is with a clean sheet of paper and your favorite erasable writing implement.

Wherever you have visitors signing up, logging in, checking out, or undertaking some other interactive endeavor on your site, your planning and implementation of the process can benefit from a flowchart. Flowcharts are all about improving communication: between you and the programmer who will implement the process and between your site and its users. A flowchart helps you visualize interaction points between visitors and the site and identify places in the process where error messages and other feedback are necessary. Include the flowchart in your functional specification document (see Recipe 2.1) to augment your textual descriptions of complex processes.

A visual example will help in this Recipe, too. Figure 2-8 shows a flowchart for the subscriber login process on a site I worked on a couple of years ago. The site already had a straightforward system for authenticating visitors: after data entered on a login form is checked against a list of valid subscriber accounts, the visitor gets the requested page, or an error message if the login information was incorrect. But the high cost of a subscription led to a lot of password sharing between subscribers and nonsubscribers. The owner of the site wanted the site to check the login information supplied by a user for other active sessions with the same login, and then let the new user kick the other user off the site. The site would allow only one active session per user—"second come, second served," so to speak.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Color, layout, and navigation are what usually come to mind when o

Table of Contents

Index pages