Why won't short paths work for images?


(Dave) #1

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?

Thanks,

Dave


(Brad Halstead) #2

Your could try adding a meta tag…

<meta name="baseurl" content="https://www.yoursite.com/">

Don’t know if it will fix it or not but worth a try - site wide meta tag of course :wink:

To me, it is looking for currentfolder/sites/focal… but you’re wanting it root folder/sites/? Is that correct?

Brad


(Dave) #3

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.


(Brad Halstead) #4

Under Site Settings -> Advanced, what is your File Links Are set as?

You could try Relative to DOCROOT but that can be problematic with some stacks (Beware prior to using final build)

You could try Relative to Website Address

You likely tried those already…

Other than that, if those don’t work then you’re stuck doing it the way you’re doing it (report it as a bug I would say) for now.

Brad


(Dave) #5

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.


(Brad Halstead) #6

Is it only on Stacks pages or is it in default styled text or markdown pages as well?

If yes (Stacks only pages) to the above question, it is possibly a YH Stacks issue

If it happens in all 3 page types it is likely a RMS issue

If no (Happens in styled text page and markdown page), then it is a RW issue.

Brad


(Jannis from inStacks Software) #7

I guess every link, which is added through a link selector, will be stripped by RW.

How does your folder structure look like?

/docs/images/photo001.jpg
/page1/docs/images/photo001.jpg
/page1/page2/docs/images/photo001.jpg

Where is the respective html page located, which is referring to the pictures?


(Dave) #8

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.

Really hoping @ben @dan or @nikf will weigh in here.


(Brad Halstead) #9

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

Brad


(Nik Fletcher) #10

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.

—N


(webcore) #11

Why does relative links to images doesn’t show the image in Preview mode with the Web Address defined in the General settings? Am i missing something?

Same if we use a relative links to images in CSS or HMTL code (in an HTML stack for example).


(Brad Halstead) #12

Probably because it has to be exported locally to figure things out or to a test server or MAMP…

Brad


(Dave) #13

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.


(Jannis from inStacks Software) #14

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?


(Dave) #15

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.


(Nik Fletcher) #16

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.


(Nik Fletcher) #17

@dave If you set RW to use “DOCROOT” relative links, your /test/ style links should not be processed at all. Could you confirm you’re seeing that?


(Dave) #18

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.

Cheers, Dave