Absolute Path Problem in DW
Hello,
I've got a problem with absolute paths not working in DreamWeaver. I have defined my site in DW's site definition thing. I am developing a site on a development server running Apache.
When I use SSI's with absolute path, Dreamweaver displays them in design mode. The below SSIs are displayed properly.
<!--#include virtual="/global/includes/
<!--#include virtual="/global/includes/
But, when I try to refer to external files using absolute paths, they do not display in DreamWeaver.
For example:
If I use absolute, <img src="/global/images/hdr_AI
If I use relative, <img src="../global/images/hdr_
Another example:
If I use absolute, <link type="text/css" href="/global/css/global.c
If I use relative, <link type="text/css" href="../global/css/global
I have this narrowed down to something wrong in DreamWeaver as web browsers do not have a problem with my absolute paths. DW obviously knows the site's root correctly since it can find the SSI files. So, why can't it find external css, js, gif, etc. files when linked using absolute paths? Thanks!
I've got a problem with absolute paths not working in DreamWeaver. I have defined my site in DW's site definition thing. I am developing a site on a development server running Apache.
When I use SSI's with absolute path, Dreamweaver displays them in design mode. The below SSIs are displayed properly.
<!--#include virtual="/global/includes/
<!--#include virtual="/global/includes/
But, when I try to refer to external files using absolute paths, they do not display in DreamWeaver.
For example:
If I use absolute, <img src="/global/images/hdr_AI
If I use relative, <img src="../global/images/hdr_
Another example:
If I use absolute, <link type="text/css" href="/global/css/global.c
If I use relative, <link type="text/css" href="../global/css/global
I have this narrowed down to something wrong in DreamWeaver as web browsers do not have a problem with my absolute paths. DW obviously knows the site's root correctly since it can find the SSI files. So, why can't it find external css, js, gif, etc. files when linked using absolute paths? Thanks!
Jason C. Levine
Are you developing locally and publishing to a testing server or developing right on the testing server? I'm thinking your site definition may be just slightly off.
ASKER
At the moment, I am developing and testing on the same server. Once the "skeleton" of the site is in place, I'll being using a development, testing, and multiple production servers.
In my site definition, I have defined a local and testing server both pointing to the same development server. See my Local & Remote Info configuration below. Thanks jason!
Local Info:
Local root folder: \\servername\sites\virtual
HTTP Address: http://servername:900/
Testing Info:
Server Model: None
Access: Local/Network
Testing Server Folder: \\servername\sites\virtual
URL Prefix: http://servername:900/
In my site definition, I have defined a local and testing server both pointing to the same development server. See my Local & Remote Info configuration below. Thanks jason!
Local Info:
Local root folder: \\servername\sites\virtual
HTTP Address: http://servername:900/
Testing Info:
Server Model: None
Access: Local/Network
Testing Server Folder: \\servername\sites\virtual
URL Prefix: http://servername:900/
Meh. That looks right. A few more questions about the site definition:
What is the default images folder?
What is checked off on "Links Relative To"? Whatever it is, change it to the other one and see if that fixes it.
There is a difference in how SSI is called vs. links and images. The SSI is looking at the "server" structure whilst links and images resolve via the URI and I think that's what you are seeing with the dot leaders in DW. The "Links Relative To" is supposed to control that.
What is the default images folder?
What is checked off on "Links Relative To"? Whatever it is, change it to the other one and see if that fixes it.
There is a difference in how SSI is called vs. links and images. The SSI is looking at the "server" structure whilst links and images resolve via the URI and I think that's what you are seeing with the dot leaders in DW. The "Links Relative To" is supposed to control that.
ASKER
Jason,
The default images folder is \\servername\sites\virtual
The "Links Relative To" radio button was set to "Document". So, I changed it to "Site root," but it is still not working when I use abolsute paths.
I don't know if it makes a difference, but under Remote Info, I have not placed any information. So, it is currently set as "Access: None."
If it helps with the troubleshooting at all, the checking in/out of files randomly works and then stops working again. If you want me to post the XML of the site definition let me know. Thanks.
The default images folder is \\servername\sites\virtual
The "Links Relative To" radio button was set to "Document". So, I changed it to "Site root," but it is still not working when I use abolsute paths.
I don't know if it makes a difference, but under Remote Info, I have not placed any information. So, it is currently set as "Access: None."
If it helps with the troubleshooting at all, the checking in/out of files randomly works and then stops working again. If you want me to post the XML of the site definition let me know. Thanks.
>>under Remote Info, I have not placed any information
Makes a difference. Set it to Local/Network and try that.
Which version of DW is this?
Makes a difference. Set it to Local/Network and try that.
Which version of DW is this?
ASKER
I am using DW 8. I also have 2004 MX that I could install if you think it may be a DW 8 issue.
I had the remote info section set up, but removed it while trying to solve this issue. I have set up the Remote Info section again. See the configuration below.
Access: Local/Network
Remote Folder: \\servername\sites\virtual
Refresh remote file list automatically: Unchecked
Maintain synchronization information: Checked
Automatically upload files to server on save: Unchecked
I also have the file check in/out information configured as well.
I also tried changing the "Links Relative To" radio button to "Site Root" again after setting up the Remote Info.
When I make these changes to the site definition, I do not need to export the .ste back onto the dev server's root do I? DW uses my local copy and exporting is only for sharing the .ste with other developers, correct?
I had the remote info section set up, but removed it while trying to solve this issue. I have set up the Remote Info section again. See the configuration below.
Access: Local/Network
Remote Folder: \\servername\sites\virtual
Refresh remote file list automatically: Unchecked
Maintain synchronization information: Checked
Automatically upload files to server on save: Unchecked
I also have the file check in/out information configured as well.
I also tried changing the "Links Relative To" radio button to "Site Root" again after setting up the Remote Info.
When I make these changes to the site definition, I do not need to export the .ste back onto the dev server's root do I? DW uses my local copy and exporting is only for sharing the .ste with other developers, correct?
>> When I make these changes to the site definition, I do not need to export the .ste back onto the dev server's root do I? DW uses my local copy and exporting is only for sharing the .ste with other developers, correct? <<
Correct.
If this is DW 8, have you applied the patch yet? It may resolve this.
Correct.
If this is DW 8, have you applied the patch yet? It may resolve this.
ASKER
I've installed the patch to 8.01...
Aside from rebuilding the cache, that's everything I can think of.
I still think the difference between DW and production is what is going on (chroot). Technically, /global/css/global.css and ../global/css/global.css are BOTH relative paths. /global is site root relative and ../global is document root relative. To DW, an absolute path is http://yoursite.com/global/
Not sure what else to tell you. If publishing the production server works with ../, then I would leave it alone. Otherwise, you can tell community support to delete/refund this question and pose it again and see if someone else has a better answer.
I still think the difference between DW and production is what is going on (chroot). Technically, /global/css/global.css and ../global/css/global.css are BOTH relative paths. /global is site root relative and ../global is document root relative. To DW, an absolute path is http://yoursite.com/global/
Not sure what else to tell you. If publishing the production server works with ../, then I would leave it alone. Otherwise, you can tell community support to delete/refund this question and pose it again and see if someone else has a better answer.
ASKER
Hmm... I installed DW MX 2004 and removed the .. from the external references and it works correctly. I imported the same site definition I made in DW 8.
I wonder if this could be a bug... ?
I can't to use document relative links as the SSI's files have external references that require site root relative paths.
I wonder if this could be a bug... ?
I can't to use document relative links as the SSI's files have external references that require site root relative paths.
>> I wonder if this could be a bug... ? <<
DW8 is somewhat buggy, but the bugs tend not to be show-stoppers, so patches are not a high priority. It's starting to look like you found one.
DW8 is somewhat buggy, but the bugs tend not to be show-stoppers, so patches are not a high priority. It's starting to look like you found one.
ASKER
Hrm, there are similar bug reports on Macromedia's website as emerging issues for DW 8. See http://www.macromedia.com/go/54d76ef .
I'm wondering if the fix in the DW 8.0.1 upgrade ended up causing the issue I'm having now. I'll try removing the 8.0.1 upgrade and see what happens then. Thanks for your help Jason. I'll leave this question open for a few days to see if anyone else knows a 'work-a-round' or anything.
I'm wondering if the fix in the DW 8.0.1 upgrade ended up causing the issue I'm having now. I'll try removing the 8.0.1 upgrade and see what happens then. Thanks for your help Jason. I'll leave this question open for a few days to see if anyone else knows a 'work-a-round' or anything.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well, I'm fairly certain it is a bug in DW 8.0.1 because it works all other versions of DW without any problems. I submitted the information to Macromedia/Adobe. Thanks for your help! I would of spent forever trying to figure out why it wasn't working.