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

Misc case issues for URLs #1641

Closed
joneskoo opened this Issue Nov 28, 2015 · 8 comments

Comments

Projects
None yet
7 participants
@joneskoo

joneskoo commented Nov 28, 2015

I think there may be a regression for the URLs of uppercase tags.

In #491 urlize was changed to lowercase URLs. In #557 I think this may have been reverted?

Now when I added tag links to my post list page:

<a href="/tags/{{ . | urlize }}">#{{ . }}</a>

The links were broken as URLs come out as mixed case (contain uppercase letters). As a workaround, I can do this and it works.

<a href="/tags/{{ . | urlize | lower }}">#{{ . | lower }}</a>

I don't think most themes use | lower.

cc/ @bep @spf13 who participated in both issues.

@jeffreycentex

This comment has been minimized.

Show comment
Hide comment
@jeffreycentex

jeffreycentex Dec 19, 2015

It's not just tags that are broken. I am migrating a blog over from Jekyll that has the url: specified with uppercase characters. The main index page references the URL the proper way (with uppercase characters), but is generating the files with lower case letters. Thus my URL's break...

jeffreycentex commented Dec 19, 2015

It's not just tags that are broken. I am migrating a blog over from Jekyll that has the url: specified with uppercase characters. The main index page references the URL the proper way (with uppercase characters), but is generating the files with lower case letters. Thus my URL's break...

@gitgrimbo

This comment has been minimized.

Show comment
Hide comment
@gitgrimbo

gitgrimbo Apr 6, 2016

I think I am seeing a similar issue.

I have a folder on disk like the following (part1=lowercase, PART2=uppercase):

content/posts/part1/PART2

This folder has an index.md that references images in the same folder using a relative link, e.g. ![](999.jpg)

http://localhost:1313/**part1/PART2/** fails to load.
http://localhost:1313/**part1/part2/** loads ok, but is not the right case compared to what is on disk.

The relative URL to the image for the page that loads resolves to:

http://localhost:1313/**part1/part2**/999.jpg

This will not load in the browser running the hugo server. I assume because it's the wrong case and hugo is using a different resource-serving mechanism that is case-sensitive.

http://localhost:1313/**part1/PART2**/999.jpg loads ok.

I would like hugo to leave the case alone when handling URLs.

gitgrimbo commented Apr 6, 2016

I think I am seeing a similar issue.

I have a folder on disk like the following (part1=lowercase, PART2=uppercase):

content/posts/part1/PART2

This folder has an index.md that references images in the same folder using a relative link, e.g. ![](999.jpg)

http://localhost:1313/**part1/PART2/** fails to load.
http://localhost:1313/**part1/part2/** loads ok, but is not the right case compared to what is on disk.

The relative URL to the image for the page that loads resolves to:

http://localhost:1313/**part1/part2**/999.jpg

This will not load in the browser running the hugo server. I assume because it's the wrong case and hugo is using a different resource-serving mechanism that is case-sensitive.

http://localhost:1313/**part1/PART2**/999.jpg loads ok.

I would like hugo to leave the case alone when handling URLs.

@moorereason

This comment has been minimized.

Show comment
Hide comment
@moorereason

moorereason Apr 6, 2016

Contributor

Try setting the following option in your site config:

disablePathToLower = true
Contributor

moorereason commented Apr 6, 2016

Try setting the following option in your site config:

disablePathToLower = true
@gitgrimbo

This comment has been minimized.

Show comment
Hide comment
@gitgrimbo

gitgrimbo May 6, 2016

disablePathToLower = true does not work for me. The URLs are still changed to lowercase.

gitgrimbo commented May 6, 2016

disablePathToLower = true does not work for me. The URLs are still changed to lowercase.

@spf13

This comment has been minimized.

Show comment
Hide comment
@spf13

spf13 May 26, 2016

Contributor

@gitgrimbo What OS & file system are you using? Do you this site source publicly available so we can investigate further?

Contributor

spf13 commented May 26, 2016

@gitgrimbo What OS & file system are you using? Do you this site source publicly available so we can investigate further?

@gitgrimbo

This comment has been minimized.

Show comment
Hide comment
@gitgrimbo

gitgrimbo May 26, 2016

WIndows 7 and NTFS.

I lower-cased all my files/folders and flattened the content folder tree after my issues and have since been ok.

And I have a hunch that I also changed all the names of my md files to index.md, and put them in a folder of the same name, and that helped. Especially with the relative paths to images.

E.g. from

/content/article1.md
/content/article2.md

to

/content/article1/index.md
/content/article2/index.md

The TL;DR is probably that I used the wrong mixture of uglyurls and relative paths - I did a couple of tests and the results are below.


Test 1

With this test I can't replicate my issue. The test is:

/config.toml

uglyurls = false
disablePathToLower = true

/content/test1/index.md

{
    "title": "test1",
    "description": "",
    "tags": [ "test1" ],
    "date": "2016-05-26"
}

![](./TEST2/HUGO-UP.png)

![](./TEST2/hugo-low.png)

/content/test1/TEST2/index.md

{
    "title": "TEST2",
    "description": "",
    "tags": [ "TEST2" ],
    "date": "2016-05-26"
}

![](./HUGO-UP.png)

![](./hugo-low.png)

/content/test1/TEST2/hogo-low.png - A test png.

/content/test1/TEST2/HUGO-UP.png - A test png.

Both the above pages work, linking to the images correctly.

Test 2

This test uses file names that are not index.md.

E.g.

/content/test1/test1.md

This produces the following article link from my post list:

Browsing to this page fails to show the images. The HTML source is:

<p><img src="./TEST2/HUGO-UP.png" alt="" /></p>

<p><img src="./TEST2/hugo-low.png" alt="" /></p>

which is correct, but which results in the following absolute URL:

which is incorrect (there is an extra test1 URL segment).

Test 3

Using uglyurls = true, Test 2 works, with the post URL being:

and thus the relative paths to the images are correct.

gitgrimbo commented May 26, 2016

WIndows 7 and NTFS.

I lower-cased all my files/folders and flattened the content folder tree after my issues and have since been ok.

And I have a hunch that I also changed all the names of my md files to index.md, and put them in a folder of the same name, and that helped. Especially with the relative paths to images.

E.g. from

/content/article1.md
/content/article2.md

to

/content/article1/index.md
/content/article2/index.md

The TL;DR is probably that I used the wrong mixture of uglyurls and relative paths - I did a couple of tests and the results are below.


Test 1

With this test I can't replicate my issue. The test is:

/config.toml

uglyurls = false
disablePathToLower = true

/content/test1/index.md

{
    "title": "test1",
    "description": "",
    "tags": [ "test1" ],
    "date": "2016-05-26"
}

![](./TEST2/HUGO-UP.png)

![](./TEST2/hugo-low.png)

/content/test1/TEST2/index.md

{
    "title": "TEST2",
    "description": "",
    "tags": [ "TEST2" ],
    "date": "2016-05-26"
}

![](./HUGO-UP.png)

![](./hugo-low.png)

/content/test1/TEST2/hogo-low.png - A test png.

/content/test1/TEST2/HUGO-UP.png - A test png.

Both the above pages work, linking to the images correctly.

Test 2

This test uses file names that are not index.md.

E.g.

/content/test1/test1.md

This produces the following article link from my post list:

Browsing to this page fails to show the images. The HTML source is:

<p><img src="./TEST2/HUGO-UP.png" alt="" /></p>

<p><img src="./TEST2/hugo-low.png" alt="" /></p>

which is correct, but which results in the following absolute URL:

which is incorrect (there is an extra test1 URL segment).

Test 3

Using uglyurls = true, Test 2 works, with the post URL being:

and thus the relative paths to the images are correct.

@bep bep added the Stale label Feb 28, 2017

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 1, 2017

Member

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

Member

bep commented Mar 1, 2017

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

@xofyarg

This comment has been minimized.

Show comment
Hide comment
@xofyarg

xofyarg Mar 6, 2017

Contributor

Hi @bep, I can probably provide a test case which is relevant:

System
OSX 10.11.6 with Extended filesystem, case insensitive.

$ hugo version

Hugo Static Site Generator v0.19 darwin/amd64 BuildDate: 2017-03-06T10:44:09Z

$ cat config.yaml

baseurl: "http://127.0.0.1:1313"
languagecode: en-us
title: a test title

theme: test
disablePathToLower: true

MetaDataFormat: yaml

$ cat themes/test/layouts/_default/list.html

list:
{{ range .Data.Pages }}
{{ .RelPermalink }}
{{ .Content }}
{{ end }}

$ find content

content
content/TestFile.md
content/Type
content/Type/TestDir
content/Type/TestDir/index.md

$ hugo && cat public/index.html

list:

/TestFile/
<p>a test file post</p>


/type/testdir/
<p>a test dir post</p>

As we could see, the .RelPermalink is rendered without case information on path /Type/TestDir/.

Contributor

xofyarg commented Mar 6, 2017

Hi @bep, I can probably provide a test case which is relevant:

System
OSX 10.11.6 with Extended filesystem, case insensitive.

$ hugo version

Hugo Static Site Generator v0.19 darwin/amd64 BuildDate: 2017-03-06T10:44:09Z

$ cat config.yaml

baseurl: "http://127.0.0.1:1313"
languagecode: en-us
title: a test title

theme: test
disablePathToLower: true

MetaDataFormat: yaml

$ cat themes/test/layouts/_default/list.html

list:
{{ range .Data.Pages }}
{{ .RelPermalink }}
{{ .Content }}
{{ end }}

$ find content

content
content/TestFile.md
content/Type
content/Type/TestDir
content/Type/TestDir/index.md

$ hugo && cat public/index.html

list:

/TestFile/
<p>a test file post</p>


/type/testdir/
<p>a test dir post</p>

As we could see, the .RelPermalink is rendered without case information on path /Type/TestDir/.

@bep bep added Bug and removed Stale labels Mar 13, 2017

@bep bep added this to the v0.20 milestone Mar 13, 2017

@bep bep referenced this issue Mar 13, 2017

Closed

Add custom output formats #2828

26 of 26 tasks complete

@bep bep changed the title from URLs for uppercase tags broken (regression) to Misc case issues for URLs Mar 14, 2017

@bep bep self-assigned this Mar 14, 2017

bep added a commit to bep/hugo that referenced this issue Mar 27, 2017

hugolib: Refactor/-work the permalink/target path logic
This is a pretty fundamental change in Hugo, but absolutely needed if we should have any hope of getting "multiple outputs" done.

This commit's goal is to say:

* Every file target path is created by `createTargetPath`, i.e. one function for all.
* That function takes every page and site parameter into account, to avoid fragile string parsing to uglify etc. later on.
* The path creation logic has full test coverage.
* All permalinks, paginator URLs etc. are then built on top of that same logic.

Fixes #1252
Fixes #2110
Closes #2374
Fixes #1885
Fixes #3102
Fixes #3179
Fixes #1641
Fixes #1989

@bep bep closed this in 6bf010f Mar 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment