by John Jung and William Robert Stanek
No matter how well documented FrontPage is or how proficient you are you're bound to run into problems. You can get around some of the problems by digging through the help files. You might even be able to get some help from Microsoft's Internet-based
knowledge base. Although you can find the information you're looking for, it could take a while.
As with most other Microsoft products, FrontPage comes with a rather extensive context-sensitive help file. To help you get used to the software, FrontPage even includes its own help file to help you learn about the product. Unfortunately, the help
files are broken into different components, some tied to each other. This ensures that that when you look up things, you'll come back to something you've already read. Unfortunately, this isn't always what you want. Sometimes you desire a different angle
on your problem.
The Microsoft FrontPage Editor is a very versatile WYSIWYG HTML editor. It can occasionally get a little confusing, especially to people new to FrontPage. The fact that FrontPage makes extensive use of the network frequently causes problems.
Fortunately, these problems aren't devastating and you can easily get around them.
If you started the FrontPage Editor by itself and not from the FrontPage Explorer, you could have a number of problems. One of the more significant ones is that it becomes extremely difficult for you to access any Web page on a local web. If you know
the full URL for the local Web page you want to work on, you can access it. Unfortunately, you won't be able to save any changes you make (see Figure 40.1).
Figure 40.1. The FrontPage Editor prevents you from saving the page into a nonexistent web.
This occurs because FrontPage doesn't know who you are. Consequently, it doesn't know what permissions you have. The best way to get around this problem is to start the FrontPage Explorer. When it's up and running, open the web where you want to save
the Web page. You have to enter your username and password to the system before you can access any pages. Finally, assuming you have the proper permissions for that web, you'll be able to save your work.
FrontPage enables you to create client-side image maps right on a Web page. Traditionally, image maps were implemented with a number of files that, when used together, made up the image map. The problem with this approach is that some Web browsers,
such as text-based browsers, couldn't handle image maps. People with slow Net connections who turned off the automatic image loading had the same problem. Client-side image maps implement image map capability from within a Web document itself.
Consequently, it is suddenly possible for everybody to access an image map. Chapter 10, "Enhancing Your Web Publication with Images and Image Mapsthe Easy Way," gives you more information about what image maps are used for and how to create
them.
If you're creating a client-side image map, it's possible that you won't see the clickable regions. Don't panic. All your hotspots are still in place; you just can't see them. When you put an image on your Web page, the FrontPage Editor suddenly has
two display modes: the Web page and the image map. The Web page display mode is shown when you click anywhere on your Web page outside an image. You can navigate through the Web page, and everything you do takes place on it. However, if you moved your
mouse cursor over an image map hotspot, nothing shows up. The image map display mode shows you the entire Web page as well, but all the links for the image map become visible. If you don't see any image map regions, simply click inside an image and
everything should be fine.
If you're designing complex Web pages, you probably want to add in form fields. Unfortunately, because form fields are rather complicated, it's possible that you might not get the results you want. Probably the most common problem you'll encounter when
working with forms is trying to put forms and text in the same line. By default, when you create a form field, FrontPage puts it on its own line as its own object. You can't move the form field object into another line with text or graphics. As a result,
it might not seem possible to put forms and text on the same line.
If you're faced with such a situation, don't despair. You can put in a form field on the same line as text. When you insert a form field, it isn't inserted into the document at the cursor location. It's inserted into the next blank line after
your cursor. If you want to add text before or after the form field, you must create the form field first. After that, you can position your text cursor in the form field region and type in the text you want. This method enables you to put form fields
before and after the text in the form field region.
The best way to minimize the number of problems you might encounter with the FrontPage Editor is to use the FrontPage Explorer. This Explorer takes care of a number of access problems you might encounter with the Editor. However, while you're getting
around some problems for the FrontPage Editor, you're getting new problems for the Explorer.
Suppose that you wanted to add something to a Web page on your web but can't. There are a number of problems that could be impeding you. First check to make sure that you have an account on the web. If you don't have an account on it, you'll have to
talk to your Web administrator or Webmaster. They can create an Web authoring account for you for the web in question.
If you already have such an account, make sure that you typed your username and password correctly. Also, make sure that you have an account for the web that you're trying to access. Just because you have an account on one web doesn't mean you have
access to all webs. This is true even if the two webs are being run from the same Web site. FrontPage enables Web administrators and Webmasters to restrict where Web authors can go. It's possible that you're trying to access a web that's off limits to you.
You might be unable to access a local web because Web authoring has been disabled. The Webmaster, or Web administrator, has the ability to disable authoring for a particular web. That's not to say that only the page you want to work on is disabled;
your entire web is down. If you're working in a group in a large company, it's possible that your group's web has authoring disabled. This isn't something to panic about because it's possible that the Webmaster is doing some maintenance on your web. He
might be upgrading the software or backing up the content.
One of the most common problems with the FrontPage Explorer is accessing Web pages outside your web. You'll encounter this problem when you try to have FrontPage Explorer verify all the links in your Web page. Unfortunately, if you run into this sort
of problem, there's very little you can do about it. In all likelihood, the reason you can't get a remote Web page is because of network issues. The best thing to do is tell your Webmaster about the problem.
Another possible cause of this problem is that you're running FrontPage from a stand-alone computer. Although FrontPage attempts to connect to the Internet, if there is a connection failure during dial-up, you won't be able to access remote pages. To
solve this problem, all you need to do is connect to the Internet.
Because FrontPage is a multi-user environment, you might get a message from one of your colleagues. Suppose that she tells you that she just finished a Web page and that the one you're working on should link into it. If you try to access her new Web
page and can't find it, the problem could lie with the FrontPage Explorer. The FrontPage Explorer loads in the attributes for a particular web when you first access it. This means that if changes are made after you first accessed the web, they won't be
seen. Fortunately, you can force the FrontPage Explorer to update the attributes for the current web. This can be done by clicking on Tools | Recalculate Links from the FrontPage Explorer, causing FrontPage to re-evaluate all the links and data information
for the currently loaded web.
The Personal Web Server that comes with FrontPage is derived from an NCSA Web server. It is straightforward and its interface is easy to use. That's not to say it's a perfect Web server, but the Personal Web Server is at least familiar to veteran
Webmasters. Because it's based on a UNIX Web server, when something goes wrong, it might not be easy to fix. The FrontPage Web Server Administrator program doesn't give you an option to work on the files directly. Consequently, you have to break out a text
editor and directly modify the configuration files.
Although changing port numbers isn't a problem, it is certainly a commonly requested feature. In a completely fresh and Windows-specific Web server, this could be accomplished in a number of ways. However, because FrontPage is an NCSA-derivative, you
have to modify its configuration files. To change the port number of a Web server, you first have to shut down the server that you want to change the port number for. You can do this by double-clicking the Web server icon on the taskbar, selecting the
Startup tab, and then clicking the button labeled Stop. Next, start a text editor and modify that Web server's httpd.conf file. Go to the entry that states "Port =" and change the value
from 80 to some other number.
By default, Web servers "listen" to port 80 of all machines. However, you might want to change it to suit your particular setup. Situations in which you want a different port number include running a multihoming
environment, running a Web server through a firewall, and similar circumstances. Whatever the case may be, changing a port number is easy, but not intuitive. After you save the configuration file, you can restart the server.
The Internet Information Server (IIS) is a very good intranet package for Windows NT. It offers FTP, Gopher, and Web access in a package that's easy to work with. Your organization could very well be running the Internet Information Server (IIS), and
as a result, you might want to have FrontPage hook into it. Fortunately, Microsoft made a FrontPage Extension for the Internet Information Server. If you're having problems installing the IIS extension, you simply might not be using Windows NT. IIS was
written with the Windows NT operating system in mind and consequently depends a great deal on Windows NT features that aren't in Windows 95.
An incorrect version of the software also might prevent you from installing the extensions. Which software? The operating system or FrontPage could be at fault. The Internet Information Server extensions can only be installed on Windows NT 3.51 server
or later. Furthermore, that system must have the NT Server Pack #3, or later, installed on the system. You also have to be careful of which FrontPage version you're running. You might run into problems installing the IIS extensions if you're not using the
released version of FrontPage 97.
As a Webmaster, you might receive complaints about inaccessible Web pages, either on your server or at a remote site. These problems are different; after all, one is a problem with your site, and the other is a possible problem with another site.
However, they are similar problems and have some similar solutions.
An internal Web page might be inaccessible because the web in question is password protected. Although you, the Webmaster, can enable or disable password protection on a web, so can Web administrators. It's possible that the Web administrator for the
page in question has made his web protected. You can easily get around a page access problem by disabling password protection for a web. This can be done by loading the web in question into the FrontPage Explorer. Next, select Tools | Permissions and
choose the End Users tab. Simply disable the web password protection and quit the Explorer.
If your users could also have problems trying to access external Web pages, you must make sure that the host of the web in question is actually up. You can verify this by using the standard UNIX utility, ping, and accessing
the remote host. If there is no response, the host could be down or routing to that host could be unavailable. To make sure that your site isn't at fault, try to ping a computer outside your domain. If it succeeds, it's
probably a network problem with the destination host. If it fails, your network connection could be down. You should contact your organization's Internet service provider (ISP) and report your problem.
A possible cause for Web page access problems both into and out of your site is the proxy server. If your organization uses a proxy server in conjunction with a firewall, the proxy server could be at fault. It could be offline or misconfigured to
disallow any communication on port 80, the default port for HTTP. You should talk with your network administrator to verify that the proxy server is running properly. If it is, also have him check that proxy servicing is enabled for the ports on which the
Personal Web Server is running.
Even though FrontPage was designed to work on a network, it works fine if you're not on one. However, if you're not on a network, you can still have some problems. The most common problem is that webs on the FrontPage server aren't available.
If you're trying to access an existing web and you just started a machine, you might have problems. Typically, the Personal Web Server starts up automatically when needed. This isn't a problem for people running Windows 95 or Windows NT with more than
12MB of physical memory. For those of you who fall into that category, you could have problems with the Personal Web Server starting. Regardless of how much virtual memory you've allocated for Windows 95, the server, in all likelihood, will start after a
message has been displayed (see Figure 40.2). This is because the disk drive is slower than the processor in your system.
Figure 40.2. FrontPage is complaining that there isn't a server, but in fact the server started too late.
It's not that the server won't start up, just that it starts up too late. Consequently, it's possible that you'll get an error message about a Web server not running on a particular port. Because the Personal Web Server is automatically started when
needed, it should be running after you get the error message. If not, simply start the Web server manually. After you've confirmed that the Personal Web Server is up and running, try to access the web again. However, the underlying problem is still there;
you don't have enough memory. You should seriously consider getting more memory, especially if you want to make extensive use of FrontPage.
When you're not on a network, you might sometimes have difficulty starting the FrontPage Editor. This often happens because you have the Personal Web Server and FrontPage Explorer already running. If you try to open a particular Web page, you get an
error message about certain modules not being able to run. Although FrontPage recommends that you quit other running applications, that might not be enough.
This problem occurs because, once again, the system you're running has insufficient memory. That's not to say that it doesn't have enough physical RAM, just not enough total memory. It's possible that the drive that Windows 95 is using for the swap
file is filled. You should delete unnecessary files from that particular drive and then try to access the web. FrontPage's minimum system requirement is 12MB of memory. Make sure that you have at least that much in combined physical and virtual memory.
After you have FrontPage up and running on a network, intranet, or Internet, you might still run into problems. This is especially true if your computer is the one running the Personal Web Server. If you're not familiar with your system's
configuration, this could be the source of some of your problems.
From time to time, you'll probably get reports about users having problems accessing one of your webs. The Internet is basically a series of interconnected computers, all talking to each other. If one of those computers between you and the person
reporting the problem goes down, the network will seemingly go down. Consequently, it's likely that your web will not always be accessible to everyone at all times. As a result, if you get one or two e-mails complaining about inaccessibility of your web,
you can probably ignore them.
On the other hand, if you receive e-mail about your web from a number of different people, there's probably a problem. You should first check your network connection. Using the UNIX utility ping, try to reach a random set
of computers outside your network. If you can't reach any of them, it could be that you or your ISP are having problems. You also can attempt to track down the specific host that's giving you problems by using the traceroute
UNIX utility. Whereas ping just tells you if it can talk to another computer, traceroute tells you how it's getting there. You should inform your network administrator about what you've found as
soon you have results.
Another possible problem arises if you're in a multihoming environment. After you've checked your network connection, you should check each of the computers that you're multihoming. Make sure that the Web servers are running on each of those systems.
Also, you should check to make sure that the FrontPage extensions are properly installed on each of those systems.
If your system can talk to the Internet and you're still having problems, you might want to look at your proxy server (if you have one). Proxy servers are used, often in conjunction with firewalls, to help watch over network traffic. This is often
simply monitoring the traffic between the organization and the Internet. If you are using a proxy server, it's possible that the server has malfunctioned, shut down, or crashed. Whatever the case may be, you should report your problem to the network
administrator as soon as possible.
When your Personal Web Server is on the Net, another problem you might face is an unavailable page. In this case, you should use the FrontPage Explorer, load the web in question, and try to find the page itself. If the link that was followed was
outside your organization, inform the Web author of that link concerning the page in question. This enables the Web author to either remove his link or remove it all together.
If the link that was followed was from one of your webs, you should load the web into the FrontPage Explorer. Next, load the Web page in question and inform that web's administrator. It's possible that the Web administrator in question has a reason for
having a dead link. It could be that he or his organization is planning to put in a page there but hasn't gotten around to it. Whatever the case may be, you can probably safely defer the problem to the Web administrator.
You might be enabling people to publish Web pages through the Personal Web Server. What publishing Web pages means is that the Web pages are built in a staging area. When they're ready to be released, they are published and pushed out to the external
Web server. It's possible that this is the method your organization has chosen to handle each group's Web page. It's also possible that you're working for an ISP, and this is how you want your users to make their pages publicly available.
Before authors can publish their Web pages, they have to be able to communicate to your Web server. If they are complaining that their system isn't established to the Personal Web Server, there could be a few problems. One of the most basic problems
occurs when the author isn't logged onto your network. This is especially true if you work for an Internet service provider where people dial into your system. Although FrontPage does initiate the dial-up routine, it's possible that the user failed to
connect to the Internet and can't upload his Web page because of this connection failure. Make sure that the user is logged on to your system to begin with.
Another possible difficulty is that there's a problem between your system and the author's. You can check the network connection through the usual suite of tools. If you're working at an ISP, you probably won't be able to check the connectivity to the
author's computer. However, you can have the telephone company check the telephone connection between the remote modem and your company's computer. If there are any problems with the connectivity, they should fix it automatically. If they determine that
the connection between your company's building and the remote modem is fine, you should check your building's telephone wiring. (Obviously, checking telephone wiring requires a trained professional from the telephone company.)
One of the most typical methods of publishing your Web pages with FrontPage is to publish the web. That is, the Web author loads his web into the FrontPage Explorer and tries to copy it to the external Web server. This method is a good one because it
enables each author to develop his pages independently. This also enables authors to test everything on their systems, minimally impacting the Web server itself. However, because it's probable that you'll have authors from all over the world, the Internet
is involved. What this means is that there could be network problems while an author is trying to publish his Web page.
If a few authors can't publish their Web pages, you should check the network connection. Check the network connection between the Web server and the author's computer. You can use the usual ping and traceroute utilities to help you. It's also possible that the drive with the Web content is filled up, and the copy operation is failing. The obvious solution to this problem is to delete or move unneeded files.
A possibility exists that you won't always be with the same Internet service provider. It's also possible that you won't be working for the same company forever. Consequently, there might come a time when you need to move your web. This obviously only
extends to your personal webs because you won't have access to your group's web when you leave. Those duties will be given to someone else to maintain and update.
While you're creating Web pages, you'll almost definitely create links. There are a number of acceptable protocols that a URL can take, such as gopher://, ftp://, and so on. Another such
protocol is the file://, which refers to a file on the local computer's drive. The file that's going to be accessed isn't the one stored on the server's hard drive, but on the client's. Although this might not be used very
often on the Internet itself, it's more likely to be used on intranets. It might be practical to have a URL point to a common network drive and access a particular document.
As a result of the way the file:// protocol behaves, when you move the web, you might suddenly have some broken links. FrontPage usually does a good job of keeping track of which files go where, but the file:// protocol could easily be overlooked while you're moving your web. Be sure to check your web for any URLs that use the file:// protocol and manually copy the files over.
This connection problem typically arises when you move or copy the Web server somewhere else. Some Web authors may have hard-coded the address of the Web server. That is, they've put the actual host name in a URL they used in a link to a file on the
same server. Consequently, when you move the web to a new computer and a new host name, those links could very well break. This is especially true if the old Web server has been given to another person. When people try to access once valid links, they'll
try to talk to the old computer. That system might not even be running the Personal Web Server, let alone have the same content.
To fix this problem, first take the old Web server completely off the network. Next, start the Personal Web Server on the new computer and have FrontPage verify all links. If there are any broken links, they are probably due to the hard-coding of the
old host name. Correct the problem by eliminating the http:// protocol, and simply refer to the web from the top level. This makes it easier if, and when, you move the web in the future.
FrontPage is an incredibly detailed and involved HTML editor and Web server. Although this is mostly something to be praised, there are some aspects of it that can lead to problems. Most often, these problems are the result of a bad or questionable
network connection. Whether it's an intranet-based Web server or an Internet service provider providing Web services, the problems and solutions are pretty similar. Most of the time, they can be tracked down and fixed by a veteran network administrator.
Another source of common problems is the lack of knowledge of how the Web works on the part of Web authors. There are certain "good" and "bad" aspects in creating a Web page. As a result, there's a good chance that some
"bad" aspects of Web design will creep in. To help minimize this problem, be sure to have FrontPage verify all links. This should be done periodically and when something major happens to the Web server.