Support ugly urls

[kellpossible]

As discussed in #635, it would be nice to have an option similar to Hugo's uglyURLs, to enable pages to be rendered out as /foo.html instead of /foo/index.html, this will have a couple of benefits:

• backwards compatibility when porting another website to zola which uses this url scheme, and for which you wish to keep the old url's alive (I'm currently porting my personal website/blog which was using Pelican and this scheme)
• help support any future efforts to enable for browsing the site on a local file system

[piaoger]

It's quite useful to deploy the static site on cloud stoages directly, such AWS S3, Aliyun OSS ...

[kellpossible]

@piaoger that's quite a strong reason I didn't think of!

[Keats]

The currently URLs should work just fine on S3 if you are not using CloudFront and you can use something like https://github.com/CloudUnder/lambda-edge-nice-urls if you do use it.

[rotty]

I'm not sure if it really fits in with this issue, but I just played around with converting my site to Zola, and ran into an issue which I think is related. I need to create an RSS feed for a specific section, and tried solving it by a using a custom template, based on rss.xml builtin. However, there is no way to force the output to be the desired path; what I'd like to be able to do is something along these lines:

$ ls -1 content/blog/
... index.rss.md ...

Now in index.rss.md, I'd just have frontmatter, like this:

path = "blog/index.rss"
path-verbatim = true # This setting is missing
template = "blog-feed.xml"

If the proposed path-verbatim setting existed, I'd be one step closer to getting where I want; I suspect there would be issues due to RSS feed generation being special-cased, and hence the template not having the information it gets when it is used in "RSS mode", but that is a separate issue.

To generalize a bit, I think it should be possible to make use of the tera engine for non-HTML content, and thus one would need to be able to influence the resulting path name precisely. This would incidentally also solve this issue as raised by @kellpossible, IIUC. However, setting path-verbatim in and path in the frontmatter of each page would probably be less than ideal for that use case, and I imagine some kind of global setting would be a better fit. For my use-case, on the other hand, it is crucial to be able to set this on a per-page basis.

Edit: Alternatively, for my use-case, it would suffice if, when a a template with a non-html extension is specified, that would automatically imply path-verbatim = true. The path-verbatim setting wouldn't even need to exist then. Currently, it seems Zola strips the extension of the specified template, and adds .html instead. Such a solution would do nothing for this issue, however, hence I'll open a new one to discuss non-HTML templates.

[Keats]

Hmm so for that specific usecase I think it would make sense for section to be able to have a rss = true setting that automatically create a RSS feed for that section which could use its own issue.

Let's discuss the rest on #905

[NatTuck]

Not having ugly URLs for pages makes asset colocation weird. For example "foo.md" needs to link to "../thing.txt" to reference an item in the same directory.

[Rantanen]

I was thinking of moving over from Hugo to get better experience when editing Markdown files. Hugo has the problem that its shortcodes use {{<foo name="bar" id="baz">}} syntax that causes issues with normal Markdown preview as everything within the angle brackets gets parsed as a HTML tag.

Zola's choice for shortcodes is better in that regard, but the inability to link to image files with a simple ![Foo][image.png] keeps me away from Zola. Using ../image.png or @/... would work, but breaks the image linking when viewing Markdown preview outside of Zola.

The use case here is internal project documentation that should be easy to consume but also easy to update on the fly, thus Edit this page links everywhere that open the Markdown files in an online Markdown editor.

[Keats]

![Foo][image.png] should work for colocated assets? At least I'm using it in https://github.com/Keats/vincentprouillet/blob/master/content/blog/2018-11-17_releasing-zola-0.5.0/index.md

[Rantanen]

Yeah, co-location is only supported when the Markdown page is called index.md, otherwise images break.

Having a directory for every single page gets noisy when there are several sections with limited amount of pages in each.

But I can appreciate this use case is limited to specific kind of sites and not necessarily applicable to blogs.

[dureuill]

FWIW, I opened a branch with some preliminary support for "ugly urls" in a personal clone of the zola repository: https://github.com/dureuill/zola/tree/page_name_url

I'd open a PR, but the contribution page says something about opening a thread on the forum before opening a feature request PR, and I kind of saw that... after doing most of the work on my branch. TBH this made me unsure of what to do, and lose impetus :stuck_out_tongue:.

The current branch is able to generate URLs of the type section/foo.html for a Foo page, instead of section/foo by passing the url_mode = pagename config option in config.toml or to zola build/serve. There might be unexpected interactions with some parts of zola, or just dumb mistakes from my part, I don't know the codebase enough to say for sure. URLs are only changed for pages, not for sections nor other taxonomies.

BTW I found the zola codebase very clean and easy to hack on, so props to the maintainers :+1:.

[Keats]

Honestly I'm not sure enough people want that feature to be worth merging. I've seen quite a few people asking for that just to be actually fine with pretty URLs.

BTW I found the zola codebase very clean and easy to hack on, so props to the maintainers

🙇

[rpearce]

Honestly I'm not sure enough people want that feature to be worth merging. I've seen quite a few people asking for that just to be actually fine with pretty URLs.

I dig zola! It's just what I need, except not having this functionality is a deal-breaker for me to use zola at the moment, unfortunately.

Historically, a number of scraping services (e.g., Twitter & Facebook just a few years ago) had issues with /my_page/index.html when being linked to as just /my_page or even /my_page/. I've built to regular old named HTML files since then and haven't tried emulating regular server routes for static sites.

Separately, and more to my use case, I'm using zola to manage part of a static site, so if the rest of the site uses a my_page.html format everywhere, but this one area doesn't, it's a little weird.

---

That said, this project is great, and if it's not worth it to you to add a configuration feature for this, no worries! I appreciate everything you've done already. :purple_heart:

[sethm]

I'd like to offer another vote for this issue. I'm interested in migrating an extensive website that's been around for a long time from a hodgepodge, home-made static site generator to Zola, and unfortunately almost all of the URLs are HTML pages, not directories with index.html in them. Doing the migration will result in either a huge number of external links and search results ending up in 404s, or I'll have to come up with a large nginx config full of permanent redirects to get people redirected from the old layout to the new layout.

I don't think this is super urgent, though. The migration is going to be a very significant and unavoidable amount of work anyway, so the extra work of building an nginx redirect map is probably not a dealbreaker for me!

[Keats]

@sethm you could write a script to add an alias automatically to the front-matter, which would redirect to the new URLs

[orlp]

I would really prefer 'ugly' URLs over /index.htmls everywhere.

[dennisse]

I also really want "ugly URLs". I think they're a lot prettier. So I made this small (z-)shell-script as a workaround.

#!/usr/bin/env zsh
setopt globdots errexit pipefail

local tmp=$(mktemp -d)
trap 'rm -rf $tmp' EXIT

for f in public/**/*.html(/N); mv $f $tmp && mv $tmp/${f:t}/index.html $f

grep -lR '\.html/' public/ | xargs sed -i 's-\.html/-\.html-g'

I just run this from the zola root-dir before publishing, and voila, ugly links. edit: Forgot to add that I also name my content-files with the suffix .html.md, or give them a path that ends in .html.

[paddlefish]

I'm trying to host zola-generated content on AWS S3 with CloudFront distribution in front of it. Sadly, CloudFront with an S3 origin doesn't automatically just deliver + "/index.html"

I'm surprised that zola assumes that a link to some/path will automatically be expanded by the web server to deliver some/path/index.html.

If "ugly URLs" is not an option -- what about make it possible to generate "really ugly links" like this: <A href="path/including/index.html>? Right now the beautiful links don't include the /index.html.

I'm not sure I will be able to deploy this site the way I was hoping to. I might have to use the trick suggested by dennisse, but I don't love the idea that out of the gate I need to "fix" things with a post-processing step.

[Keats]

I'm surprised that zola assumes that a link to some/path will automatically be expanded by the web server to deliver some/path/index.html.

It's the convention, pretty much every web server redirects to index.html on directories (or default.html).

Looks like you can handle it either in cloudfront or s3 directly with an index document

[dmolesUC]

+1 to this feature request. I work in academia, where at least some of us try to keep existing URLs working — sometimes for decades — and the inability to generate <basename>.html instead of <basename>/index.html is a definite barrier to moving old static HTML sites to Zola and Markdown-based repos.

(Maybe I'm just showing my age, but conceptually it seems weird to me that Zola, Hugo, etc. want to create all these extra directories and index.html files, instead of trying when possible to preserve the directory structure of the content directory and a one-to-one <path>.md ↔︎ <path>.html correspondence. I'm sure there's a good reason for it that I missed when I dropped out of web development after Netscape 4.5 and didn't come back till ES6, but it's weird.)

[Keats]

I'm sure there's a good reason for it

2 things:

1. A lot of people prefer not seeing the .html
2. How do you handle colocated assets if you're not creating folders? Any colocated asset in a page of the same section can now overwrite each other (eg content/posts/react/example.js and content/posts/solid/example.js would correspond to posts/react.html and posts/solid.html. What about each post example.js? Where do you put it?)

[orlp]

1. I don't think anyone is suggesting this would be the default, just an option.

2. I would assume that co-located assets would work like this:

posts/react.html
posts/react/example.js

posts/solid.html
posts/solid/example.js

[dmolesUC]

@Keats In the bad old days we mostly weren't in the habit of collocating assets (don't ask me why), but I suppose (in a vacuum) I wouldn't name both files example.js.

That said, at the moment if you want collocated assets in Zola you need to create page/index.md instead of page.md, right? In that case I would expect "ugly URL mode" (or one-to-one .md to .html mode) to generate page/index.html anyway, so no problem there. @orlp's suggestion would be a little trickier to implement (I suspect) but would also work.

To be clear, I'm not trying to tell you you're doing anything wrong, I'm just saying I have a use case for the proposed feature (old-school static HTML sites that I want to revamp and make maintainable while preserving existing URLs). Being curious how we got here is just an aside.

[itf]

I have a fork that implements this, if you build zola from source (cargo build --release): https://github.com/itf/zola/tree/easy-markdown. Then you can either add path = yourPath.html in the frontmatter of specific pages you want to uglify or enable ugly_urls = true in your config.toml to uglify everywhere

[brianm]

Another vote for this, the ability to migrate to Zola without breaking existing URL schemes is valuable. I'm trying to migrate to Zoila, and maintaining the URLs from the previous iterations, without mod_rewrite hacks and such, is a must.

@orlp's scheme for asset colocation is very good, I believe.

In an ideal world, a "ugly urls" setting which switches to @orlp 's scheme, with an option to provide templating in the config, or even full path specification (not slug) in front matter would be amazing. It adds optional complexity, but significantly expands the places Zola can be used.

[zorun]

I would also like to see this feature: I'm also migrating from an old static site generator that uses "ugly URLs" and I would like not to break the old URLs.

However, based on Keat's comment above, I found an easy workaround for this use-case. Simply use aliases in the front matter. If the alias ends with .html, Zola will generate the alias file as foo.html instead of the usual foo/index.html.

So if you have a source file posts/my-page.md with this:

+++
title = "My page title"
aliases = ["posts/my-page.html"]
+++

Zola will output an alias file posts/my-page.html that redirects to /posts/my-page/ (which should load the actual file posts/my-page/index.html depending on your webserver). The redirection is done with a <meta> http-equiv tag, I hope search engines understand this.

This is actually quite powerful, because you can keep supporting old URLs with any directory structure, even if it is completely different from the one in Zola:

+++
title = "My page title"
aliases = ["old/path/old-page-name.html"]
+++

In that case, /old/path/old-page-name.html would redirect to /posts/my-page/

[moorereason]

I decided to give zola a try for a simple project at work, and I would have liked to have had this feature available. But it's for an admittedly esoteric use case.

We use EZproxy in our library. EZproxy uses hardcoded template file names, such as login.htm, in a single directory. Since zola doesn't generate ugly URLs (or .htm files AFAIK), I have a Makefile target that copies the zola-generated files into the correct location in the EZproxy config. Since I'm using basically zola to generate templates, the aliases feature doesn't do my any good.

Again, this is an odd use case with a simple workaround, but I wanted to add my experience to the list. Thanks for considering it.