The nav structure is stored in a plain text file called \_vti_pvt\structure, which is really structure.cnf, but it will not do any good to upload that file to the server manually.

The FP Extensions on the server play an active role in rendering some aspects of your pages. If you upload the data file but turn the Extensions off, your pages will stop rendering properly.

If you need the nav structure, it means you're probably using the Navigation webbots to automatically create link bars that display links to related pages.

The page at [support.microsoft.com...] has a list of FrontPage features that require the server-side Extensions to function properly. The dependency on the navigation structure (the navigation webbots) are one of those features.

Before you turn off the FPE, you must remove all those features from your site, converting to alternative methods of doing the same things.

After you've done that, you have a website that is not dependent on proprietary FrontPage features (the webbots), and can turn the FPE off. At that point, you can use any web design program (or a text editor) to manage the site, which means you can continue to use FrontPage for that purpose, since it's a very good text editor.

From that point on, you'll use FTP to publish the site.

Thanks for the very clear explanation.

Do you have any suggestions for creating an alternative, non-front page navigation function? My site is pretty complex with a number of menu levels.

To have the link bars automatically calculated for you (and auto-regenerated if you reorganize the structure of your website) like your current FrontPage method does, you'd need to replicate the relationships among your pages in a database and do the link bar code generation with PHP. I've never heard of anybody doing that. My suggestion... don't bother. The goal should be a replacement method that is good enough, not one that perfectly duplicates the original. The end result will probably be an improvement, even if it doesn't seem so at first.

If you're lucky, you might find that one or more of the following applies to your site:

1) Some or most of the link bars are extraneous clutter that add little value to the page. If you remove them, not much will be lost. If you have a sitemap, you can just put a link to the sitemap on each page, and get rid of unnecessary FP-generated link bars. Every link bar you delete is one that you don't have to convert.

2) Many of your pages (or groups of them) have identical link bars. Those link bars can be replaced with static HTML link bar code. It is even possible to preserve the FrontPage-generated link bar code (which is already in each of your files), but just make it "non-webbot" code so that FP doesn't manage the code anymore.

Contrary to what you'd think from looking at FrontPage-generated link bar code, a basic link bar is very simple. It's just a set of hyperlinks grouped together:

Textual link bar (horizontal):

<p>
<a href="/index.htm">Home</a>
<a href="/sitemap.htm">Sitemap</a>
</p>

Graphical link bar (adding the <br> makes it vertical):

<p>
<a href="/index.htm"><img src="/images/home.gif" alt="Home" title="Home"></a>
<br>
<a href="/sitemap.htm"><img src="/images/sitemap.gif" alt="Sitemap" title="Sitemap"></a>
</p>

When I converted my site, I ended up just deleting most of my FP link bars even though I knew how to convert them. Instead, I made a top navigation link bar (Home, Sitemap, etc.), put it in a .php file, and included it into the header of each page.

There was one set of pages closely related to each other where I wanted to preserve the existing link bars from each page in the set to all the other related pages. After some study of the HTML code, I saw how to remove their status as "webbots" and yet preserve the HTML code that the webbots had generated. That left me with plain HTML link bars in those locations.

There are complicating details of doing the conversion that you'll need to understand by studying your code and using web searches if necessary to learn about how FrontPage works "under the hood". Go slowly and carefully.

The key concepts are:

1. You might not need as many links bars as you currently have.
2. The basic HTML code for a link bar is so simple that putting them into your pages manually is not that difficult, and the FrontPage method of managing the navigation structure, auto-calculating parent/child relationships, and auto-generating the link bar code might not really be saving you anywhere near the amount of time and trouble that you thought when you first started using the FP link bar methods.

Many thanks. Very clear.

Vince

To expand a bit further, the main complication is that all the folders and subfolders in your site that start with an _underscore belong to FrontPage. It creates new files in them, or modifies files, or deletes files anytime it feels it's necessary, with no warning to you.

Before you start taking steps to remove webbots, anything in those folders that you are going to need in the future (such as the already-created button images for your link bars) must be copied from those folders into your own non-underscored folders, and all the links to those items throughout the site should be adjusted to point to the new location rather than to the old _underscored folder. Then if/when FrontPage deletes its _underscored files/folders, it won't make any difference because you're already using your own set of them.