FrontPage - Personal advice | Traps and Lessons Learned | FP, Oracle, ASP | FP Wish List | Faughnan Home
Here are a few things I've learned that may save you some pain with FrontPage 97/98 and 2000. This page will be of particular benefit to those who use a UNIX web server without FP extensions, who need to deviate from a very simple installation, or who simply want to avoid FP's many landmines.
As of Nov 15, 2001 one last longstanding unfixed bug in FrontPage 2002 server extensions pushed me over the edge. I will not use any new versions of FrontPage, IIS, or the server extensions. I'm strictly in maintenance mode and looking to switch to Dreamweaver. I do not recommend anyone upgrade beyond FrontPage 98b.
Note this page is not well organized, the contents section is pretty much the only way to navigate it.
Revised: 01 Nov 2004
| Microsoft Personal Web Server (PWS)
FrontPage 2000 - Disappointing |
Microsoft FrontPage 98
Microsoft FrontPage 97 |
FP 2000 is a radical revision of FP 97/98, and the most disappointing upgrade of any product I've ever used. I get the sense Microsoft really doesn't know what to do with this product. It's a product that could have instantiated Tim Berners-Lee's vision of the web, but it is fundamentally non-standard and it has been caught in the maelstrom of shifting Microsoft priorities. (The lack of true standards compatibility is by design, the original CEO wrote a rather egocentric book in which he explicitly states that Vermeer/FrontPage was designed to break open standards.)
The most obvious change is a shift towards disk based editing and away from communicating with a web server. This reduces installation complexity and all the security holes in Microsoft's servers, but it also reflects fundamental confusion about what the product is for. (The change may have partly been driven by corporate concerns about security problems with running internal web servers -- IIS esp. with FrontPage extensions has a rich history of security issues and it requires very frequent patching). Microsoft wants you to use FP 2000 with a disk based web. If you want to run a web server (say to use FrontPage 98 as well in a workgroup) ... well ... don't say you weren't warned.
Overall the program has continued a trend towards feeling more like a single-window version of Microsoft Word and less like a web tool. Less obvious are a range of mistaken changes; it's as though all the original product managers left and maintenance was turned over to an inexperienced group of Word team novices. With FrontPage 2000 I think Microsoft crossed the line. I do absolutely not recommend this upgrade.
As usual installation was a bit of a fiasco; I went through several install/remove cycles until things settled down. I think it's best to deinstall previous versions prior to installing. Manual deletion of missed folders, etc. may be required.
If you are really stubborn/foolish and want to do web-based editing, then install the web server first (see Internet Information Server 4/5 Personal Web Server). I also recommend downloading the latest versions of Microsoft's server extensions (eg. not the ones on the CD) and installing them next. However it is pretty clear that using FP 2K in anything but disk based editing mode is relatively unsupported by Microsoft. The main reasons to go with web-based editing are
Alas, the best/easiest support for web-based editing was probably FP 97/98 on a Windows 95 machine.
The FrontPage server extension administration tool are administered through the Microsoft Management Console. Unfortunately, MMC is really an NT tool! The installation process put in a 1997 version that is supposed to work with Win98, I found it to be quite fragile. (It also conflicts with SoundBlaster Live software, but that may not be Microsoft's fault.) The server extensions are installed in a Microsoft FrontPage directory on your system drive; you have no choice with this and it's a separate directory from FrontPage. In a folder called 3.0 you will see the old (Microsoft PWS 3.0) management tool -- don't use it. It does nothing with the later versions of PWS which are based on IIS.
I installed into my Microsoft Office 2000 folder as per the default, FP 2K uses a lot of Microsoft Office tools and I think that if you install anywhere else FP 2K may duplicate a lot of files. If it were being installed with a different version of Office I'd put it in separately.
Until I figure out this typically nasty release, I am still doing most of my work on a Windows 95 PWS 3.0 web (I wish I'd stuck with this, I later changed to IIS and then changed back). I had to enter the URL directly, FP 2000 has lost the ability to query a server for available webs. Once I'd done this FP 2000 created a Web Folders on the desktop. This is interesting given the relationship of Web Folders to WebDav, a W3C standard. To view webs, look first in the web folders directory.
I had trouble getting this to work when I tried it with a Windows 2000 box running IIS 5.0 personal. On a Windows 98 box running Windows 98 PWS (basically IIS 4.x personal) it seemed to work at first, but then it worked quite erratically and I finally put all my directories into one tree on one drive and made the parent directory the root web.
I don't think this is supported, in fact I think I saw buried away somewhere that IIS 5.0 on Windows 2000 doesn't support subwebs, or perhaps they all have to be on one physical drive? Of course it didn't help that I was dual booting from Win 98 to Win 2000, thus running IIS 4/5 with the Win 2000 server extensions on the directory structures, or that in switching from Win 2000 to Win 98 my Win 98 drive letters changed! (Because Win 98 can't see the NTFS drives).
In other words, "ere I saw Elba".
Anyway, I've included the directions I developed below, use them at your own risk. One additional tip: if you move a set of files that belonged to a FP web into a new web, then from the Management Console choose "New Web", you may get an error message telling you the files contain FP web extensions and telling you to delete server.cnf if you wish to continue. The error message is referencing the wrong string -- the file in Windows is just "server" (maybe in Unix it's server.cnf).
From a post to microsoft.public.frontpage.client:
FrontPage 2000 no longer supports any implementation of relative font sizing - part of its consistent migration towards integration with Word. FP 98 at least supported the <small> tag!
My O'Reilly HTML 4 text reflects the common stand of HTML bigots like myself -- we hate absolute font sizing. We like to leave the base font definition up to the user's browser settings, and then suggest relative sizings. CSS is best for this, but the <small> tag is not deprecated and (contrary to a prior posting) it works very well with Netscape, Opera, and IE -- all versions. Check out the W3C's HTML 4.01 tag description or their elements table; <FONT> and absolute font sizes are deprecated, but <SMALL> is still very much approved.
I used the <small> tag in my pages. It's just handy. Now I have several hundred static pages that FP 2000 doesn't know what to do with.Since FP 2000 does not support style extensions using the <SPAN> tag I can's define a .SMALLER style and apply it to inline text. I tended to use relative font sizing in menus, so I was able to apply a style to
This part of this long page is not organized in any reasonable way. Use the Contents area to navigate it.
Installing FP 97 can be an ordeal. If you put everything on drive c:, you should be ok. If you use drive c: only for your OS, and install apps elsewhere, good luck. Unlike, say, Netscape, Microsoft does not use the standard Windows installation process. You do not always have the option to choose an 'advanced installation'. The IE 3.01 installation is particularly ugly. I recommend:
[ref: http://www.microsoft.com/frontpage/upgrade/engupgrade.htm]
Microsoft clearly intends that everyone install everything on drive c:. Using any other
drive with Microsoft products is always tough, but using any drive but c: for your
Personal Web Server hosted webs is brutal. Here's what you have to do (drive g: used as an
example):
PWS 4.0 is either IIS 3.0 or IIS 4.0 (not sure, I think IIS 4.0) repackaged for personal use with Windows 98. If your registry is at all complex installation fails with a meaningless error message. See Q246081 - Error Message An Unknown Error Occurred While Making MTS Specific Changes to the System Registry for details. Basically you copy all files to your drive, replace on DLL, and start over. (PS. scanreg /fix can be run if you boot to DOS; it will rebuild a registry. Not sure how well it works for this problem though, the DLL fix does work.)
FrontPage's handling of the BASE HREF tag is absurd. Once you add any base href tag, all links in a document become fully qualified and point to the current machine rather than to the URL of the BASE HREF tag. A very important tag, but you can't use it with FrontPage. Stupid.
One day I discovered I could no longer browse the local file system from the FrontPage 98 editor (FP Editor). When I chose File Open then clicked on the folder icon by the filename entry field ("Select a File on Your Computer") FP simply locked up. Presumably this is due to one of Microsoft's numerous DLL conflicts (see DLL Hell). I reinstalled FrontPage 98, but I had no success. Recent installations include Microsoft's WebFolders and IE 5.5; they would be my primary suspects.
It is still possible to use the Windows "SendTo" command to send a file from the local filesystem to FrontPage 98 for editing.
Microsoft has a tech report on this, but the report is incorrect. This problem occurs on my Win95 system with upgraded extensions. After Fall DST begins I get 'newer version saved' errors, and my web page time is an hour earlier than it is (as though the Fall time correction had been applied twice).
It seems that having FP Explorer rebuild my hyperlinks has resolved the problem.
Microsoft Personal Web Server also includes an FTP server. However it is initially set up as "read only". To enable writing you have to done one or more of the following (I'm not sure all of this is necessary. Steps 3-6 definitely are.).
- Go to Network Control Panel and enable Microsoft File Sharing.
- From Explorer open properties for the FTProot folder within your WebShare folder. Allow Full Sharing. Go into Web Sharing and allow FTP read and write.
- Now go to control panel and startup Microsoft PWS (if it's not running).
- Make sure the FTP service is running. You can use properties to have it auto-start along with the HTTP service.
- Go to administration for FTP and choose the directories tab.
- Click on the name of the FTP directory. You'll get a screen where you can turn on write access.
- Now (phew!) you should be able to read and write to this directory from an FTP client.
After installing IE 4.01 over an existing installation of FP 97, I experienced new crashes with FP 97. On the other hand, I've also had crashes on startup when IE tried to run its tutorial module (Kernel conflicts). I do love Microsoft.
FrontPage automatically "encodes" the links that it creates. Spaces and non alphanumeric characters are replaced by a hexadecimal string, such as %20 for space. Unfortunately some system DLL replacements that are appearing in April of 1998 already encode Internet Shortcuts. This can result in a double encoding when such a shortcut is dropped into FrontPage (see Quick Creation of Links Within a Document). The resulting string may be unuseable. I have experienced this with news: type URLs. The only fix is to hand-edit the link code and reverse the incorrect encoding.
This was a problem with FP97, was fixed in FP98, but is broken again when you install the FP98b service pack.
Netscape does not render empty table cells. The standard workaround is to put an entity in the table cell. FP98 would leave this alone, but FP98b removes it under some circumstances. (May be related to switching to HTML view of a table.)
FrontPage's default behavior is to place all the files for a single site into one directory (folder). This can lead to name-space collisions (too many file names, gets tricky to remember what goes with what). It's also much more difficult to organize projects and to ftp projects separately (see Web Publishing Wizard (WPW) vs FTP ...). If you choose folder view, you can organize your files in a logical fashion. In my case, I have to mix FP managed web pages with my other pages on a UNIX server. I'm still experimenting, but here's how my FP pages are set up on my Personal Web Server:
root
(could call it anything).root I created a folder that has
the same name as the folder that holds all of my webs on the UNIX server - public_html.public_html.fp within public_html.fp each FP project gets its own
subfolder. For large projects I may use several sublevels of folder organization._private folder for the
appropriate project.fp
level; project specific images go into lower image folders.public_html
folder and link to that. That way FP uses relative links (which I prefer).Both FP 97 and 98 have trouble with large tables (60K files and higher). FP98 does a little better than FP97. With NT 4.0 and a 166 Pentium/64MB DRAM the CPU pegs at 100%, with FP Editor and Explorer alternating 'not responding' messages. This smells like a combinatorial explosion bug, not a CPU limitation. It's not a RAM limitation either. The algorithm for rendering tables must have some recursive code that takes forever to converge. FP 98 does much better than FP 97 with large non-table documents: FP 97's HTML editor couldn't handle more than a 32K file.
FP 97 choked when importing web sites with hundreds of documents. I've not attempted this with FP 98. FP 97 also had problems with large web site linkages.
FP 97 uses a stupendous amount of memory. Explorer and Editor together use 17MB of RAM just sitting around (compared to 11 MB for Word 97). The Personal Web Server, with a moderate sized site loaded, uses over 7MB. Having a browser loaded for previewing adds another 10MB or so. Clearly, even with 34MB of DRAM, a lot of virtual memory is used. I wouldn't try to use FP with less than 34MB of DRAM, for FP98 I think 48MB will be a practical minimum. FP runs better now that I have 64MB of DRAM; I think 96MB is not unreasonable for today's systems.
This is a somewhat subtle issue, but if you do hypertextual content creation it's a big problem. FrontPage will generally do a good job with maintaining links at the page level, but it will allow you do delete anchors within a page without warning. If you move an anchor (bookmarked text) between documents FrontPage will not fix up the the links that reference that anchor; it will not correct the URLs. Similarly FP will not correct references if you rename an anchor. FrontPage's link tracking is limited to the document level only.
This appears to be true of all versions of FP from 1.0 through 2000.
Webbots are instructions embedded within HTML comments that are interpreted by a FP-compatible web server. FrontPage's ASP implementation uses webbots for example. The easiest way to disable webbots is to use a text editor to replace the first letter of the string <!-- webbot with any other character. To enable them restore the correct letter. This is very useful if you want to edit the output of a FP ASP query in FrontPage. The embedded webbots make editing impossible, but this trick makes will allow editing normally. (Oddly enough, I cannot locate any utilities for stripping FP tags from web pages.) [kw: disable, remove webbot, delete webbot]
FP 98, and presumably, FP 97, has a 'temp' folder in the FrontPage directory. I'm not sure it ever get's emptied. I clean mine out every few months.
FrontPage 97 can't show framesets. I found the frameset wizard to be relatively useless. I do frames with an external text editor, using FP's Open With feature. (I configured FP to use TextPad as my external editor.) To view your frames use an external browser.
FP really prefers to use .HTM as your document extension. I prefer .HTML and often use it, but it's an uphill battle. I've been unable to make templates work properly using the .HTML extension. It's probably easier to give up and go to .HTM.
UNIX servers typically recognize index.html as the default document to display if a URL does not specify a specific document. You can set index.html to be your default document:
In Microsoft Personal Web Server
Click on the Administration Button. In your browser choose WWW administration. Then choose directories. At the very bottom you'll see a field for specifying the default document.
In Front Page Personal Web Server
Add this line to Srm.cnf:
Directory index.html
Well, this is a real mess. It took me quite a while to understand how bad things are. It's clear that Microsoft is giving up on the original design (FrontPage up to FP98 with Windows 95) of editing files hosted on a web server. See also:
Here's how it breaks out as of June 2001:
| OS | Web Server | FrontPage | Comments |
|---|---|---|---|
| Win ME | None | Win ME does not have a compatible web server. What an awful OS. | |
| Win 95 | Microsoft Personal Web Server FP 98 | FP 97, 98, 2000 | The Microsoft Personal Web Server that ships with FrontPage 97/98 and is installed on Windows 95 machines has no ASP support. It's a very small and very simple application with abundant security problems. With the FP server extensions it allows any machine with any version of FP to edit the web -- ideal for low cost workgroups. It only works (as far as I know) with Windows 95. |
| Win 98 | Personal Web Server (IIS 3/4) | FP 97, 98, 2000 | A version of Microsoft's IIS 4 commercial web server, IIS 4
ships with Windows 98 and NT 4. It used to be available on Microsoft's web site but it has
been utterly expunged -- The address in May of 1999 was http://www.microsoft.com/windows/ie/pws/.
It can allegedly be used with Windows 95, but it installs a new version of Winsock which
annihilated my system (turns out some of my older system level software extensions aren't
compatible). It does not support editing from anywhere but the local machine. A
Win 98 machine running PWS/IIS 4 is a downgrade from the Win 95 web (though you
can do ASP work with it.) If you try it from any other machine you will be a variety of extremely cryptic error messages depending on your version of FrontPage, such as "The server could not complete your request ..." and in the details area "Error 403.1 HTTP Error 403 403.1 Forbidden: Execute Access Forbidden. This error can be caused if you try to execute a CGI, ISAPI...". Microsoft explains further. Basically Microsoft doesn't want you to use Win98 as a cheap platform for workgroup editing of a FP web. You might have some luck if you used FP 2000 and edited a disk-based web that was shared on Win98 -- I don't know. If you're going to do workgroup editing of a FP web, you need to run Windows 2000 (preferably) or NT. Security with IIS4 under NT can be confusing. I allowed editing access to everyone in my home domain, but when I dialed in through our firewall I couldn't enter a username and password that would work. I found that if I preceded my username with the domain name (DOMAIN/USER) that the password worked. |
| Win 2000 | Personal Web Server (IIS 5) | FP 2000, 2002 (98 remotely) | You have to first install the personal version of IIS 5
using the Add Components wizard. If you install on an NTFS directory you have security
control via NTFS. If you install into a FAT32/FAT directory then you have pretty weak
security -- kind of like the Win95 PWS security that Microsoft felt was so bad for you
that they wouldn't permit it. I'm not sure, but I think that while IIS 5 will support multiple virtual directories as separate webs, it will not allow one to install FP extensions in each. I think FrontPage will only be able to operate on files within one physical directory. |
I use this service to send files from my Mac to the home server.
FP 2002 Server Extensions attempt to get around the incredibly complexity of FrontPage web security (where you have file level security, web share/IIS security, and FrontPage access controls). Unfortunately it was evidently not tested. Specifically, it has a grievous bug on web sites with more than about 100-200 pages. Microsoft has known about the bug since at least May of 2001, and they've known how to fix it. They just haven't fixed it. I can no longer pretend that FrontPage with the web server and server extensions is a viable platform; they're just not enough users left. I'm done!
For details, see http://support.microsoft.com/support/kb/articles/Q298/8/27.ASP (Include Components and Shared Borders Are Displayed Incorrectly on IIS).
I discovered the bug after I upgraded from FrontPage 2000 server extensions to 2002 server extensions. After the upgrade, when I browsed pages on my server, instead of seeing my included headers and footers I saw the path to the include rendered as bracketed plain text. On closer review the path had a recursion in it; part of the path was duplicated.
The fix (which works) involves deleting several registry keys, including CachedMaxIncludeSize (see directions) and reindexing the site. See also this usenet thread.
After experiencing some problems, I had to uninstall my FP 2000 server extensions. I then tried to reinstall, but now Win2K wouldn't let me. Some security patch had obsoleted the older extensions. So I again went to FP 2002 extensions, despite earlier experiences. The new experience was that I couldn't actually get to do anything. The message I received said: "You are not authorized to view this page." The fix is Q321488 - STS You Are Not Authorized to View This Page Error Message When You Try to Connect to the Site Administration Page. What a way to run a software monopoly!
See also
I got this just barely working after a LOT of struggle. In this case IIS 5/personal was running on Windows 2000 Professional with NTFS as the file system. I installed FrontPage server extensions 2002, but I'm not sure the web ever fully upgraded to the new server extensions.
The problem is the security model and permissions. Consider these complications:
I am pretty sure the above understates the complexity of this situation. It's no wonder Windows/IIS are famously insecure -- I can't imagine configuring something that had to run outside of my firewall. This is all for purely internal use!
During my many tests FrontPage 2000 on the client machine would produce cryptic error messages and refer me to the log for further detail. Here's what the log contained:
08/25/2001 13:20:10
HTTP 500 Server Error
<html>-2146893039 (0x80090311)</body></html>
During my testing process my Windows 98 FrontPage 2000 client crashed, and on restarting it was able to see and edit the Windows 2000 IIS 5 hosted web. I don't know what I really needed to do, but here's some of what I tried:
See also
When I installed NT 4.0 Workstation (service pack 3) on one of my machines, I found that FP 97's Microsoft Personal WebServer won't install under NT. Instead I had to download and install the personal version of Internet Information Server 3.0 (IIS 3.0) and install the FP extensions to that web server.
After some hassles, I got that working with FrontPage running on the same workstation. I wanted, however, to be able to use FrontPage from my home to edit the web at work. This is not hard, but I found almost no useful documentation. FP 97's server side extensions get their security model from NT's security. Here's how I had to proceed:
NT security has multiple layers, and for something to work the user must have permissions at the file level (controlled by NTFS for example), then at the application level (IIS in this case). The default user name for person's browsing an IIS web is IUSR_......
If you rename your computer (control panel:network:identity), then FrontPage won't be able to to open your webs automatically. HOWEVER, I think if you list the webs then FP will find them.
FrontPage is pathetic at importing web documents with even modestly complex tables. It's much easier to recreate the tables using FrontPage, then switch to HTML mode and cut and paste in HTML as needed. This is not due to FP's limits in creating pages, but rather with importing HTML (even HTML that passes standard quality tests).
In theory it's possible to save a page as a template. When I did this, FP attempted to save associated graphics into subdirectories of the template directory. Unfortunately, it used UNIX (web) style slashes, not DOS slashes, for the directory path. The procedure failed. Instead, I create a 'template' document, and save it as a new document when one is needed.
FP does not use relative font sizes. If you enter a relative font markup <FONT SIZE=-1> in the HTML editor, FP97 changes this to an absolute font size code for every paragraph. It does the same thing with a <BASEFONT> tag. I can find no workaround except HTML Markup insertion, which is clumsy.
If you have no font specified in your document (the browser will use its default font), FP displays Times New Roman as the font type.
This is partly an HTML mess, but FrontPage makes it worse. There are a half-dozen ways to specify font sizing in HTML, from the <small> tag to a style sheet specification. FrontPage provides a nice button control to apply the <small> tag (smaller and bigger capital A buttons), but the Font Properties box applies an absolute Font Size control, which applies the <Font size=#> tag. There's no way to do true relative font sizes. Worst of all, within FP, these two tags give identical results. In many browsers, however, the results are quite different.
Since the W3C HTML 4 spec deprecates use of the <Font size=#> tag, it's preferable to use <small> or style sheets.
FrontPage uses the Windows character set for encoding. It turns entity codes like © (copyright symbol) or ° into Windows characters. Some browsers may be unable to read this characters. I used the HTML markup insertion to put entities into FP that it would leave alone. This may be the best way, in general, to use entity codes with FrontPage. With FP97 markup insertion was simple, with FP 98 it's a "hidden" feature, and there's no UI to show that the marup exists. This is one of the top 3 things that are really, truly, stupid about FrontPage.
UNIX servers treat myFile.html and MYFILE.HTML and myfile.html as 3 distinct files. Win95/NT/Mac servers treat them as the same file (they ignore case). If you have myfile.html in a link and myFile.html on a UNIX server, the link won't work. For this reason I stick to all lower case everywhere.
I've been able to corrupt a web site in routine work. I do use a number of WebBot includes, and I also move files around using only FP Explorer. In my case FP cross-linked some includes and crashed. I was able to recalculate links after rebooting and restore the site. I recommend backing up one's web site at least hourly. I back mine up to a zip archive.
[ref: http://www.microsoft.com/kb/articles/q159/4/39.htm
and http://www.microsoft.com/kb/articles/q143/1/01.htm
]
It is generally far better to simply FTP your files to a web server, rather than use
the extremely buggy and kludgy WPW. I use FTP Explorer.
FP uses relative links, unless you force it to do otherwise, so it's not hard to ftp
In many cases you will choose simply to ftp your web using an ftp client. Typically I use
Windows Explorer to copy my fp web to an appropriate directory. Then I delete all the _private and other folders that are not used on
my server. Then I ftp the remaining files.
If you insist on using the WPW with a UNIX or other non-Microsoft server with the FP server extensions:
(I had to do this for a server named dragon.)
Not all of these steps may be necessary.
[ref: http://www.microsoft.com/kb/articles/q143/1/02.htm]
From: Corne van Delft. Use this if you're not able to connect both computers to the net:
In the course of trying to enable execution of scripts, I turned on web sharing from the Windows Explorer context menu (folder icon appears held in an outstretched arm). Afterwords I could not access the web from external browsers. FP could still open the web, but web bot includes did not work. I turned off sharing for that folder. The includes were restored. I was unable to find a way to make my web files accessible while enabling scripts to be run.
FrontPage normally produces relative URLs. If you set the BASE field in document properties to a fully specified URL, then URLs within that document will be absolute using the base URL.
If you highlight text, then use the right mouse button to drag it elsewhere in the document, you can select 'Link Here' to create a link that's internal to a document. Very handy, but it's tedious to drag the text block around a large document. It's easier to use the RMB to create the hot link proximal to its source, then cut it, move to the point of interest, and paste the hot link there. (Note, however, that the target is the full text of whatever you highlighted, including spaces.)
See FrontPage 98, ASP, IIS 4, ODBC, SQLNet and Oracle.
Fp 98, but not FP 97, ignores a page's title when you do a Ctrl-K link insertion. Instead it uses the Windows file name. This is an incredibly, jaw droppingly, stupid design decision.
There's a workaround. I routinely duplicate the <TITLE> string as a title at the top of my pages. I give this a 'bookmark' of "title". Then I can drag and drop from this bookmark to other pages to create links.
See http://support.microsoft.com/support/kb/articles/Q277/7/69.ASP. The Windows ME OS does not support using FrontPage with a web server. So you can use FP 2000 in its file-oriented mode, but you can't use FrontPage 97/98 with Windows ME. Windows ME is a bit of a dog.
Most of these point to Microsoft Knowledge Base articles