Borders do not show up on published web site.

Before I start, here is what I am using:

Windows 2000 Pro SP4
FrontPage 2002 SP3
FrontPage Server Extensions 2002
Internet Explorer 6
Firefox 1.0.4

And although I have a lot of experience with networking, I have almost none with setting up web sites.

For the few months I have been working on an internal web site for our workgroup. Now I am ready to publish the site.

I pulled an old Proliant 1600 out of mothballs and loaded Windows 2000 Workstation, Internet Information Services, and FrontPage Server Extensions 2002. Nothing else is running on this system and the event logs are clean.

I used FrontPage to publish the web site to the server. The web site publishes fine. But when I try to access the web site, the top, left, and bottom borders are replaced with the main body of the web page. The top border is supposed to have the standard banner, the left border should have navigation buttons, and the bottom should have the standard copyright notice.

The images in the borders are broken too. The images are in:

//MyWebSite/images/Vision.gif

But the borders are looking for them in:

//MyWebSite/_borders/images/Vision.gif

That is everything that I have for now. I am working on the system looking for more clues. If there is any advice that you can give, that would be great.

 

This is a classic problem when creating a web site locally and then publishing it up to an internet site. The problem comes from using absolute URLs for links and images within your site rather than relative links. This is a problem that Frontpage is particularly prone to in my experience (with 2000 I admit), and is one of the reasons I stopped using it (the other ones being the over complicated code it creates and the awful way it handles styles - when will Microsoft embrace CSS!)

Once you've loaded a parent page, links to other pages on the same site don't need a full URL, but rather just a relative URL. For example, say your opening page has links to another page on your site:

Opening page: www.mysite.com/index.html

Other page: www.mysite.com/myphotos.html

If you created a link to the other page in the opening page using a full URL it might look like this:

<A HREF: "http://www.mysite.com/myphotos.html ">My photos</A>

But, this link will not work on the local copy on you hard disk where the URL to the correct document might be "\\mypc\website\myphotos.html ". So you'll have to either manually change all the URLs when you publish the site, or hope your publishing tool is clever enough to do it for you (obviously yours isn't).

However, your browser already knows the first part of the URL as it has it from the parent document. So in fact you don't have to use the full URL in the anchor code. Instead you could use the simpler:

<A HREF: "myphotos.html ">My photos</A>

If you don't specify a path your browser will assume the document is in the same location as the parent.

You can even use this for links to documents in sub-folders. Say "PhotosOfMe.html" is in a subfolder called "ItsMe ". Rather than the full URL:

<A HREF: "http://www.mysite.com/ItsMe/PhotosOfMe.html ">This is my ugly mug</A>

You can use:

<A HREF: "/ItsMe/PhotosOfMe.html ">This is my ugly mug</A>

But how do you get back to index.html from PhotosOfMe.html you may ask. Well you can use the ".." notation to step back up a level. So in the PhotosOfMe.html page you can use:

<A HREF: "../index.html ">Back to home</A>

to get to the starting point. You can even combine the two. Say you keep your icons in an icon folder. To reference them in PhotosOfMe.html page, you can use:

"../icons/bluebuffon.gif "

This will step you back to www.mysite.com or //mypc/website/ depending which the parent is in, and then step you forward into the icon folder.

You may be able to alter the front page publishing settings so that it will correctly convert the paths when it publishes the site/pages. However, I suggest that a much more robust and neater solution is to use relative links instead.

 

Thanks for taking the time to write.

I may have misled you a little. The URL actually looked like this:

http://nnn.nnn.nnn.nnn/_borders/images/Vision.gif

I edited out the IP address and replaced it with a name. Sorry.

I just fixed the problem this morning. It was a server side issue. I un-installed and re-installed IIS, and then re-installed the FrontPage extensions.

You bring up some valid issues that I noticed while developing this site. I used to be a programmer, and I hated the quality of the code that FrontPage was producing. I also did not like the fact that I had compatibility problems with Firefox.

I would like the site to be viewable to both browsers. I tried to migrating the site from FrontPage to Mozilla, but that did not go so well. If I could figure out how to do it, that would be great.

 

In the browser an IP address is effectively a special domain name. "127.0.0.1" is the special name of the web space at the IP address 127.0.0.1, so I think my comments aren't effected by that. Instead of:

http://nnn.nnn.nnn.nnn/_borders/images/Vision.gif

from http://nnn.nnn.nnn.nnn/index.html you can link to the gif using:

/_borders/images/Vision.gif

However, it's also clear from your response that I was barking up the wrong tree anyway.

My personal view is that a GUI based web writing (I hate the word authoring) tool is great for quickly getting a document up and published, or providing a useful starting point, but you need to get into the code if you're serious about producing a good website that easy to keep up to date. Tools like dreamweaver appear to allow you to combine GUI creation with code tinkering, but the best ones (dreamweaver being a prime example) are exensive I think. For professional developers the time saved in using a professional quality GUI driven app will cover the additional cost, but for amateur hacks like me, it's too much.

My editor of choice is Actipro's SpiderWriter. It has GUI functionality, but it's best feature is the code editor with syntax highlighting and wizards. I even use it to write the VBScripts I use to manage my Win2003 network.

Frontpage's reliance on frontpage extensions is a problem and definitely limits portability. There's very little you can't do with a combination of HTML, JavaScript, and CSS and these are open standards and very portable. Add server side scripting with PHP (though I admit I tend to use ASP) and you've a huge bag of tools to do all sorts of things.

However, I don't know of a simple way of converting a site that use frontpage extensions into a more compliant system. Manually rewiting the site may be difficult.

 

This is quite a nice comparison of Web writing software.

 

Thanks for all of your time.

I will take a look at some of the editors that you mentioned. I will do some more research on the best way to migrate off of FrontPage.

Unfortunately for me, I have no HTML experience. So migrating manually will e difficult.

 

Dont feel like the Lone Ranger buddy. Me neither.