Make trailing slashes optional

[valpackett]

Now if you have a web server set up to handle this, you can set trailing_slashes = false in the config and use URLs without them.

Code changes

• [x] Are you doing the PR on the next branch?
• [x] Have you created/updated the relevant documentation page(s)?

[Keats]

Which server behaves like that? Is /path the same as /path/ in that case?

[valpackett]

No server does this by default, but servers can be very customizable. In my current server setup (h2o with custom scripts) /path/ is a 301 redirect to /path, and /path is "serve /path/index.html if exists and I'm not logged in as admin, otherwise proxy to dynamic engine". I'm planning to implement similar behavior in Cloudfront with ~~Lambda@Edge~~ Cloudfront Functions as well (minus the dynamic part). I think maybe nginx can be configured to do this with just config rules, without scripting.

[Keats]

Hm I thought it was something some common webserver was doing but it really seems to be a very specific individual configuration. I'll leave this up to see if more people are interested in that before merging.

[pk-nb]

I'll throw a +1 in for this feature. Trailing v.s. non-trailing slashes is a common ask given the "aesthetic" choice, and can be important for folks migrating from Wordpress / Gatsby / other tools that allow this configuration. Some services differ on the defaults here too. Many default with trailing slash for index pages, but others don't, such as surge. https://surge.sh/help/using-clean-urls-automatically

Personally considering deployment to surge, would be very happy for this feature to avoid the mismatch of links to the actual hosted route for SEO reasons.

[Keats]

The issue is that most webservers by default will not work without trailing slashes I believe? So it's adding an option to generate potentially broken sites for people. I think it might be better in a fork than in the main project

[valpackett]

I think users can be trusted to understand how their web servers work! These "protect the user from themselves" hand-holdy restrictions are not what I'm looking for in an open source project :/ With a compiled program that's sometimes "already there" (netlify etc.) using a fork is not trivial so flexibility is very much desired.

[eberkund]

Netlify for example, works with or without slashes.

[TeFiLeDo]

caddy also works with and without slashes.

Also I don't think that protecting the users from themselves is necessary in this case. I assume most people using an SSG are developer/admins and understand what this does. Everybody else would be warned by the documentation (which they'd have to read to learn about this option).

[roblillack]

I think this should be merged to be able to create sites without trailing slashes – even if the current implementation of zola serve can be improved. Also see my comment on a related zola serve bug: https://github.com/getzola/zola/issues/1781#issuecomment-1194058265

[pmikolajek]

Any updates on this? The consensus seems to be that this should be merged, but there's been no developments. Allowing pretty urls without trailing slashes is a must for our project, so we need to drop zola over this.

[valpackett]

Applied doc comment suggestion, quickly rebased, ~~no manual testing has been done tho~~ (sorry, not actively using Zola anymore)

[pmikolajek]

@Keats so how about it?

And just in case there's still doubt whether supporting slashless URLs is in demand: https://twitter.com/jaffathecake/status/1261252780796383233

[Keats]

I'm still not convinced about that feature. Pages/sections are directories in zola as you can have colocated assets. Having optional trailing slash means that you can't use relative urls anymore for those.

I'm leaning towards closing this.

[pmikolajek]

I mean, at the end of the day, it's about whether you want to add a feature that people definitely, 100% want and need, or if you want to deliberately limit the framework because apparently most of your potential users aren't making sites the way you want them to. Which is fair game if you want to be opinionated, but don't expect to win majority market share with that mindset.

Every time you see a site that uses the format you chose not to support (for example, this site), that's a site to which you say: Zola is not for you, use something else. (Well, github couldn't be a static site anyway, but you get my drift.) If someone wanted to migrate to Zola, but their old framework used the majority format? They can't, look elsewhere, we don't want you here.

That's my fair advice, take it or leave it. As for me, I will just use something else.

[Keats]

I mean, at the end of the day, it's about whether you want to add a feature that people definitely, 100% want and need, or if you want to deliberately limit the framework because apparently most of your potential users aren't making sites the way you want them to. Which is fair game if you want to be opinionated, but don't expect to win majority market share with that mindset.

I don't really care about the market share. A tool that has every single features of every single competitor is not something I would want to use or work on. There are 100s of SSG, each with their pros and cons, and one tool cannot possibly satisfy everyone. Maybe check out Hugo or eleventy to see if they fit your needs?