Forum Moderators: open
The issue: What is an easy/cheap way to reduce the amount of javascript while retaining the automatic generation of nav bars based on the nav view in frontpage.2002 Please please please let there be an easy way ;-)
Background: I have a site with several hundred static pages. The site structure is still jumping around as I add pages, topics and learn more about how people nav the site. I built the site with FP without much knowledge or concern about SEO since when it started it was mostly an informational site without economic concerns. A major reason for using FP was the automatic updating of the navigation structure in my menus. Not losing that capacity is still a major concern. Got rid of my top border with global navigation and put it in the bottom. Some help but left hand border navigation is essential. I have a very vague understanding of sever side includes of java script files and other information to decrease the .js code overhead but I am not clear how that interacts with the nav bot that creates the menu bars. I would have to upgrade my host account to handle SSI but will do it if necessary. Maybe you could sticky mail me with recommended tutorial pages if you are recommending using something like an SSI.
I don't think you need SSI either...instead take control of your content and design by using FP's Include Page. You make your navigation, header and footer pages separately, just like you would for SSI, and then use the Include Page function already provided by FP to place them where you want in your pages. Then when you want to change something globally, just change the included pages and the changes will be reflected site-wide.
Go to Tools>Web settings...>Advanced. Then check "Show documents in hidden directories". Left.htm will then be visible in the _borders folder. Edit and save. You'll have the same menu in all pages that have the left border turned on.
Say one page of your website is a document that you may have a need to place on another page in your site along with other content. If all the navigation, banners, ads, etc. are in the shared borders then the document can be included in another document and only the text will be seen.
On my site I have many pages of links in various categories. I can include any of those pages to articles that I write and never see the link page navigation. When I update the link page both are updated.
I tried to make that clear. I hope it's at least decipherable.
I don't think you need SSI either...instead take control of your content and design by using FP's Include Page.
I agree. That's the way I do it. Not only does it avoid JavaScript bloat, but it also lets me choose and organize navigation links in the most effective way.
At the site in my profile, I use shared borders with include files for the left and right navigation bars; the top border is edited directly.
I have developed a couple of pages using page include for my navigation bars but it appears pretty much the same,(probably did not look close enough) as the code that was generated by having the nav bar in the shared border. When I looked at the source as published. Does the include page work like SSI where it the code is only served to a bowser client and does not show to the spider?
If so I better develop a better site map than just relying on a frontpage generated TOC page.
A related TOC issue, are there ways to effect the formating of the TOC ie. number of levels shown, hiding images etc..
Honestly, I don't know how an SSI works but in FP the include is completed when you save the files. The spider will see it.
A related TOC issue, are there ways to effect the formating of the TOC ie. number of levels shown, hiding images etc..I haven't used this in a while, but I remember that this was controlled to some degree thru the Navigation structure you set up in the Navigation pane.
I stopped using the TOC component on my sites, but for some sites that still have a site map I was able to use the FP TOC page as a starting point. View the page in your browser and copy the source. Then you have the whole list of links and you can format it or reorder it the way you like.
I'd always been a big fan of FP page include until an FP server extension bug last year made pages published by FP unusable. Had to FTP for a month before host upgraded (and before I changed my host).
Made the change from page includes to javascript includes. Have extensive nav links on each page and using the js includes drastically cut page side with no (not much) effect on load time. And by cutting 50 or so links on a page it doesn't distract the spider from the important content and important links.
And easy enough to maintain with Notepad except that I've learned not to do anything at 4:00AM when the eyes are a bit tired.
Jim
You're correct when you say that "As soon as you save a page in FP the changes in the Include Page are processed."
That's find for your local copy. After publishing to the server the extensions take over. If these are buggy you can have big problems.
Check out MS knowldge base articles 299360 and 298827:
"After you upgrade your [UNIX- MSII-based] site to the FrontPage 2002 Server Extensions, the shared borders and Include components do not appear correctly."
Do not appear correctly? What an understatement! How 'bout four occurrences of the main page in each include page component? Times four includes on each page! Kind of unusable.
Our sites were hammered last year because our very, very big well-known host refused to install the available 2002 server extension patches for more than a month. The workarounds noted in the KB articles had to be made at the host FP server extension level above the root web and would last only as long as they didn't do any other routine maintenance.
My only recourse was to FTP entire sites when I made changes to keep the sites stable. If I as so much just opened a live site in FP it went buggy again.
I still have the agita to prove it.
Jim
