github/hugo
1
0
Fork 0
mirror of https://github.com/gohugoio/hugo.git synced 2024-11-07 20:30:36 -05:00
Code Issues Projects Releases Packages Wiki Activity
hugo/docs/content/extras/urls.md
Anthony Fok 743998306a [Docs] Document the new (temp?) default of canonifyurls = false 
Also add a **Caveat** on http://gohugo.io/tutorials/github-pages-blog/
warning the reader that a `canonifyurls = true` must be added
for Spencer's old example files to work.

Fixes #802
2015-01-22 18:04:07 -07:00

2.8 KiB
Raw Blame History

aliases date menu next notoc prev title weight
/doc/urls/
2014-01-03
main
parent
extras
/community/mailing-list true /extras/toc URLs 110

Pretty URLs

By default, Hugo create content with 'pretty' URLs. For example, content created at /content/extras/urls.md will be rendered at /public/extras/urls/index.html, thus accessible from the browser at http://example.com/extras/urls/. No non-standard server-side configuration is required for these pretty URLs to work.

If you would like to have what we call "ugly URLs", e.g. http://example.com/extras/urls.html, you are in luck. Hugo supports the ability to create your entire site with ugly URLs. Simply add uglyurls = true to your site-wide config.toml, or use the --uglyUrls=true flag on the command line.

If you want a specific piece of content to have an exact URL, you can specify this in the front matter under the url key. See Content Organization for more details.

Canonicalization

By default, all relative URLs encountered in the input are left unmodified, e.g. /css/foo.css would stay as /css/foo.css.

By setting canonifyurls to true, all relative URLs would instead be canonicalized using baseurl. For example, assuming you have baseurl = http://yoursite.example.com/ defined in the site-wide config.toml, the relative URL /css/foo.css would be turned into the absolute URL http://yoursite.example.com/css/foo.css.

Benefits of canonicalization include fixing all URLs to be absolute, which may aid with some parsing tasks. Note though that all real browsers handle this client-side without issues.

Benefits of non-canonicalization include being able to have resource inclusion be scheme-relative, so that http vs https can be decided based on how this page was retrieved.

Caveat: Default of canonifyurls changed in v0.11

Hugo Version Release Date Default
v0.9 2013-11-15 canonifyurls = true (non-configurable)
v0.10 2014-03-01 canonifyurls = true
v0.11 2014-05-29 canonifyurls = false
v0.12 2014-09-01 canonifyurls = false
v0.13-DEV in development canonifyurls = false (as of January 2015)