I think this is a question for @dan or @isaiah since @joeworkman told me that it’s out of his control. I have quite a few sites that, due to corporate policy, must use Absolute paths - and must use short versions (e.g., /docs/images/photo001.jpg instead of https://example.com/docs/images/photo001.jpg).
I’ve noticed that this is possible when linking text, but not images. In the screenshot below, note that the link starts with a forward slash, but this is stripped out in the final code output.
With this in mind, my work around has been to leave the full absolute path in the link inspector and then perform a global FIND & REPLACE using Espresso (http://example.com/ >>becomes>> / ). Is there a better way - or perhaps this is a bug that can be fixed?
Right- I don’t want any of the links tied to a base URL. If it’s done correctly, it wouldn’t make any difference what domain the site lives at. In reality, users will get to it using a legacy non-secure URL (e.g., http://example.com). But, the site will actually reside at (e.g.,) https://example.companyname.com
The site is for a Fortune 250 company- and their Sys Admin is adamant that the site use short absolute links.
Thanks Brad- yes, I’ve tried both ways. Really seems strange that either way (relative or DOCROOT) , I can set links to documents (e.g., PDF, docs, etc.) with a leading forward slash, but not to images. And, I’ve tried several different stacks and methods (e.g., warehoused image, background Jack image, etc.) with the same results.
This looks to be a Rapidweaver issue. Upon further testing, it appears that Rapidweaver always strips out a leading forward slash, regardless of the type of page or link used.
So, the link in the screenshot below will become “docs/test.doc” which makes NO SENSE whatsoever. Why not publish exactly what’s in the link inspector? Unless I’m missing something, setting a Rw project to DOCROOT is pretty pointless if the links generated can’t be made relative to docroot.
Works properly in an HTML stack or an HTML page type… just as an fyi
The other thing I tried is a ./ in the add link interface but I don’t think that’s what you want either as that will point to current directory as the starting destination.
So, to me, it looks like it is something to do with the link insertion part of the interface
Because there’s a few processes that run on all links “depth correct” them. This is a quirk of the system that is not as easy a fix as the issue would suggest.
Thanks for answering @nikf I don’t understand why the processes would strip it out, but I’ll take your word for it.
@turtle - ./ wont’ work. For a site to be truly docroot, the links wouldn’t have the period in front of the slash. I guess I’ll continue to rely on Espresso to replace the protocol and domain name with a / Seems like a lot of extra work - and rather disingenuous to offer DOCROOT as a means of publication when it obviously isn’t generating the correct code.
This stripping is related to the link selector. I guess it would help you when having an input field only. As I am working on a nice Stack like this already, what are your requirements regarding the images? I’ve seen that they have to be applied to some background, correctly?
In about two dozen of my sites, all of the links need to be relative to docroot - so they all have to start with a forward slash. As I’ve long been warehousing all of my documents (anything and everything that I can), but always using a fully qualified domain, it’s going to be easiest to just run my exported sites through Expresso (or Coda2) to replace the protocol & domain name with a slash.
This is a new process sprung on me by the company I work for. But, I’m really surprised that in light of the fact that more people are going https, that it hasn’t come up before.
Regardless of which method one chooses in site setup (Relative to page or relative to docroot), it appears that we have no choice but to insert a fully qualified domain. Which means there will be a TON of work for anyone who has warehoused documents and then decides to change the protocol from http to https (every single link will need to be changed).
If the system worked correctly, it not only wouldn’t matter which protocol was used…it wouldn’t even matter what domain the site is tied to.
The reason it hasn’t sprung up substantially before is because RapidWeaver generates page-relative URLs by default, which mean that they’re determined by whatever domain name is serving the page. So the switch to HTTPS is seamless for most.
Thanks @nikf After ensuring that DOCROOT was selected, I added two links to a page several layers deep within a site.
Text stack > text link = /docs/test.doc
Warehouse Image stack > link = /docs/test.png
As you can see in the screenshot below, the link to the Word document would be pulled up by any visitor just fine. Not so for the link to the image since it’s missing the leading forward slash.
I realize that my situation is not normal (sites not living at the initial published domain) - and I’m okay with it. I really don’t mind running the sites through Espresso - I’ve long had to do this anyway because corporate policy dictates that all CDNs have to run from the corporate network. So, replacing the protocol and domain with a slash really isn’t any extra work. I just figured this must have been a bug that you’d want to fix.
