Creating and Implementing a 404 Page

[David Ross]

I want to write and install a personalized "404 Error" page. How
do I do that?

I have over 200 HTML files on my Web site. I'm concerned that, if
I change or move a file, I might not detect all the other files
that link to it and thus require changes. A personalized "404
Error" page would inform visitors to my site how they can help me
correct such errors when they exist.

--

David E. Ross
<http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <http://www.mozilla.org/>.

[Brian]

David Ross wrote:

I want to write and install a personalized "404 Error" page. How
do I do that?
Write the page as you would any other html document. As for how to
set it up, that depends on the server and configuration. If it's
Apache, you can add to the config file (e.g., .htaccess for a per
directory configuration) the following line:

ErrorDocument 404 /error404.html

Change the file name and path to point to your document.
I have over 200 HTML files on my Web site. I'm concerned that, if
I change or move a file, I might not detect all the other files
that link to it and thus require changes. A personalized "404
Error" page would inform visitors to my site how they can help me
correct such errors when they exist.

You shouldn't have to rely on visitors to detect missing files. Use a
link checker.

http://validator.w3.org/checklink

--
Brian
follow the directions in my address to email me

[David Ross]

Brian wrote:

David Ross wrote:

I want to write and install a personalized "404 Error" page. How
do I do that?

Write the page as you would any other html document. As for how to
set it up, that depends on the server and configuration. If it's
Apache, you can add to the config file (e.g., .htaccess for a per
directory configuration) the following line:

ErrorDocument 404 /error404.html

Change the file name and path to point to your document.

Thank you. I did it, and it works like a charm. (Yes, my ISP
uses Apache.)

I have over 200 HTML files on my Web site. I'm concerned that, if
I change or move a file, I might not detect all the other files
that link to it and thus require changes. A personalized "404
Error" page would inform visitors to my site how they can help me
correct such errors when they exist.

You shouldn't have to rely on visitors to detect missing files. Use a
link checker.

http://validator.w3.org/checklink

I bookmarked the "checklink" page. I will try that soon.

--

David E. Ross
<http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <http://www.mozilla.org/>.

[Neal]

"Brian" <us*****@julietremblay.com.invalid-remove-this-part> wrote in
message news:9uRBb.359323$275.1179772@attbi_s53...

Write the page as you would any other html document. As for how to
set it up, that depends on the server and configuration. If it's
Apache, you can add to the config file (e.g., .htaccess for a per
directory configuration) the following line:

As a warning to any "fine people notwithstanding their poor choice" using
Frontpage, I'm told to not try making a htaccess file. You'll end up having
to recode your whole site the right way.

This is second-hand info, so corrections to my statement are welcome.

[Jukka K. Korpela]

"Neal" <ne**@spamrcn.com> wrote:

As a warning to any "fine people notwithstanding their poor choice" using
Frontpage, I'm told to not try making a htaccess file.
I beg your pardon? How would the authoring software affect .htaccess, which
is something that a server uses without even looking at the content of HTML
documents, still less how they have been produced?

BTW, I'm just playing with FrontPage 2003, and it can actually be used to
produce and edit HTML pages pretty well. The problem with FP products is that
their user interface makes it all too easy to produce poorly written pages,
and you need to understand HTML and other Web affairs rather well to avoid
all the pitfalls on your own.
You'll end up having
to recode your whole site the right way.
Well, having to do things the right way isn't really a worst-case scenario in
my book, but I have no idea of what you are talking about.
This is second-hand info, so corrections to my statement are welcome.

It's impossible to correct your statement, since it didn't really contain any
factual information that could possibly be confirmed as correct or proved
counter-factural.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Chris Sharman]

Brian wrote:

You shouldn't have to rely on visitors to detect missing files. Use a
link checker.

http://validator.w3.org/checklink

Doesn't do well with javascript links, in particular it doesn't spot
errors/missing images in the rubbish dreamweaver leaves to preload
rollover images.

Chris

[Eric Bohlman]

Chris Sharman <ch***********@sorry.nospam> wrote in
news:br*******************@news.demon.co.uk:

Brian wrote:

You shouldn't have to rely on visitors to detect missing files. Use a
link checker.

http://validator.w3.org/checklink

Doesn't do well with javascript links, in particular it doesn't spot
errors/missing images in the rubbish dreamweaver leaves to preload
rollover images.

Yet another reason not to *rely* on scripting for a function as important
as linking.

[Steve Pugh]

Chris Sharman <ch***********@sorry.nospam> wrote:

Brian wrote:

You shouldn't have to rely on visitors to detect missing files. Use a
link checker.

http://validator.w3.org/checklink

Doesn't do well with javascript links,

Of course not - they're not links.
Google won't be able to follow them either.
Nor will any user without JS (for whatever reason).

Don't use JavaScript as the only means of reaching a page.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[Brian]

Chris Sharman wrote:

Brian wrote:

Use a link checker.

http://validator.w3.org/checklink

Doesn't do well with javascript links

It doesn't process javascript, period. It is a link checker, not a js
checker.

--
Brian
follow the directions in my address to email me

[Chris Sharman]

Eric Bohlman wrote:

Chris Sharman <ch***********@sorry.nospam> wrote in
news:br*******************@news.demon.co.uk:

Brian wrote:

You shouldn't have to rely on visitors to detect missing files. Use a
link checker.

http://validator.w3.org/checklink

Doesn't do well with javascript links, in particular it doesn't spot
errors/missing images in the rubbish dreamweaver leaves to preload
rollover images.

Yet another reason not to *rely* on scripting for a function as important
as linking.

Well personally, I'd be just as happy to use CSS for rollovers, but the
marketeers have decided they like flashy rollover images, as provided by
Dreamweaver. If you have them, you ideally want a body preload for them,
because a rollover really needs an instant, local, response.
I seem to spend a lots of time chasing down rubbish from Dreamweaver.
Ho hum.
I'd see it as a significant improvement it it processed any strings
found in <body onload=MM_preloadImages('img1',...)> or similar (thereby
better supporting popular web authoring tools). I daresay the even more
dreaded Frontpage does something similar.
I'm not a fan of Dreamweaver, but I do have to work with the pages it
produces.
Suggested to the www-validator mailing address, anyway.

Chris

[Steve Pugh]

Chris Sharman <ch***********@sorry.nospam> wrote:

Eric Bohlman wrote:

Chris Sharman <ch***********@sorry.nospam> wrote:

Brian wrote:

You shouldn't have to rely on visitors to detect missing files. Use a
link checker.

http://validator.w3.org/checklink

Doesn't do well with javascript links, in particular it doesn't spot
errors/missing images in the rubbish dreamweaver leaves to preload
rollover images.
Yet another reason not to *rely* on scripting for a function as important
as linking.

Well personally, I'd be just as happy to use CSS for rollovers, but the
marketeers have decided they like flashy rollover images, as provided by
Dreamweaver.

One of the least elegant rollover scripts around....
If you have them, you ideally want a body preload for them,
because a rollover really needs an instant, local, response.
I prefer to place the preload in the same external .js file as the
actual function. Has no impact on performance and makes the code a lot
tidier.
I'd see it as a significant improvement it it processed any strings
found in <body onload=MM_preloadImages('img1',...)> or similar

How is the checker to know that the above is referencing an image when
the following is not: onload="myFunction('foo')"

Is it supposed to have the exact names used by the DW functions hard
coded into it? What happens if the next release of DW changes those
names?

Or indeed how is it to know that my example does in fact reference an
image? I may be putting together a URL inside the function
imageURL = myDir + "/" + myImg + ".gif"; Is it supposed to have a full
JS parser so it can track down all possible links?

I suggest that if you are using DW to build and maintain sites that
you use the built in DW link checking functions. If they don't check
for the existence of images referenced in DW extruded code then that
is a problem to take up with Macromedia. ;-)

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[J. David Bryan]

On Thu, 11 Dec 2003 09:17:14 +0000 (UTC) in article
<Xn*****************************@193.229.0.31>, Jukka K. Korpela wrote...

How would the authoring software affect .htaccess....
I haven't used more recent versions, but when using the site management
features (e.g., to upload just the changed pages from the local, FP-managed
copy of the site) of versions up through FP 2000, it would:

a) offer to delete any files present on the server that were not present
in the local copy, and

b) not allow local copy file names to begin with a dot (e.g., ".htaccess").

The result was that FP would ask to delete all of the .htaccess files on the
server each time the site was updated from the local copy.

BTW, I'm just playing with FrontPage 2003, and it can actually be used to
produce and edit HTML pages pretty well. The problem with FP products is that
their user interface makes it all too easy to produce poorly written pages,
and you need to understand HTML and other Web affairs rather well to avoid
all the pitfalls on your own.

I concur.
--
-- Dave Bryan

NOTE: Due to unrelenting spam, I regret that I have been forced to post with
an encoded address. Please ROT13 this message to obtain the reply address.
Address also available at http://www.bcpl.net/~dbryan/mailto.html

Cyrnfr ercyl gb guvf nqqerff: wq*****@npz.bet

[Chris Sharman]

[snip]

Dreamweaver.
One of the least elegant rollover scripts around....

If you have them, you ideally want a body preload for them,
because a rollover really needs an instant, local, response.

I prefer to place the preload in the same external .js file as the
actual function. Has no impact on performance and makes the code a lot
tidier.

Oh, no - we use the same external js for many pages, with different
buttons ...

I'd see it as a significant improvement it it processed any strings
found in <body onload=MM_preloadImages('img1',...)> or similar

How is the checker to know that the above is referencing an image when
the following is not: onload="myFunction('foo')"

Is it supposed to have the exact names used by the DW functions hard
coded into it? What happens if the next release of DW changes those
names?

I was trying to avoid getting too dreamweaver-specific (I expect
frontpage & others would benefit from the same/similar functionality),
but yes, I'd see it as appropriate to hardcode MM_preloadImages (or
perhaps anything called *preloadImage*) and change/add as necessary for
future versions.
Or indeed how is it to know that my example does in fact reference an
image? I may be putting together a URL inside the function
imageURL = myDir + "/" + myImg + ".gif"; Is it supposed to have a full
JS parser so it can track down all possible links?
I should have made that clear before, no - general js parsing is clearly
outside the scope of such a tool. I'm just suggesting enhancing the
existing public link check tool to catch a lot more links for a lot more
pages, without getting into general js parsing.
I suggest that if you are using DW to build and maintain sites that
you use the built in DW link checking functions. If they don't check
for the existence of images referenced in DW extruded code then that
is a problem to take up with Macromedia. ;-)

Installed it, played around, hated it, got the free upgrade to DWMX,
hated it the same, binned it. Colleagues still use it though, to build
the 'page surround', and their page contents, and I have to use the
common page surround. I'm also the one that analyses the webstats, and
sees all the 404s, most of which I believe stem from this. If I was
going to take up a problem with Macromedia, it would be 'how about
moving on from ie3/nn3 compatibility, and doing valid & non-deprecated
html4/xhtml+css' ;)

Chris