Results 1 to 1 of 1
2003-03-22, 11:44 #1
- Join Date
- Aug 2002
- Dallas, Texas, USA
- Thanked 0 Times in 0 Posts
Repeat page within Navigation (Front Page 98/2000/XP)
Issue: When you add a page to your navigation in Front Page, you cannot add that page to your navigation again. You CAN add that page as an 'external link', but that will not let you add pages beneath it in the navigation structure. Why would you want to be able to add the same page? Simple, less space if you have one page that you want in your navigation at multiple locations. In my case, I wanted an ASP page to show up in four different places, with a different QueryString (ie, http://MySite/mypage.asp?PageVersion=1 ,or http://MySite/mypage.asp?PageVersion=2), that way, I have the same page, displaying whatever it needs to based on the QueryString value (in my example, that would be PageVersion), in different areas of my navigation.
Problems: #1. The GUI does not allow for adding the same page twice. It also doesn't allow you to edit the URL of a Navigation Node (A Node is each individual page in your navigation). Even though VBA in FrontPage, the URL of a Navigation Node is Read-Only.
#2. There does not appear to be any 'special files' containing navigation information, at least not from within FrontPage's file/folder list.
To solve this problem, you have to dig into the inner workings of FrontPage's Navigation. I'll walk through the steps I used to do this. First of all, FrontPage's Navigation is not magic. It has to store information to 'remember' the structure somewhere. Also, it has to be stored on the webserver, since you can get the navigation structure from any machine that you access it from. (Not to mention that the web pages are 'adjusted' with the latest structure, which the webserver does with a webbot.). So, where would FrontPage store this information?
To find this information, I had the advantage of local access to an IIS server. Thus I was able to look directly at the folders and files being used on the website. One of the folders within your web/subwebs root is _vti_pvt . That folder contains several files, one of which is structure.cnf (On my machine, the .cnf extension does NOT show up...even with those options setup in Windows Explorer's options. Also, it doesn't let me directly open the file, it thinks it is associated with some other program. I'll get into this a little later.). To get to this file you have three relatively easy options:
#1. If you have direct access to your WebServer (Either locally, or you can map a network drive to it), then it's a simple matter of going to that file.
#2. If your hosting provider has FTP support, you can get to it with FTP. This is a little tricky though, since it is a hidden folder, when you go to the root folder of your site with FTP, you will not see it listed. Do not panic. Simply change the address your FTP browser is using to have that folder after it, like this: ftp://MyWebSite/_vti_pvt/ You're browser should then list several files, one of which is going to be structure (.cnf). Copy this file to your local machine. You will need to upload the 'changed' file when you are done.
#3. If you can't do either #1, or #2, you still have an option. You can absolutely get the file. You are just going to have to beg, to 'save' it on the server. <img src=/S/evilgrin.gif border=0 alt=evilgrin width=15 height=15> To download the file, just use your browser. http://www.MySite.com/_vti_pvt/structure.cnf (obviously replace www.MySite.com with your site's correct URL information. That MAY allow you to download the file. If it doesn't, again, do not panic. We can cheat. I have attached a .zip file that has an .asp file that you simply put on your site. It's structurestealer.asp. It can be put ANYWHERE on your site, and it will grab the structure for the web/subweb that it's in. (Actually, can't gauruntee it will grab a subwebs, but it 'should'.). It will display the information within the structure.cnf file on your browser. DO NOT copy and paste what you see. HTML ignores carriage returns and line feeds, instead, right click on the page, and select 'View Source'. This should show you the data in Notepad, with the correct formatting. Save the NotePad file as structure.txt (or whatever you want). When you are done making changes, and you had to use either the http: or my ASP script file, you will need to contact your ISP's tech support, and ask them to replace the file for you. I'm sure if you asked nicely, none of them would really have a problem with doing that.
Now we all should have a data file to work with. The structure file is comma seperated. Before we dig into the information, a little tip for those of you that were lucky enough to fit into #1 or #2 above. To open the .cnf file, open Notepad first, then within Notepad, Click File and Open, then change the type of file from 'Text *.txt' to 'Any File *.*'. Then browse to the file (either on the server for #1, or the local copy you saved for #2.). Just a cautionary note, I highly recommend that before anyone continues further, that you save an original copy of the file somewhere else. Just to cover your back.
Now that you have your structure file open within Notepad, you should see something like this:
1040,WorldwideSales/world_wide_sales.htm,0,World Wide Sales,1000,1039214664,0
This is the beginning of a structure.cnf file I have on a site I am building. Let's explore what this represents. First of all, relational data structures should use a key to identify each 'record'. In this case, it should be pretty obvious that the number before the first comma (in this case, all in the 1000 range), is the 'key' for each node in our navigation.
Now that we know the 'key' field, what are the lines that don't have a bunch of commas. Well, I would guess that the first number is probably a version number. Either way, it's unimportant, so we can ignore the first line. The next line may be less obvious, but if you take a look at the keys in your data, you'll find that it's the next highest number. So line 2 is the next incremental 'key'. Handy to know. I'll explain why Frontpage would need that in a bit. Line 3 looks like a 'node', but it is seperated by Line 4, which looks like some navigation options. Line 3 is a node. It is the ROOT node. I would hazard a guess that if you have another root node, that it would become Line 4, and Line 4 would become Line 5. Haven't bothered to check that. Line 5 and on are all Nodes.
So, we know that we can ignore lines 1,2, and 4. What are the 'fields' within the other lines? Well first of all, each field is seperated by a comma, so we know where each field starts and each field stops. Let's look at this line:
1045 is the key, we have already establised that. "Applications/....." is the URL. Pretty obvious. Note that it's a short URL, because the navigation is based upon your site's root. This way, if you change your domain name, or on an intranet, you change the DNS alias, the navigation doesn't have to change, it is just going off the default root path. The next 'field' is a 0, that's a DKDC field. (Don't know, don't care). It appears to be 0 in all of my nodes. "Applications", well that's simple, it's the name of the node. It is what will show up in a page banner or navigation bar. By default it is entered as your page's title, but you can change it in the navigation view simply by renaming the node. (Or now you can rename it here.....not necessary though, since Frontpage already lets you do this). 1000, this is an IMPORTANT field. If you look through your data, you'll find that this field matches a key of another node. If you take the time to track it out, you'll find that it's the key of this node's parent. (Note that the Root node has 0 for this field, because it has no parent). The last two fields are also DKNC fields. Technically, you can probably figure out what these fields represent if you look into the NavigationNode Object, in FrontPage's VBA help files. They are unimportant for what we want to do though, so let's keep going.
We now know what fields represent a node's key, parent, URL and title/name. That is all we need to 'duplicate' a page within our navigation. There are two ways to 'duplicate' a page. The first way is to manually make the records for our duplicate page. That would require giving it it's own key (incrementing Line 2), and filling in some DKDC fields. The easier way is to just go into FrontPage, before you go to edit the structure.cnf file, and just add blank pages where you want your duplicate pages to be. Then go into the structure.cnf data, and change the URL to the correct page. Doing it the second way, using Front Page leaves much less room for error, since FrontPage is handling the key creation, the DKDC field info, the title and the Parent Key.
Once you have changed the nodes that you want duplicated (or made whatever other changes you felt like tackling), save the file back to the site (Download Method #1 just copy it to the server, #2 FTP it back up (should be able to drag and drop it), #3 Contact your Hosting companies tech support.).
Now for a few final pieces of information. First, if you use the second method of 'duplicating' the fields (letting FP do most of the work first), you will have some blank pages. When you delete these pages, note that your navigation nodes don't disappear. This is because the navigation 'engine' is matching the navigation nodes to the pages they represent through the 'URL'. Since the URL is different, after you change it, there is no longer a match for those 'blank pages'. Why is this important? Because one of the features of FP's navigation, is that it keeps it updated for you. If you use an ASP page, with a querystring after it, then the URL is NOT going to match a file, so if you move or rename that page, the Navigation is not going to update itself, you'll have to do it manually. If you have just a duplicated page, so the URL will match several times, I have not tested whether or not FP will change all of the navigation nodes for you. It may just change the first one it comes too. I personally don't have a scenario like that, so I haven't bothered to check.
Next, for some of you, the keys for the nodes may not be in order going from top to bottom. This is because the keys represent the nodes, and can be used to back track to each node's parent, BUT the order of each node's record, is what determines the Left to Right order of the navigation. In other words....
1000,MyRootNode.htm,0,Home Page,0....(DKDC fields)
In the 'data above', if you put a navigation bar on the home page, and had it list it's child nodes, you would get this:
First Page Second Page
If the data was like this:
1000,MyRootNode.htm,0,Home Page,0....(DKDC fields)
you still have the same data, but now the order is different, you're navigation bar would look like this:
Second Page First Page
That is why the keys are not sorted numerically, and it is also why Line 2 represents the next largest number. Since the 'records' are not in order, Frontpage does not have to run through every record to find the max number, it just uses Line 2's information.
That should be all the information you need to modify (or break <img src=/S/evilgrin.gif border=0 alt=evilgrin width=15 height=15>) your FrontPage navigation structure to your liking. It is also all the information you need to build more dynamic navigations, then what a navigation bar provides. For example, I have already written an .asp SiteMap, which builds a sitemap from the structure.cnf file <!post=Dynamic Site Map,214965>Dynamic Site Map<!/post>. You could create a set of links which backtrack up the node tree all the way back to the root. All easy to do, once you have cracked FrontPage's navigation structure.
Enjoy! <img src=/S/jollyroger.gif border=0 alt=jollyroger width=29 height=18>