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

joneskoo opened this Issue Nov 28, 2015 · 8 comments


None yet
7 participants
Copy link

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.


This comment has been minimized.

Copy link

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


This comment has been minimized.

Copy link

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


This folder has an 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:


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.


This comment has been minimized.

Copy link

moorereason commented Apr 6, 2016

Try setting the following option in your site config:

disablePathToLower = true

This comment has been minimized.

Copy link

gitgrimbo commented May 6, 2016

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


This comment has been minimized.

Copy link

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?


This comment has been minimized.

Copy link

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, and put them in a folder of the same name, and that helped. Especially with the relative paths to images.

E.g. from




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:


uglyurls = false
disablePathToLower = true


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




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



/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



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


This comment has been minimized.

Copy link

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.


This comment has been minimized.

Copy link

xofyarg commented Mar 6, 2017

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

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: ""
languagecode: en-us
title: a test title

theme: test
disablePathToLower: true

MetaDataFormat: yaml

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

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

$ find content


$ hugo && cat public/index.html


<p>a test file post</p>

<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


Add custom output formats #2828

26 of 26 tasks complete

@bep bep changed the title URLs for uppercase tags broken (regression) 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 gohugoio#1252
Fixes gohugoio#2110
Closes gohugoio#2374
Fixes gohugoio#1885
Fixes gohugoio#3102
Fixes gohugoio#3179
Fixes gohugoio#1641
Fixes gohugoio#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