Add ability to just generate relative URLs about piecrust2 HOT 5 CLOSED

Hi, why do you need relative URLs exactly?

from piecrust2.

I wanted to publish my site in IPFS.
The site would there be available at, say /ipfs/[insert hash here]/, so a slash would just not work.

For this to work, one would have to use relative url (like ../assets/script.js) to reference files in a parent directory.

from piecrust2.

Huh, interesting, I didn't know about IPFS, thanks for that :)

From what I can tell it doesn't look like you need relative URLs though? I mean you could, just like you could in the HTTP world, but you can also use a site root of /ipfs/<hash>/, like you would with a site root of https://example.org/, no? Or maybe I'm missing something (I'm still trying to wrap my head around this).

I had relative URLs like you mention a long time ago but I removed it because it basically completely fucks up caching and, therefore, performance. For instance, imagine you have a blog post that references some "about" page with pcurl('/about')... depending on whether that blog post is rendered in, say, sub-page 6 of your home page, or its own blog post page, or the 2015 blog archive page's second sub-page, then the relative path to the "about" page could be different, which means the same blog post's text must be re-rendered differently each time (potentially).

So yeah, I cut that feature a long time ago and don't want to add it back, sorry.

from piecrust2.

It is not possible to use the hash as the sites root, because the files content will be part of the hash. By inserting the hash, you would change it.
(You would have to break sha256 for this to work :) )

I don't see how it would break caching.
You just have to know where you are generating the path to a file to be able to generate the relative path.

Its ok you closed this, as I don't really have the time to play with piecrust. Just thought it would be a nice feature. I may come back to this later.

from piecrust2.

It breaks caching because a link from some post to another post will end up having to be rendered differently between the post itself (at /myblog/YEAR/MONTH/SLUG.html), the home page (at /myblog/page3), the various tag listing pages that this post might appear on (/myblog/tags/FOO), and so on. So we can't render the post once and re-use the cached result in all those places.

from piecrust2.