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
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
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 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
The previous implementation didn't easily support the use case "I want one base template for the single pages, another for the rest".
The new lookup order is:
1. <current-path>/<template-name>-baseof.ace, e.g. list-baseof.ace
2. <current-path>/baseof.ace
3. _default/<template-name>-baseof.ace, e.g. list-baseof.ace.
4. _default/baseof.ace
As views looks like a regular template, but doesn't need a base template, we have to look inside it.
Altough really not needed by this commit, reading the full file content into memory just to do a substring search is a waste.
So this commit implements a `ReaderContains` func that in most cases should be much faster than doing an `ioutil.ReadAll` and `bytes.Contains`:
```
benchmark old ns/op new ns/op delta
BenchmarkReaderContains 78452 20260 -74.18%
benchmark old allocs new allocs delta
BenchmarkReaderContains 46 20 -56.52%
benchmark old bytes new bytes delta
BenchmarkReaderContains 46496 1258 -97.29%
```
Fixes#999
That is whas was implemented, not Substr.
Also make the API more similar to Go's internal slice by making both the start and end indices optional.
See #990
Thanks to @bep's new, brilliant helpers.Deprecated() function,
the following functions or variables are transitioned to their
new names, preserving backward compatibility for v0.14
and warning the user of upcoming obsolescence in v0.15:
* .Url → .URL (for node, menu and paginator)
* .Site.BaseUrl → .Site.BaseURL
* .Site.Indexes → .Site.Taxonomies
* .Site.Recent → .Site.Pages
* getJson → getJSON
* getCsv → getCSV
* safeHtml → safeHTML
* safeCss → safeCSS
* safeUrl → safeURL
Also fix related initialisms in strings and comments.
Continued effort in fixing #959.
First step to use initialisms that golint suggests,
for example:
Line 116: func GetHtmlRenderer should be GetHTMLRenderer
as see on http://goreportcard.com/report/spf13/hugo
Thanks to @bep for the idea!
Note that command-line flags (cobra and pflag)
as well as struct fields like .BaseUrl and .Url
that are used in Go HTML templates need more work
to maintain backward-compatibility, and thus
are NOT yet dealt with in this commit.
First step in fixing #959.
`eq` and `ne` template functions don't work as expected when those are
used with a raw number and a calculated value by add, sub etc. It's
caused by both numbers type differences. For example, `eq 5 (add 2 3)`
returns `false` because raw 5 is `int` while `add 2 3` returns 5 with
`int64`
This normalizes `int`, `uint` and `float` type values to `int64`,
`uint64` and `float64` before comparing them. Other type of value is
passed to comparing function without any changes.
Fix#961
Added a new Template.PrintErrors() function call,
used in hugolib/site.go#Process() so it does not clutter
up `go test -v ./...` results.
Special thanks to @tatsushid for mapping out the call trace
which makes it a lot easier to find the appropriate places
to place the Template.PrintErrors() call.
Fixes#316
- Add `safeUrl` template function (Fixes#347)
- Add TestSafeUrl() fashioned after @tatsushid great examples
- Disable `safeHtmlAttr` pending further discussions on its other
use cases because `safeUrl` is a cleaner solution to #347.
(There are also `safeJs` and `safeJsStr` that we could implement
if there are legitimate demands for them.)
- Rename `safeCSS` to `safeCss` (to follow the convention of `safeHtml`)
- Add/expand documentation on `safeHtml`, `safeCss` and `safeUrl`
This allows a template user to keep a safe HTML attribute or CSS string
as is in a template.
This is implementation of @anthonyfok great insight
Fix#784, #347
This changes `echoParam` template function behavior to accept not only
an array or a slice and its index pair but also a map and its key pair.
This also changes the function that float and uint values are treated as
a valid result type of it.
Fix#771
It allows to use `where` template function like SQL `where` clause.
For example,
{{ range where .Data.Pages "Type" "!=" "post" }}
{{ .Content }}
{{ end }}
Now these operators are implemented:
=, ==, eq, !=, <>, ne, >=, ge, >, gt, <=, le, <, lt, in, not in
It also fixes `TestWhere` more readable
'where' template function used to accept only each element's struct
field name, method name and map key name as its second argument. This
extends it to accept dot chaining key like 'Params.foo.bar' as the
argument. It evaluates sub elements of each array elements and checks it
matches the third argument value.
Typical use case would be for filtering Pages by user defined front
matter value. For example, to filter pages which have 'Params.foo.bar'
and its value is 'baz', it is used like
{{ range where .Data.Pages "Params.foo.bar" "baz" }}
{{ .Content }}
{{ end }}
It ignores all leading and trailing dots so it can also be used with
".Params.foo.bar"
The flag `HTML_SMARTYPANTS_ANGLED_QUOTES` was added to Blackfriday on Black Friday. This configures rendering of double quotes as angled left and right quotes («
»).
Typical use cases would be either or, or combined, but never in the same
document. As an example would be a person from Norway; he has a blog in both
English and Norwegian (his native tongue); he would then configure Blackfriday
to use angled quotes for the Norwegian section, but keep them as reqular
double quotes for the English.
This commit adds configuration support for this new flag, configuration that can be set in the site configuration, but overridden in page front matter.
Fixes#605
- `.Ref` and `.RelRef` take a reference (the logical filename for a
page, including extension and/or a document fragment ID) and return
a permalink (or relative permalink) to the referenced document.
- If the reference is a page name (such as `about.md`), the page
will be discovered and the permalink will be returned: `/about/`
- If the reference is a page name with a fragment (such as
`about.md#who`), the page will be discovered and used to add the
`page.UniqueID()` to the resulting fragment and permalink:
`/about/#who:deadbeef`.
- If the reference is a fragment and `.*Ref` has been called from
a `Node` or `SiteInfo`, it will be returned as is: `#who`.
- If the reference is a fragment and `.*Ref` has been called from
a `Page`, it will be returned with the page’s unique ID:
`#who:deadbeef`.
- `.*Ref` can be called from either `Node`, `SiteInfo` (e.g.,
`Node.Site`), `Page` objects, or `ShortcodeWithPage` objects in
templates.
- `.*Ref` cannot be used in content, so two shortcodes have been
created to provide the functionality to content: `ref` and `relref`.
These are intended to be used within markup, like `[Who]({{% ref
about.md#who %}})` or `<a href="{{% ref about.md#who %}}">Who</a>`.
- There are also `ref` and `relref` template functions (used to create
the shortcodes) that expect a `Page` or `Node` object and the
reference string (e.g., `{{ relref . "about.md" }}` or `{{
"about.md" | ref . }}`). It actually looks for `.*Ref` as defined on
`Node` or `Page` objects.
- Shortcode handling had to use a *differently unique* wrapper in
`createShortcodePlaceholder` because of the way that the `ref` and
`relref` are intended to be used in content.
filepath.Walk does not follow symbolic links.
There's no easy fix for that outside of Go, so the best we can do for now is to give notice to the end user by ERROR log statements.
This commit also fixes a related panic situation in GenerateTemplateNameFrom when the layout dir was a symbolic link.
Fixes#283
File handling was broken on Windows. This commit contains a revision of the path handling with separation of file paths and urls where needed.
There may be remaining issues and there may be better ways to do this, but it is easier to start that refactoring job with a set of passing tests.
Fixes#687Fixes#660
