Forum Moderators: open
Well, we've come to find out that the external .js file was referencing relative URL image paths. So, if we had a page that sat one level below the root, the path was not correct. We just changed all the external .js to absolute URL's.
Not sure if anyone else is wondering about this one, but this is the fix! Or, is this something that everyone knew?! ;)
Well almost 100%. Still have a navigation structure and physical files and folders. The problem would be calling anything external and the problem you mention.
It came down to thinking that I would have a few "records" in the db for a specific external file (like CSS) like
ID1 Link css.css
ID2 Link ../css.css
ID3 Link ../../css.css etc etc
at least this way you wouldnt have to reference absolute URL's, and the physical space taken on your site won't grow as much as it could using absolute url's etc...
Its one of those neat little probs that makes webmastering sorta interesting :)
What I'm referring to is the actual .js file itself and what it contains. Here is a snippet from the file...
var preloadFlag = false;
function preloadImages() {
if (document.images) {
search_over = newImage("http://www.mydomain.com/images/search-over.gif");
The 404's were occurring because the path for the javascript function was relative (search_over = newImage("images/search-over.gif")). I utilize the FP includes for navigation elements and my top include contains all the graphics. Anytime that include sits on a page outside of the root, the relative paths now become an issue.
I had to make all the image paths in my include absolute also. This allows me to use the one include throughout the entire site instead of putting copies in each sub-directory.
Did I maybe misinterpret your reply?
P.S. It also allows me to drag and drop pages wherever I wish.
[edited by: pageoneresults at 5:51 pm (utc) on June 21, 2002]
Am I missing the point? I'll bet I am ;)
Nick
I don't have single quote marks in any of those URL's. They are all double quote marks. The includes are calling the absolute URL's. The javascript was calling relative URL's. If I have a page within a sub-directory, the relative path image/file.gif does not work. It would need ../images/file.gif. That means putting the images within each sub-directory or even worse level 2 directories ../../images/file.gif.
You don't necessarily need absolute URLs with a database-driven site, though often it is easier. The source of the data shouldn't change anything. You just have to be more careful about keeping track of *what* the URLs are relative to. For example, they will not be relative to the DB or the included file, but to the main script for that page.
If you're using PHP, you can always specify part of the path as a constant, that way you can have a set of local constants on your testing machine that load first, then they override the paths on your live machine.
As for the JS, I think (which is not to say that I *know* ;0 ) pageone's problems come from having the javascript included at different levels in the hierarchy.
/root
/root/sub1
/root/sub2
/root/sub2/sub2sub1
/root/shared-images
the relative paths from pages in /sub1 and /sub2 will be the same, but if you call the same JS file from a page in /sub2sub1, you'll get a 404.
Tom
No, forget single quotes, has nothing to do with it. It's just the way webservers work. (at least Apache)
Anything starting with / is relative to the root. So if your images are stored in a dir called 'images' in the root dir then any call from anywhere to /images/pic.gif will referece correctly.
Anyone care to tell me I'm wrong?
Nick
The file is no longer located in its original dir and all the paths are broken unless you used "/" before all paths originally.
pageone, you shouldn't have to put the http:...etc just starting from /images/something.jpg should be fine. I would imagine that you moved your javascript to some root level dir called js or some such.
Same problem when you are using headers, footers or libs in multiple files stored in a base level directory. If you don't reference your img's with paths from the root they break because the pages they are used on could be anywhere within the tree.
I have my .js in a sub-directory called /javascript/. Maybe that is where the issue lies. I'm still a little iffy on the /images/ relative path as I don't think it will work that way. I'll set up a page over the weekend and do some testing.
I just feel so much more comfortable with the Absolute URL's. Then I don't have to worry about where the reference is, it could be 10 levels deep and would provide a much shorter and definitive URL than lets say ../../../../../../../../../images/.
I forgot to mention, the purpose of me doing it was 1 link for every folder deep the site is. ie 3 links covers all. If I know that ID0 is same dir, 1 is 1 folder up etc, then its easy for me anyways
but I see that using / at the front of a relative URL also works, maybe I should do that instead.
still not sure about the original 404 issue though!
I am sure that is where it came from. If you want to keep absolutes, keep them, shouldn't make a monstruous difference in file size. If it does then test it the other way.
you don't need the ../../../ if you use the way I am saying. They are all relative from the root, which is /. All paths start with root and work their way from there. You img paths would be
/images/file-over1.gif
/images/file-over2.gif
/images/file-over3.gif
that's it. I can't see why it wouldn't work. As I said though, leave them absolute if you don't feel comfortable the other way.
/images/file-over1.gif
/images/file-over2.gif
/images/file-over3.gif
I hate to say that I didn't know that! I thought if I had a page at let's say root/sub/sub/file.htm that using an image reference of /images/file.gif, it would then look in the sub/sub/images/file.gif and not go back to the root /images folder.
When scripting it is a whole different problem because it looks at your servers dir tree and you have to use something like $DOCUMENT_ROOT but that is a whole different conversation.
Got it now pageone? Don't feel bad about not knowing, my site still use absolutes 'cos I havn't changed since I discovered it!
Nick
Nick
jatar_k and everyone else, thanks! I've been building sites since early 1996 and never knew this! I feel embarassed because I'd like to think that I know all the basics, and this sure sounds like something basic.
I'll now spend some time later this evening converting everything back to relative where the images are involved. I'm still keeping my relative URL's for includes and such.
Whodathunkit? /images/
I'll bet that I'm not the only one! ;)
Weird, guess it's just one of those things...
Nick
You are correct! The default formatting for images when using FP is either images/ or ../images. Easy fix, the Find and Replace feature is awesome in FP!
jatar_k and everyone else, thanks! I've been building sites since early 1996 and never knew this!
Basically, this is so because unix filesystem rules apply if running Apache (even if you run it under Windows). You should check out a book on Unix/linux (same rules) for more info. In brief, under Unix:
/ - root dir.
./ - present dir
../ - parent dir.
You can concatenate this so
../../subdir12/file
is a valid path. Given
/img1
/dir1/subdir11/file1
/dir2/file2
/file3
If you're in file1 and you want img1, it could be
<img src="/img1">
or
<img src="../../img1">
If you're in file2, it would be the same absolute path, but the relative path would be
src="../img1"
In file3 it could be
src="./img1"
src="img1"
In other words in unix
ls ./img1
ls img1
Should give the same results.... I wish I were on a Unix machine right now to make sure that's true....
Tom
root/images/file.gif
root/navigation/file.htm
root/javascript/file.js
Since FP can't understand anything between ' ' (single quote marks), I'm able to make the paths relative with the preceding / forward slash. I also believe that because the site is interlinked through various sub-directories that FP realizes that and defaults to absolute.
I've checked all the options in FP and I thought there might have been an area to define "Use Absolute URL's" but no, its not there. Any ideas?
> The default formatting for images when using FP is either images/ or ../images. Easy fix, the Find and Replace feature is awesome in FP!
Just when I thought life was grand and FP was almost perfect. ;)
Nick
<head>
<base href="http://www.domain.com/">
</head>
Of course that would be placed before any external file references.
