First of all, I would like to express my appreciation for this project. We have a medium sized (dozens of pages), static, content-only website, using client-side javascript (and document.write :-) to render all the pages. In the past, we have transpiled the landing pages into server-rendered php to minimize delays due to script loading on the client. This has been a bit painful, so we were considering transpiling to javascript for node.pm. However, a pre-rendered site is actually a much better option. Having looked around, most of the other static generators are doing lots of things that we don't care about. We just want to pre-render a sub-set of our pages and serve them up. Eleventy is the only project that seems to address this use case at all well.
However, we have one issue that is causing friction. Our website is content-only, not an app, we do not actually want permalinks. We want the urls to stay the same as before. So "/some-content.html" should be pre-rendered into "/some-content.html", not "/some-content/index.html". It seems there is no easy way to specify this. I have to either manually set each permalink, or parse "page.url" or "page.inputPath" in a template file to set a permalink.
Would it be possible to have a configuration option that avoids all the permalinking, and just outputs the same paths? Alternatively, would it be possible to have a "page.originalURL" which could simply be output as the permalink in the layout file?
I think ours is a fairly common use-case, that will become more visible as eleventy becomes more broadly adopted by smaller sites.
regards,
Al
Would "page.inputPath.substring(1)" always be the same as the original URL? If so, that should be good enough.
For completeness, and to help others that have the same issue, let me document the solution I'm using now. In the layout front matter, I have (we're using EJS for now)
the file front matter does not need to know anything about permalinks.
page.fileSlug does exist at least in collection items.
I do like the idea of a configuration option to handle this, though, especially for the same use-case that you're describing: keeping the URLs the same as some legacy site.
One conflict, though doubtful it would occur very often, is when having more than one file with same fileSlug but with different extensions.
Who wins?
about.pug
about.njk
about.ejs
@jevets I think that would be handled by the warning/error suggestion in #322.
@Rangoli-Software Huh, this is a fascinating workaround. Very interesting!
I did have a discussion with someone awhile back about disabling the “clean url” default setting documented here: https://www.11ty.io/docs/permalinks/ I wasn’t able to find that discussion on the bug tracker though, hmm.
Partially related: https://github.com/11ty/eleventy/issues/244 if you want to upvote that similar request.
I think this is a good thing to formalize this (as a page variable, probably), I’ll put it in the enhancement queue. Can everyone here upvote the top comment?
This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open.
The enhancement backlog can be found here: https://github.com/11ty/eleventy/issues?utf8=%E2%9C%93&q=label%3Aneeds-votes+sort%3Areactions-%2B1-desc+
Don’t forget to upvote the top comment with 👍!
@zachleat Are you talking about #213?
I think it’s reasonable to assume that there are users who will either want to output
/my-favorite-teas/index.html or/my-favorite-teas.htmlThe supposed clean path style is the former because by convention, the index.html in a directory is loaded by a server when requesting the path to the parent directory. This makes it possible to ask for /my-favorite-teas without specifying the HTML extension.
I prefer the extension-less style, for it is less noisy. The file extension in a URI that points to a document is almost always irrelevant for me as a user of a web page.
TL;DR: Provide a way to configure the default permalink style by once providing the pattern that is already used on a per-document/per-directory basis.
For the extension-less style, the trailing slash should be stripped so that Eleventy has the chance to detect duplicates (e.g. /my-favorite-teas is the same as /my-favorite-teas/ as far as Eleventy is concerned).
I also cannot find a discussion elsewhere here, so: +1 for a simple configuration option to disable "clean" URLs. I am @kleinfreund's hypothetical user.
In the meantime, I've worked around this with the following front matter in my base template (my input directory is src/site):
permalink: "{{ page.inputPath | replace('src/site/', '') | replace(r/\\.\\w+$/, '') }}.html"
Hm, I wonder, whether a configuration like Jekyll's would be helpful.
But I don't understand their implementation (even if I can read Ruby enough for it).
RegExp sounds like a bad idea to me …
On the other hand, we have URL constructor which could be used to safely assemble the bits. (Also available in Node.js)
I believe this is solved with #244 right? Can anyone confirm? Does this still need to be in the queue?
I'd personally like to see a project configuration setting to toggle Eleventy's opinion in favor of "clean" URLs, but filePathStem makes this trivial to implement via layout permalinks.
For future visitors: https://www.11ty.dev/docs/data-eleventy-supplied/#filepathstem
Most helpful comment
For completeness, and to help others that have the same issue, let me document the solution I'm using now. In the layout front matter, I have (we're using EJS for now)
permalink: <%- page.inputPath.substring(1) %>
the file front matter does not need to know anything about permalinks.