jekyll s redirects to slightly wrong URL (with file and folder of same name)

[janpio]

If a file and a folder have the same "permalink" name, jekyll s redirects to a slighty incorrect URL.

---

• I believe this to be a bug, not a question about using Jekyll.
• I updated to the latest Jekyll (or) if on GitHub Pages to the latest github-pages
• I ran jekyll doctor to check my configuration
• I read the CONTRIBUTION file at https://jekyllrb.com/docs/contributing/
• This is a feature request.

---

• I am on (or have tested on) macOS 10+
• I am on (or have tested on) Debian/Ubuntu GNU/Linux
• I am on (or have tested on) Fedora GNU/Linux
• I am on (or have tested on) Arch GNU/Linux
• I am on (or have tested on) Other GNU/Linux
• I am on (or have tested on) Windows 10+

Windows Linux Subsystem, bash via Windows 10 Powershell

---

• I was trying to install.
• There is a broken Plugin API.
• I had an error on GitHub Pages, and I have reproduced it locally.
• I had an error on GitHub Pages, and GitHub Support said it was a Jekyll Bug.
• I had an error on GitHub Pages and I did not test it locally.
• I was trying to build.
• It was another bug.

My Reproduction Steps

jekyll s does strange things when a file has the same name as a folder:

• Site is configured as permalink: /:path
• bar.md, should render at /bar
• bar/baz.md, should render at /bar/baz

Unfortunately:

On accessing /bar:

• In 3.5.2 it showed the directly listing after redirecting to /bar/ (had to go to bar.html manually).
• Since 3.6.0 it shows the correct content of bar.md (fixed in Fix serving files that clash with directories (#6222) #6231) but still redirects to /bar/.

In _site everything is generated as it should:

• /bar.html with content from bar.md
  Per the configured permalink, this should be accessible as /bar.

Example repo

Here is a repo that shows this exact scenario:
https://github.com/janpio/jekyll-path-test
Use the site navigation for the three example pages.

If you use jekyll s, note how you are redirected on "Bar" (3.5.2 and 3.6.x).

(The project also includes 3 collections that test further iterations of this problem:, _test1 and _test2 with .html ending are fine, but _test3 has the exact same problem.)

The Output I Wanted

You can see how everything should work at Github Pages:
https://janpio.github.io/jekyll-path-test/

[janpio]

That were some short two months...

[stevetweeddale]

I've just run into this same issue, running 3.6.2. I have the following in config.yml:

permalink: /:categories/:year/:month/:day/:title # no extensions or trailing slashes
collections:
  team:
    output: true

And a source directory like this:

.
├── Gemfile
├── Gemfile.lock
├── _config.yml
├── _team
│   ├── person-a.md
│   └── person-b.md
├── about.md
└── team.md

Produces a _site directory like this:

_site
├── about.html
├── team
│   ├── person-a.html
│   └── person-b.html
└── team.html

And then visiting:

• /about renders about.html.
• /team/person-a renders /team/person-a.html

So far so good. But then:

• /team 301 redirects to /team/, which then renders team.html

So nothings mega broken, it's mainly just disconcerting because Jekyll generates links correctly to /team and that url populates canonical tag and such. So it's odd that the local server redirects away from it!

[SolderHQ]

I have the very same problem as well described by @janpio and @stevetweeddale. Any updates on this? I'm Using Jekyll 3.8.2, if that's of any help.

Edit: I believe this behaviour is intended to make sure that if a collection, say test-collection, is set to output to a directory, Jekyll will automatically link /test-collection to /test-collection/. I think it's desirable when no root page test-collection exist. But when it does exist, Jekyll should point /test-collection to /test-collection instead of 301 redirecting it to /test-collection/.

Is it possible to take a closer look and reopen this issue @DirtyF ?

[stevetweeddale]

Jekyllbot – cold as ice!

Sooooo… I’ve only just looked at the aria-label for the 'stale' label, but otherwise, I was left wondering if this issue was closed 'works as designed'? 'Resolved'? 'Closed: won't fix'? I normally wouldn't expect a bug report to be closed when there's no reason to believe the bug isn't reproducible and valid. I use "open issues" as a vague metric for "potentially unresolved known bugs" quite a bit. Maybe I shouldn't!

As such, I'd suggest the robo-wording/labels could potentially do with some work. Because Jekyllbot initially asking for more info is fine I think: it’s when that effort (understanding the issue, producing a reduced test case, writing up findings) is proven wasted when the issue is summarily dismissed 2 months later… well, doesn’t make you feel like bothering next time.

Maybe something along the lines of "We're sorry to anyone who spent time investigating, producing reduced test cases and reporting – but we're not going to get around to working on this. If you're able to contribute a PR feel free, but otherwise we are sorry that our time is limited and other issues must take priority."

Anyway, I'd hate to sound like a whiner so thanks for all your work on Jekyll! I'm sorry that I'm not familiar enough with Ruby to take a stab at this issue.