There are currently several Params and case related issues floating around in Hugo.
This is very confusing for users and one of the most common support questions on the forum.
And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work:
`Params.myCamelCasedParam`
Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys.
But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`.
This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys.
This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling".
Tests are added for all the template engines: Go templates, Ace and Amber.
Fixes#2615Fixes#1129Fixes#2590
Some sites, Hugo docs included, have faulty alias definitions that point
to itself or another real page. These will be overwritten in the next step.
This is how it behaves in Hugo 0.17, too.
Updates #2297
This includes removing the error return value from Permalink and RelPermalink.
We ignore that error all over the place, so we might as well remove it.
Updates #2297
To make it easier to follow and understand.
Both building and rebuilding now follow a four step flow:
1. Init
2. Process
3. Assemble
4. Render
And now there are only one Build method, used for both builds and rebuilds.
Updates #2297
There are currently several Params and case related issues floating around in Hugo.
This is very confusing for users and one of the most common support questions on the forum.
And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work:
`Params.myCamelCasedParam`
Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys.
But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`.
This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys.
This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling".
Tests are added for all the template engines: Go templates, Ace and Amber.
Fixes#2615Fixes#1129Fixes#2590
All config variables starts with low-case and uses camelCase.
If there is abbreviation at the beginning of the name, the whole
abbreviation will be written in low-case.
If there is abbreviation at the end of the name, the
whole abbreviation will be written in upper-case.
For example, rssURI.
The gain, given the "real sites benchmark" below, is obvious:
```
benchmark old ns/op new ns/op delta
BenchmarkHugo-4 14497594101 13084156335 -9.75%
benchmark old allocs new allocs delta
BenchmarkHugo-4 57404335 48282002 -15.89%
benchmark old bytes new bytes delta
BenchmarkHugo-4 9933505624 9721984424 -2.13%
```
Fixes#2495
Maps in Viper, Hugo's config backing store, is now properly lower-cased not just on top level, the current situation.
While this is mostly a good thing, as you don't need to know the original casing to look up a value, it will be breaking for people doing direct lookups in the ´Site.Params` map.
We will try to find a solution to this "breakage", but the recommended method to get params values is via the `.Param` methods.
This method is now implemented on `Node`, `Page` and `Site` and is case-insensitive:
* Use `.Param "someKey" ` if you want page param with fall back to site param if not found on page.
* Use `.Site.Param "someKey"` to get a site param
See #2590
This change adds a canonical alias.html template that is used for page
redirects, and passes the page as data to the template under .Page
Fixes#2533Closes#2576
There were some breaking changes etc. that is too late to fix for 0.17.
Let us think this through and add proper author support for Hugo 0.18.
Fixes#2464
Revert "docs: Add documentation for author profiles"
This reverts commit b6673e5309.
Revert "Add First Class Author Support"
This reverts commit cf978c0649.
Hugo 0.16 announced support for symbolic links for the root folders, /content, /static etc., but this got broken pretty fast.
The main problem this commit tries to solve is the matching of file change events to "what changed".
An example:
ContentDir: /mysites/site/content where /mysites/site/content is a symlink to /mycontent
/mycontent:
/mypost1.md
/post/mypost2.md
* A change to mypost1.md (on OS X) will trigger a file change event with name "/mycontent/mypost1.md"
* A change to mypost2.md gives event with name "/mysites/site/content/mypost2.md"
The first change will not trigger a correct update of Hugo before this commit. This commit fixes this by doing a two-step check:
1. Check if "/mysites/site/content/mypost2.md" is within /mysites/site/content
2. Check if "/mysites/site/content/mypost2.md" is within the real path that /mysites/site/content points to
Fixes#2265Closes#2273
Atomic operations with 64 bit values must be aligned for 64-bit on x86-32.
According to the spec:
"The first word in a global variable or in an allocated struct or slice can be relied upon to be 64-bit aligned."
The above wasn't enough for the `paginationPageCount` on `SiteInfo`, maybe due to how `SiteInfo` is embedded.
This commit adds a 4 byte padding before the `uint64` that creates the correct alignment.
Fixes#2415
So the Permalink gets correct when listing translations.
I have also checked the other relevant places to make sure we do not overwrite node values we need later.
Pointers can be tricky, but lesson learned is: A copy is cheap.
Updates #2309
In a multi-language setup, before this commit the Node's Translations() method
would return some "dummy nodes" that would point to the correct page (Permalink),
but would not be the same as the node it points to -- it would not have the translated
title etc.
The node creation is, however, so mingled with rendering, whihc is too early to have any global state,
so the nodes has to be split in a prepare and a render phase. This commits does that with as small
a change as possible. This implementation is a temp solution until we fix#2297.
Updates #2309
The current "rendering language" is needed outside of Site. This commit moves the Language type to the helpers package, and then used to get correct correct language configuration in the markdownify template func.
This commit also adds two new template funcs: relLangURL and absLangURL.
See #2309
And in the same go adjusted some minor parts of the language API:
Add LanguagePrefix alias to Node and rename the Multilingual config section to Languages.
See #2309
This is needed to make shortcode users happy with the new multilanguage support,
but it will also solve many other related posts about "stuff not available in the shortcode".
We will have to revisit this re the handler chain at some point, but that will be easier
now as the integration test story has improved so much.
As part of this commit, the site-building tests in page_test.go is refreshed, they now
tests for all the rendering engines (when available), and all of them now uses the
same code-path as used in production.
Fixes#1229Fixes#2323
Fixes ##1076
Work In Progress!
This commit makes a rework of the build and rebuild process to better suit a multi-site setup.
This also includes a complete overhaul of the site tests. Previous these were a messy mix that
were testing just small parts of the build chain, some of it testing code-paths not even used in
"real life". Now all tests that depends on a built site follows the same and real production code path.
See #2309Closes#2211Closes#477Closes#1744
This commit also consolidates URLs on Node vs Page, so now .Permalink should be interoperable.
Note that this implementations should be fairly short-livded, waiting for #2297, but the API should be stable.
Setting the language to use when loading the language bundles just doesn't work.
The template system is unfortanetely a global, and the last languate processed won ...
And a Hugo global variable which contains the site under build.
This is really needed to get some level of control of the "multiple languages" in play.
There are still work related to this scattered around, but that will come.
With this commit, the multilingual feature is starting to work.
Implements:
* support to render:
* content/post/whatever.en.md to /en/2015/12/22/whatever/index.html
* content/post/whatever.fr.md to /fr/2015/12/22/whatever/index.html
* gets enabled when `Multilingual:` is specified in config.
* support having language switchers in templates, that know
where the translated page is (with .Page.Translations)
(when you're on /en/about/, you can have a "Francais" link pointing to
/fr/a-propos/)
* all translations are in the `.Page.Translations` map, including the current one.
* easily tweak themes to support Multilingual mode
* renders in a single swift, no need for two config files.
Adds a couple of variables useful for multilingual sites
Adds documentation (content/multilingual.md)
Added language prefixing for all URL generation/permalinking see in the
code base.
Implements i18n. Leverages the great github.com/nicksnyder/go-i18n lib.. thanks Nick.
* Adds "i18n" and "T" template functions..
We have to figure out another way. There are perfectly valid reasons not having a layout for a page (I have have some broken sites as result of this).
See #1313
This reverts commit b15934008f.
Meny people, including me, have a custom robots.txt in static.
Also remove that option from the command line; it doesn't feel
important enough.
Fixes ##2049
This also includes a refactor of the hugofs package and its usage.
The motivation for that is:
The Afero filesystems are brilliant. Hugo's way of adding a dozen of global variables for the different filesystems was a mistake. In readFile (and also in some other places in Hugo today) we need a way to restrict the access inside the working dir. We could use ioutil.ReadFile and implement the path checking, checking the base path and the dots ("..") etc. But it is obviously better to use an Afero BasePathFs combined witha ReadOnlyFs. We could create a use-once-filesystem and handle the initialization ourselves, but since this is also useful to others and the initialization depends on some other global state (which would mean to create a new file system on every invocation), we might as well do it properly and encapsulate the predefined set of filesystems. This change also leads the way, if needed, to encapsulate the file systems in a struct, making it possible to have several file system sets in action at once (parallel multilanguage site building? With Moore's law and all...)
Fixes#1551
Site.ReadPagesFromSource returns nil chan error value when a site
content directory is empty but its receiver expects to be passed
something error values via the channel.
This fixes it by returning a channel which will be immediately closed.
Fix#1797
Cobra, the CLI commander in use in Hugo, has some long awaited improvements in the error handling department.
This enables a more centralized error handling approach.
This commit introduces that by changing all the command funcs to `RunE`:
* The core part of the error logging, usage logging and `os.Exit(-1)` is now performed in one place and that one place only.
* The usage text is now only shown on invalid arguments etc. (user errors)
Fixes#1502
