Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make trailing slashes optional #1534

Closed
wants to merge 6 commits into from
Closed

Conversation

valpackett
Copy link

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

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

@Keats
Copy link
Collaborator

Keats commented Jul 2, 2021

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

@valpackett
Copy link
Author

valpackett commented Jul 3, 2021

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
Copy link
Collaborator

Keats commented Jul 10, 2021

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
Copy link

pk-nb commented Aug 11, 2021

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
Copy link
Collaborator

Keats commented Sep 3, 2021

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
Copy link
Author

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
Copy link

Netlify for example, works with or without slashes.

@TeFiLeDo
Copy link

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).

Copy link

@sshine sshine left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In reading the comments for this PR, I've learned that it makes perfect sense to make your relative paths default to the parent, even though this is not what's done historically or is the norm. It does make for nicer URLs where historically, the browser cooperated to remove trailing slashes to make the URLs nice.

I think the "due to how most default web server configurations work" argument warrants this.

And the argument for holding back should be to minimize the number of configurable parameters?

@roblillack
Copy link

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: #1781 (comment)

edwardmlyte and others added 5 commits August 30, 2022 10:28
* docs: github action version updates

* Uses latest version of the action
* Updated requirement for token to be set
  (https://github.com/shalzz/zola-deploy-action/blob/138a3568d1045f57bcdfec4b66ad37ac3dca5475/entrypoint.sh#L44
  will exit out without it)
* Reduced TOKEN scope and added scope to URL. Aligns with action docs

* docs: revert commentary on token requirement

* docs: add note about passing in automatic token
Co-authored-by: GitHub Action <action@github.com>
Changed double quotation mark " to single quotation ', otherwise the code doesn't work.
Co-authored-by: GitHub Action <action@github.com>
@pmikolajek
Copy link

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 valpackett force-pushed the trailing branch 2 times, most recently from 8e82222 to 472bc92 Compare November 15, 2022 00:45
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.
@valpackett
Copy link
Author

valpackett commented Nov 15, 2022

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

@pmikolajek
Copy link

@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
Copy link
Collaborator

Keats commented Nov 23, 2022

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
Copy link

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
Copy link
Collaborator

Keats commented Nov 23, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet