trailing slashes

[laurenskling]

I'd like to create my pages as /blog/ and /blog/2/, it cannot be done currently, right?

[chmac]

@laurenskling Is there a reason why you want this? As I understand it, Gatsby considers both /blog and /blog/ to be the same URL. There is a warning output if you try to create two pages with the same path like this but with or without the trailing slash...

[laurenskling]

My client wants to have the exact same sitemap as the old website, that one included trailing slashes.

[chmac]

@laurenskling Then I'd suggest doing something in your sitemap generation to append slashes. I'd also guess that from a crawler point of view the two URLs are identical, but I'm not 100% sure on that. The get built into folders, so /page-one/index.html is the actual filename, I guess it makes no difference if you write /page-one or /page-one/ as the URL. But hey, I also understand keeping clients happy! :-)

[ryanwiemer]

@chmac,

First of all thank you for the plugin. It works great and I use it on several starters and themes.

For what it's worth I think it would be beneficial to have trailing slashes as an option. Is that something you would be open to in a pr or are you against the idea all together?

[chmac]

@ryanwiemer I consider that maybe adding an API to specify a function that builds the path might be an option here, what do you think?

This would allow us to support all kinds of crazy use cases, like /foo/even/2/ and /foo/odd/3/ or whatever folks can come up with. It'd also allow somebody to add trailing slashes.

[ryanwiemer]

@chmac

Yeah, that sounds good to me. More of an advanced feature for those that want it.

[sjelfull]

Just chiming in here.

@chmac Having this / the API as an option would allow us to keep URLs consistent.

Every other URL on our site has a trailing slash, so I think it makes sense.

[i-bsd]

Is there an update on this issue?

I get dozens of warnings like this during development:

warn Non-deterministic routing danger: Attempting to create page: "/tag/conlangs", but page "/tag/conlangs/" already exists

This could lead to non-deterministic routing behavior

It hasn't caused any actual errors yet thankfully and builds work, but I'm concerned it may cause issues at some point (plus I hate having pages of warnings like this).

I'd also guess that from a crawler point of view the two URLs are identical, but I'm not 100% sure on that.

Just to respond to this - no they are not identical. Google treats trailing and non-trailing slash slugs as separate pages. This is a major problem for SEO.

How can we modify the plugin to force trailing slashes to avoid these warnings?

[chmac]

@i-bsd The error you've posted means you're creating pages twice, once with and once without a trailing slash. That's not a problem with this plugin.

Also, Gatsby treats the URLs as identical, even though they might not be from an SEO perspective, they both result in folders like /tag/conlangs/index.html so they will definitely overlap.

It's up to you how you want to link to pages, you're free to ensure links always have a trailing slash.

I'm closing this issue now. I'm happy to review a PR that adds an option itemToPath to the paginate() API in line with the createPagePerItem() API.

[decimoseptimo]

Given that an extra config flag is coming soon gatsbyjs/gatsby#29445 (comment)

We might want to hook onto that when available, but for now a prop might do:

type PaginateOpts = {
  ...
  trailingSlash: Boolean
  ...
};

Defaulting to true, equaling gatsby's behaviour. Thoughts?

[chmac]

@decimoseptimo Thanks for sharing the link on Gatsby's plans. Maybe I'm missing something, but I guess that once this flag lands in Gatsby, then the topic is solved? I assume Gatsby will take care of ensuring that all paths end with a trailing slash, so there's no need for any updates to this plugin?

I'm still open to a PR as I mentioned above.

[decimoseptimo]

We'll see their implementation. In the meantime this fixes the OP request, which is to allow the setting of canonical URLs with trailing slashes.

[chmac]

Just to copy the message here, I will not add a trailingSlash API. I am open to a PR that adds itemToPath.

[decimoseptimo]

I understand. Your are aiming at something more robust and inline with your current api. On the other hand, there might be more need for something that merely solves trailing slashes. At least now there's a solution out there, that might be useful for someone.

[igpineda]

This post has a good reason why is important to have the option to support trailing slash,

" Here’s what I mean. Take my site’s Blog index. Say that we pass "/blog" to createPage() — we know from above that it’ll ultimately print the HTML to ~/public/blog/index.html, but what happens when we load jonsully.net/blog/ in the browser? Well, if you do it with Javascript disabled, it works just fine! But if you enable Javascript you’ll see that as soon as you load the page, the trailing slash suddenly falls off! And if you refresh your browser, you’ll see the trailing slash pop in for a moment then quickly fall off again! What the heck!

What’s going on is that Gatsby printed your file to a directory index because the path string you gave for that page didn’t end in .html — so the server is correctly pushing you to /blog/ (with slash) because that’s what the actual file is. Once that page loads in your browser though (once the Router loads in Javascript), it’s reverting the address bar back to the non-slash version of your path because that’s the path it was configured with. The path string you give to createPage() is the same path string that the Reach Router gets. Even though createPage() doesn’t care if it has a trailing slash or not (it’ll directory-ize either way), the Reach Router configuration does. It was configured with /blog, not /blog/, so once the Router spins up in Javascript on your browser, it drops the trailing slash!

That’s particularly unhelpful because when you refresh the page, it requests the non-trailing-slash version of the page from the server (that’s what’s currently in your address bar, after-all) but the server does its job and pushes you to the trailing slash version. Your browsers follows and receives the content for the trailing slash version and… as soon as the Router spins up in Javascript, it drops the slash again! Annoying, right?! "

https://jonsully.net/blog/trailing-slashes-and-gatsby/