Welcome to WebmasterWorld Guest from 188.8.131.52
All my includes, .css and image files are coded as;
I changed one test page to *.jpg and it worked, but I really don't want to change and upload over 3,000 pages.
Support told me to changing them to ./*.jpg
That works too, but same problem.
Is this an Apache config problem?
<img src="/readrin2.gif" alt="readers web ring image" border=0 width=116 height=79 vspace=3></a>
are not working?
Does your regular navigation work?
Is it of the same form?
The above form in this case requires that the file readerin2.gif be in the document root.
Can you show us the configuration file things might be a little off.
Options -Indexes FollowSymLinks Includes ExecCGI
Name changed to protect the guilty etc ....
Works correctly using your /aaaaa.jpg form.
[edited by: theBear at 12:12 pm (utc) on Aug. 2, 2007]
Tell them to fix this immediately, or you're leaving. If they can't get DocumentRoot right, you are going to have nothing but trouble with them...
If your page is at the Web root (i.e. in the "home page" directory), and it references any of these, they should all resolve to the same file:
That is a fundamental requirement, unless you want to be forever tweaking every page and every script you put onto this server... And if you don't have the source code for a script and can't modify it, you won't be able to use it at all.
I'm trying to look at the sites using IP addresses
I couldn't test the navigation very well because I haven't changed the nameservers at the domain host. And since I use absolute links, they point to my live sites on the existing server.
They believe it is a DNS issue.
I don't know where he got his server from but it wouldn't be the first place to have brand spanking new servers with brand new up to date software that is out to lunch on its defaults. Let alone the hosting providers staff being out to lunch or is that just plain out of it?
It does make one wonder though doesn't it.
It's probably just some kludge they've got for IP-based access before the real hostname goes live. That pretty much takes away the appeal of being able to work on the site using its IP address or some back-door URL like "hostname.com/user/"
I sure wouldn't want to have to change something as basic as on-page links just to be able to test on a new server before going live!
It could be so many things I wouldn't even want to list them.
There are probably as many fouled up web hosting providers as there are grains of sand on the beaches. But to be fair (Why I would want to be fair I don't know.) I have seen plenty of messed up default templates provided by the software folks, the dns server folks, and so on down the line (Anyone want to discuss forum software and shopping carts systems? I thought not.)
I'm sure the the old one knows exactly how to wield his ordinance.
[edited by: theBear at 10:31 pm (utc) on Aug. 2, 2007]
I added a series of pages to a site. The site is set up in directories to separate content, other files and includes
I added the series of pages, and put a link structure at the bottom of the content to page i.e
I noticed that images were not showing on page 2. Neither were styles working. But head.php, foot.php, menu.php were being included.
I finally tracked the problem to a cut-and-paste issue. One of my links was:
(note the '//' in filepath)
Okay, I can understand that I might get a 404, but why will I get the /inc/ working but not the /other-files/
So was the original problem fixed, or just masked?
Am I being overly paranoid?
On Apache, the URL-path
is identical to
So normally, things should work even with double-slashes all about.
However, things like anti-hotlinking code, scripts that check requested URLs and are picky about it, or a host's mod_rewrite applied to your directory could conceivably break when double-slashes appear in the URL-path.
The only way to tell is to test several of your broken-CSS-and-image cases, and examine your server error log to see what error the server reported in each case. That will single out the problem or narrow it down considerably.