are you linking to file: protocol or http: protocol?
Can you navigate to the actual files and open them? Computer default settings sould open any html file in your browser, but your settings may vary. Can you open the files in a text editor that has html editing and browser viewing features like Notepad++ (or similar for Mac)?
@phranque I link to the files like this <a href="foldername/">.
I tried it with both the index.html and without, relative vs absolute urls, etc. I also tried it with http:
@not2easy No I can't navigate to the files. I'm on a Mac. Alll other 50+ domains are set up the same way and they work fine.
I open the html file in BBedit, tell it to preview in firefox or Safari and get that error message.
thanks for trying to help folks.
is your "home page" in /Users/myname/documents/----nameofdomain.net/index.html?
(hey! happy 12th anniversary on WebmasterWorld, Lorel!)
I use Mac and BBEdit too, I once found that there was a "parallel" copy of my domain folders that was a product of BBEdit (not something I had set up) that was set up to use the Terminal.app. I do have a MAMP install, but never set up domain files to work with that unless I'm doing some specific testing. It is something BBEdit did by default and I am sorry I don't recall the specifics of turning that off. I would look for assistance via BBEdit if this seems to be the same thing. Is your Terminal.app active when it gives you that error message?
Now I just make sure to keep domain files in specific folders and only edit and view from those folders.
|I tried it with both the index.html and without, relative vs absolute urls, etc. I also tried it with http: |
I'm on a Mac.
With/without "index.html" makes a difference, but it's a non-fatal one on the current Mac. If you leave off the "index.html" and link to a bare directory-- the way you would do on a "live" site-- the computer will show you the directory listing. You then have to manually find and click on "index.html".
Relative URLs are useful for testing, because your browser parses them without needing a server. But remember to change the ugly ones (like "../../otherdir/whatsit/filename.html") before you go live.
|I link to the files like this <a href="foldername/"> |
That only works if the link is in a document that's physically located in the same folder as "foldername/". Is it?
|Firefox can't find the file at /Users/myname/documents/----nameofdomain.net/name of folder/ |
Then the two questions are:
Where is the previous document (the one that contained the link leading to the error message)?
Where is the target document really located?
Is the current Mac OK with literal periods in folder names? I can't remember one way or the other.
I haven't seen any problem having filenames with periods. I have accidentally created a few "whatever.txt.txt" and they handle OK. I rename them, but not because they have problems other than weird looking filenames.
Filenames, sure. I meant directory names-- especially ones that will be part of a longer path.
It doesn't seem to mind if I make up a few at random, though. They're permitted in URLs, so I guess there's no reason to think local names would be any different. This isn't the 8.3 days after all ;) But I still think it looks weird.
@phranque I didn't even realize it's been 12 years. Yes that is the url to my home page.
@not2easy I haven't used the terminal.app on bbedit but will check into it if nothing else works. The thing that is odd is that the same set up is in all my domains/folders. This is the first time I had a problem like this.
@lucy24 I'm not on the newest Mac - I'm on OSX 10.7.5.
each folder has it's own index.html I don't use periods in folder or directory names.
These 3 folders used to be in my main website file where the main index links to the folder same as I have it set up now, i.e. like this :
my main site
end of my main website
I've tried including index.html on each folder name but that doesn't work either.
The new site is set up the same way.
Thanks for trying to help folks.
I am also on 10.7.5. though the problem I had was probably on a previous OS. I know it was also a previous version of BBEdit, it had to be in 2011 when that happened. I was not using the Terminal.app, BBEdit had set up copies of the files I was working on all on it's own in a folder in my Users/username/ directory but I saw that the Terminal.app was active when I got that error.
It seems to me that I fixed the issue by using the LiveHeaders Extension to see where the browser was trying to access the files it couldn't find.
|I'm not on the newest Mac |
The behavior I describe (showing the index listing when you request the bare directory in a browser) has been the same since at least 10.6.8, so that's not an issue. The point was simply that links to "/directory/" and links to "/directory/index.html" will both work with local files.
Let me make sure I'm getting this. You have a page, let's call it index.html, which represents the front page of one of your domains. On your hard drive, this file is located at
You then have some other pages, representing assorted subdierctories. On your hard drive, these are located at
and the links from the first index page are expressed as
<a href = "subdir1/index.html">
<a href = "subdir1/">
and these links don't work when you open the local file in your browser?
Or am I completely misunderstanding your situation?
@not2easy Can you explain how you saw that the terminal was active when you got the error? And where did you find the extra copies of the files? I clicked on my user name and checked the folders in my documents folder (where I save all data except applications) and everything looks normal. I turned on the Activity monitor and tried to open that page again but not sure what to look for.
@Lucy24 I use the same formatting as on multiple other domains I work on.
BTW, just to clarify, when I want to view the files in a browser I am viewing the html page in BBedit and then go up to Markup (in the top menu) and select one of the browsers. The home page opens in the browser. but the links on the home page bring up that error message.
The index file for the new domain is located here:
that one works and loads the home page for the domain.
Trying to open an index page within that folder doesn't:
/Users/myname/documents/----nameofdomain.net/name of folder/index.html
The browser says "no file exists at the address" .
BTW, I just opened a new browser window and navigated to one of the folders inside that new domain folder and the page opened, i.e., bypassing BBedit to open the page.
So perhaps the problem is within bbedit. All other domain files open correctly however.
my guess is when bbedit opens the browser, the browser loses the context of the index.html file and therefore relative urls don't work.
that's kind of a useless test environment in any case.
you should have an actual web server (local or development) for testing web pages.
do you have spaces in your folder names?
@phranque I've tried full URLs also with the same result.
I"ve looked into have an actual web server for testing web pages but don't see the need when they work just fine on my computer (usually).
there are no spaces in the folder names.
What happens if you simply open the files directly in your browser?
You don't need a production server for testing. Just get the free version of MAMP. It's a normal Mac program; no nasty stuff involving Terminal.
|@not2easy Can you explain how you saw that the terminal was active when you got the error? And where did you find the extra copies of the files? I clicked on my user name and checked the folders in my documents folder (where I save all data except applications) and everything looks normal. I turned on the Activity monitor and tried to open that page again but not sure what to look for. |
I could see that the Terminal.app was active in the Dock at the bottom of the screen. The little 'light' thing showed it was active.
I found the files were in a folder in my Home (Username) Directory, not in the Documents Directory that I thought I was working in. I found that by clicking on the FilePath button in the upper left corner of the page I was viewing in BBEdit, copy and paste it into the page to find the version that BBEdit had loaded. It looked the same as the one I had thought I was working on.
I found a complete up to date version of all the files I had been working on, but not all the files in the working folder. It sounds like the same kind of issue, sorry I didn't keep any notes on it. I know that BBEdit has command line tools, but I never intentionally used any of those. Not saying I didn't set something that caused it, just don't know what it was.
I was not using the Activity Monitor, I use a Firefox Extension called LiveHeaders to view server requests and it works when you're using Firefox to Preview files. The LiveHeaders also showed me the path where it was looking for the file that was not found. It was a non-existent folder. I have looked all over and not found any notes on the issue, but I just looked back at that folder and the files in it are from 2010. I never deleted those files, but they are in a Directory named Sites in my (Username) directory.
@not2easy I opened the file and watched the Dock and terminal does not appear so it might not be the same problem.
Both My home and username directory is "documents"
I haven't been using Preview in BBEdit. I use Preview in Firefox, etc.
There is no "file path" button in upper left corner when viewing
the page in bbedit (or location bar).
I loaded the home page of my main website the same way and the file paths both look the same (coming from users/mynmae/documents/ etc.
I also have the live headers extension in firefox but it's not showing anything on either website. It only shows data when the website is online and this one isn't online yet.
---- to all who have tried to help
I sent a message to BBedit to see if this problems is within the program. I'll let you know what they say.
from an earlier post: BTW, I just opened a new browser window and navigated to one of the folders inside that new domain folder and the page opened, i.e., bypassing BBedit to open the page.
I'll check into MMAP