|
|
Now that you have developed all the pieces of your site, you're ready to make sure all of those pieces work together. In this chapter we start testing your site; we'll upload it, and we will discuss ways you can verify your code. Hold on, we're about
to let the world view your work!
The first step in preparing to go online is to test your site in all three major browsers—Microsoft Internet Explorer, Netscape Navigator, and Spyglass Mosaic—before you upload it. Start from your home page (usually index.htm), and check out
each page one by one in your browser, making sure all your pages look good. Now, check your system twice more, using the two other major browsers. You are checking to make sure everything works and looks good, no matter what browser the viewer is using.
Note
Microsoft Internet Explorer is available at http://www.microsoft.com/ie/download/.
Netscape Navigator is available at http://www.netscape.com/comprod/mirror/client_download.html.
Spyglass Mosaic is available at http://spyglass.com/products/index.html.
If you want to ensure total cross-compatibility, you would also test your pages with older browsers and on different machines (such as Macintosh, UNIX, and so on).
Figures 19.1-19.3 are screen shots of the same HTML file in different browsers.
Figure 19.1. The HTML file in Microsoft Internet Explorer 3.0 (Beta 2).
Figure 19.2. The HTML file in Netscape Navigator 3.0 (Beta 5a).
Figure 19.3. The HTML file in Spyglass Mosaic 2.11.
You can see that this same HTML file looks very similar within the different browsers. This is difficult, but not impossible to achieve. If you have trouble with this, that's all right—just make sure that each page looks like a page you can be
proud of, no matter what browser the viewer is using.
Before you can upload your files, you must set up your FTP program. (We discuss how to set up CUTFTP—which is on your CD-ROM—in Chapter 4, "Your Domain," in the section titled "How to Use FTP to Post and
Update.")
Now, get online and upload your files (making sure you maintain your directory structure). If your site is contained within one directory, you can simply select all of your files within that directory and drag them over to your site. (See Figure 19.4.)
Figure 19.4. Uploading your site via FTP.
If you are using multiple directories for your site, you will first need to create that directory structure on your server. You do this in CUTFTP by pressing Control + M, typing the name of the directory (see Figure 19.5), and clicking OK. Then upload
each file to the correct directory on your server.
Figure 19.5. Creating directories on your server via FTP.
Now that your site is uploaded, the next step is to see if it works. Connect to the Internet, open your browser, and enter your site's URL. Check to see if all the links on your site work now that they are online. Now, check with the other browsers.
(This may seem repetitive, since you have just done this offline, but believe us, it's important.)
Here are a few of the most common problems you could encounter at this point:
Figure 19.6. Graphics won't load.
When your page appears but the graphics don't (see Figure 19.6), there could be a name problem or an upload problem. Make sure the graphics files are actually in the correct directory and that the filename (including the .gif or .jpg extension)
matches the one in your HTML tag exactly, including the capitalization. (Windows machines, for instance, are not case-sensitive, whereas Web servers are.)
If the problem persists, you may have an uploading problem (that is, the files may have been uploaded incorrectly). This is very rare if you are using CUTFTP, which automatically switches between ASCII and binary transfers. In some other FTP software,
however, you may need to manually select the transfer protocol. Graphics files use a binary transfer.
When all you get is the message File not found (see Figure 19.7), this most commonly means that you have misspelled the filename, or that the file is not in the directory. Check to make sure that your file is actually where it should be (if not, move
it or re-upload). If that doesn't do the trick, the problem is most likely your filename. Don't forget, filenames are case-sensitive, which is why it is a good idea to make all of your filenames lower case.
A special note to Windows users: The problem may be that your server does not accept the .htm extension. Either configure your server to accept this extension (or ask your host to do this for you), or rename your files with the .html extension. This
can be done from within CUTFTP by selecting the file, hitting Control + N, entering the correct filename (see Figure 19.8), and clicking OK.
This error message often says something like: "We are sorry to be unable to perform the method POST to non-script at this time." This means that the server did not recognize the referenced URL (the URL defined as the ACTION within the HTML
Form) as a CGI script. Make sure that your script resides in the correct CGI BIN directory, and that it has the correct extension to be used on your server.
Figure 19.9 shows a very common formatting problem, which is generally caused by one of two things: You forgot to add an ending tag (as in </BOLD>), or the ending tag is improper—you forgot one of the brackets, for example (as in
/BOLD>).
We get calls about this all the time. You make corrections and reload the file, and the file is still not fixed. This is a simple problem. It is caused by the browser keeping the file in local cache. (This most often occurs in older versions of
Netscape Navigator.) The simple solution to this is to clear your cache. This is done in Netscape Navigator by choosing Network Preferences in the Options drop-down menu, and clearing both the disk and memory cache, as shown in Figure 19.10.
Figure 19.10. Clearing your cache in Netscape Navigator.
Note
If you are uploading files to a UNIX system, you may need to perform a change mod on the file (usually CMOD 755). Consult your software information or system administrator about this.
So, now that you have checked out your site, and have fixed any visible problems, you probably think you can sit back and enjoy a cold one. Well, not quite yet. The next step (if you want to be really thorough) is to check out your site's HTML through
an online validation service, or with software developed for that purpose. These programs check your HTML code as only a machine can (in other words, much more thoroughly than we humans are capable of).
Tools to validate your HTML documents (check them for errors) are available. There are forms on the Web that hook up to specialized software and will check your HTML documents for errors. Some of these services even allow you to specify the HTML
version you are using. Here are some that we have found useful:
Figure 19.11. Doctor HTML, an HTML validation service.
If you would prefer to have the HTML checking software on your own system (for faster running), there is software available for this.
Some of the software programs we have found are
Then there are software programs that take another step in analyzing your site. Incontext WebAnalyzer (Figure 19.12) is a Windows program that identifies broken links or image references, as well as file information like size, modification date, URL,
and so on. It then compiles a comprehensive report (see Figure 19.13) that is tailored to suit your own needs; a demo version of this is included on your CD-ROM. Although this program does not check your HTML syntax, it can be very useful for checking for
broken links, as well as to give you an easily understood visual diagram of your site.
Figure 19.12. Incontext WebAnalyzer.
Figure 19.13. An HTML report generated by Incontext WebAnalyzer.
After you have uploaded and tested your system, it's a very good idea to back it up. We generally do this by downloading the files we just uploaded, and then saving them on a tape backup device. We then store this tape in a very safe place (like a
safety deposit box). This ensures that you have an exact copy of your site, and also allows you to use your existing copies for experimentation without the risk of losing everything.
If something can go wrong, it probably will (at least once). It is a really good idea to check your site personally at least once a week—better for you to find a problem than your customers, eh? Another option for keeping an eye on your server is
to use an alert service like Red Alert (http://www.redalert.com/redalert/home.html), which will notify you—via e-mail or through your pager—if there is a server problem (such as server
outage or a failed CGI script). (See Figure 19.14.)
Figure 19.14. Red Alert, a server checking service.
This chapter has covered the mechanics of getting your site online and running smoothly. We've discussed testing, FTP uploads, troubleshooting, and HTML verification. Welcome to the World Wide Web!
From here, we move on to explain the ways you can publicize your site. The next chapter addresses the issues of marketing in the real world and is followed by a chapter dealing with marketing online.
