{{baseUrl}} in boilerplates is not behaving as an absolute URL

[damithc]

v2.5.2

Context: {{ baseUrl }} should resolve to the root of the site, which gives us a way to specify an absolute URL within the site.

Expectation: In a boilerplate file, a URL is resolved relative to where the file is included. However, sometimes one needs to specify a fixed URL inside a boilerplate. Suppose the following two lines are in a boilerplate file.

<include src="index.md" />
<include src="{{ baseUrl }}/index.md" />

The first one should resolve to different files based on where the boilerplate is used whereas the second one should resolve to the same file no matter where the boilerplate is used.

Problem: both URLs seem to vary based on where the boilerplate is included.

[damithc]

@sijie123 any advice?

[sijie123]

Hmm, I'm not sure how boilerplates interact with the URL-rewrite process.
I don't really know how boilerplates work, but here's what I think:

normally (i.e. not using boilerplates), we want to know where the included file is, so that we can make relative references to that file.
with boilerplates, we kinda want the opposite - we don't really care where the included boilerplate template is, we want to know where the source ("includer") file is, so that we can replace content as if the boilerplate never happened.
Yet, both use the "include" syntax, with boilerplates containing an extra boilerplate tag.

In light of this, perhaps we can check if the include tag contains the boilerplate attribute. If so, we wrap with the context of the includer file. Otherwise, we wrap with the context of the included file.

[damithc]

I think the rule should be, any URL that starts with {{ baseUrl }} should be considered an absolute URL. Links seem to follow this rule e.g., [click here]({{ baseUrl }}/index.html) but <include>s in boilerplate files don't seem to follow it.

[acjh]

Note: It should be "relative to baseUrl" rather than "absolute URL".

If baseUrl is set to MarkBind, then:

• {{baseUrl}} is relative to baseUrl, e.g. https://github.com/MarkBind/index.html
• / is relative to domain, e.g. https://github.com/index.html
• // is absolute URL, e.g. https://index.html

[ang-zeyu]

I can't seem to reproduce this, was this fixed some time ago?

[damithc]

I can't seem to reproduce this, was this fixed some time ago?

Doesn't seem to be fixed. Steps to reproduce:

Suppose we have this _markbind/boilerplates/b.md:

<include src="foo.md" />
<include src="{{ baseUrl }}/bar.md" />

Add <include src="b.md" boilerplate /> in other pages in different folders.
Expected: Each time, the page should include foo.md in the current folder but bar.md in the root folder.
Actual: Cannot find the bar.md

I also tried the following, but didn't work.

<include src="foo.md" />
<include src="/bar.md" />

[openorclose]

This doesn't seem to be a problem with boilerplates:

Suppose we have this in root inc.md:

**No special content**

and in root also index.md:

<include src="{{ baseUrl }}/inc.md"/>

This doesn't work as well.

This is because during the parsing stage (where includes are handled), we still do not know where the baseUrl is, and can't locate the required file.

[ang-zeyu]

Ahh, my mistake, I tested it with an <img>.

Reason being there are a few quirks in the preprocess process I found in #1026.
They likely aren't related, but I'll look into it!

This is because during the parsing stage (where includes are handled), we still do not know where the baseUrl is, and can't locate the required file.

👍 Thanks for the info!

[ang-zeyu]

Found the likely issue, which is slightly related to point 5 in #1026 (comment)

To add, this issue also occurs with panels, and dynamic includes ( which are converted to panels ).

Details

As @openorclose mentioned, we still do not know where the baseUrl is, but this should not affect locating the file on the disk, since during `markbind build`, the directory structure is as if `baseUrl` is not present.

_rebaseReferenceForStaticIncludes attempts the first stage of url conversion ( converting baseUrl into hostBaseUrl/... ), but isn't executed for anything other than includes with hashes which's included file is a .md file. This is necessary because the ... needs to be resolved, should the file belong in a subsite.

Once we've fixed this, we can add a simple regex check for baseUrl and hostBaseUrl for include preprocessing, and remove the appropriate pattern, which gives us the actual file path on disk.

After #1026 would be a good time to include this fix in

I could send out a seperate fix before that as well otherwise if needed, since it'll likely take longer to be reviewed