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
Add validation before creating aliases:
* Prevent creating aliases outside webroot (public/ dir)
* Skip empty "" alias
* Skip "/" → "/index.html", which gets overwritten anyway
* Refuse to create Windows-invalid filenames on Windows;
warn on other platforms
* In case of invalid aliases, after skipping them,
return `err = nil` to prevent the error passing up
all the way to `hugolib.Render()` and causing Hugo to abort.
* Update alias tests.
Fixes#701: Add support for alias with whitespace
Fixes#1418: Add validation for alias
I could be wrong here, but it looks to me like .Site.Social.facebook is used in tpl/template_embedded.go, but the variable is never set. I've added a line to initializeSiteInfo to map the info from config into this variable.
Before this commit, taxonomy names were hyphenated, lower-cased and normalized -- then fixed and titleized on the archive page.
So what you entered in the front matter isn't necessarily what you got in the final site.
To preserve backwards compability, `PreserveTaxonomyNames` is default `false`.
Setting it to `true` will preserve what you type (the first characters is made toupper for titles), but normalized in URLs.
This also means that, if you manually construct URLs to the archive pages, you will have to pass the Taxonomy names through the `urlize` func.
Fixes#1180
Section names are also used as the title of the list pages, but naming section folders as `Fish and Chips` and similar didn't work very well.
This commit fixes that.
This commit also changes the title casing of the section titles. Some may argue that this is a breaking change, but the old behaviour was also pretty broken,
even for languages that use title capitalizations, as it didn't follow any particular style guide, `fish and chips` became `Fish And Chips` etc.
Now it just turns the first letter into upper case, so `Fish and Chips` will be left as `Fish and Chips`.
People wanting the good old behaviour can use the `title` template func.
Fixes#1176
To determine if a page is the "Home Page" has inspired lots of creativity in the template department.
This commit makes it simpler: IsHome will tell the truth.
Setting `RelativeURLs` to `true` will make all relative URLs in the site *really* relative.
And will do so with speed.
So:
In `/post/myblogpost.html`:
`/mycss.css` becomes `../mycss.css`
The same in `/index.html` will become:
`./mycss.css` etc.
Note that absolute URLs will not be touched (either external resources, or URLs constructed with `BaseURL`).
The speediness is about the same as before:
```
benchmark old ns/op new ns/op delta
BenchmarkAbsURL 17462 18164 +4.02%
BenchmarkAbsURLSrcset 18842 19632 +4.19%
BenchmarkXMLAbsURLSrcset 18643 19313 +3.59%
BenchmarkXMLAbsURL 9283 9656 +4.02%
benchmark old allocs new allocs delta
BenchmarkAbsURL 24 28 +16.67%
BenchmarkAbsURLSrcset 29 32 +10.34%
BenchmarkXMLAbsURLSrcset 27 30 +11.11%
BenchmarkXMLAbsURL 12 14 +16.67%
benchmark old bytes new bytes delta
BenchmarkAbsURL 3154 3404 +7.93%
BenchmarkAbsURLSrcset 2376 2573 +8.29%
BenchmarkXMLAbsURLSrcset 2569 2763 +7.55%
BenchmarkXMLAbsURL 1888 1998 +5.83%
```
Fixes#1104Fixes#622Fixes#937Fixes#157
Create new field in Node
Update Page to look for lastmod field in the front matter. If not present, then assign Date to Lastmod
Update Site, to assign a value to Lastmod (based on the same logic used for Date)
Fixes#733
Pretty sure it has worked at some point, but that PR probably has been rebased to pieces.
This refactors the fix by @dannys42 into a method, as this URL fix is applied several places.
Fixes#1114
The current menu system works great, but is too much work if all you want is a simple menu with the sections as menu items, and having these menu items connected to the pages in a way that enables setting the correct menu item as active for both the section lists and the pages itself.
This commit adds a new option `SectionPagesMenu' which, if set, will create a new menu with that name with all the sections as menu items. The pages in the sections will behave as "shadow members" of these section items as `blogpage.HasMenuCurrent "sectionmenu" $sectionmenuitem` will return true.
If a menu item with the same `identifier` is defined in site config, *that* item will take precedence.
`Paginate`now returns error when
1) `.Paginate` is called after `.Paginator`
2) `.Paginate` is repeatedly called with different arguments
This should help remove some confusion.
This commit also introduces DistinctErrorLogger, to prevent spamming the log for duplicate rendering errors from the pagers.
Fixes#993
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.
...
Prevent 404.html from prettifying into 404/index.html
Restore @realchaseadams's commit 348e123
"Force `UglyUrls` option to force `404.html` file name"
which got lost after some refactoring (commit 8db3c0b).
Remove the equivalent "force `UglyUrls`" code for `sitemap.xml`
because the refactored code now calls `renderAndWriteXML()`
which uses `WriteDestFile()` which does not prettify a filename.
Fixes#939 (reverted from commit c4c19ad303)
Restore @realchaseadams's commit 348e123
"Force `UglyUrls` option to force `404.html` file name"
which got lost after some refactoring (commit 8db3c0b).
Remove the equivalent "force `UglyUrls`" code for `sitemap.xml`
because the refactored code now calls `renderAndWriteXML()`
which uses `WriteDestFile()` which does not prettify a filename.
Fixes#939
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
Two new configuration properties, `Paginate` (default `0`) and `PaginatePath` (default `page`) are added.
Setting `paginate` to a positive value will split the list pages for the home page, sections and taxonomies into chunks of size of the `paginate` property.
A `.Paginator` is provided to help building a pager menu.
There are two ways to configure a `.Paginator`:
1. The simplest way is just to call `.Paginator.Pages` from a template. It will contain the pages for "that page" (`.Data.Pages` will (like today) contain all the pages).
2. Select a sub-set of the pages with the available template functions and pass the slice to `.Paginate` : `{{ range (.Paginate (where .Data.Pages "Type" "post")).Pages }}`
**NOTE:** For a given Node, it's one of the options above. It's perfectly legitimate to iterate over the same pager more than once, but it's static and cannot change.
The `.Paginator` contains enough information to build a full-blown paginator interface.
The pages are built on the form (note: BLANK means no value, i.e. home page):
```
[SECTION/TAXONOMY/BLANK]/index.html
[SECTION/TAXONOMY/BLANK]/page/1/index.html => redirect to [SECTION/TAXONOMY/BLANK]/index.html
[SECTION/TAXONOMY/BLANK]/page/2/index.html
....
```
Fixes#96
When we have an absolute menu url specified in the config file
(e.g., `menu: { main: { name: "News", url: "/news" } }`),
its menu entry is generated by prefixing it with the BaseUrl.
The result is then run through prepUrl(), which uses helpers.Urlize to
convert urls such as 'My First Link' to 'my-first-link'.
The behaviour is backwards: we do not want to run helpers.Urlize on the
BaseUrl, only on the absolute component. Currently, a BaseUrl such as
'http://my.edu/ENG101' will be converted to 'http://my.edu/eng101',
resulting in broken links in all of my menus.
This commit switches the URL prep and BaseUrl prepending actions around. I
would argue that these URLs shouldn't be run through prepUrl anyway
because the site developer has specified them explicitly in a config file
and might be surprised for, e.g., URLs to change case, but that's another
commit for another time.
canonifyUrls=true, RelPermalink and baseUrl with sub-path did not work.
This fixes that by adding a check for canonifyUrl=trues=true in RelPermalink().
So given
- baseUrl "http://somehost.com/sub/"
- the path "some-path/file.html"
For canonifyUrls=false RelPermalink() returns "/sub/some-path/file.html"
For canonifyUrls=true RelPermalink() returns "/some-path/file.html"
In the last case, the Url will be made absolute and clickable in a later step.
This commit also makes the menu urls defined in site config releative. To make them work with canonifying of urls, the context root is prepended if canonifying is turned off.
Fixes#519Fixes#711
Added Version, CommitHash and BuildDate to hugolib/hugo.go and used it in build
Removed commitHash and buildDate from commands/version.go and used hugolib vars
Removed getDateFormat function from commands/version.go
Conflicts:
README.md
docs/content/templates/variables.md
Menu urls like /categories/новости-проекта would turn into /categories/d0bdd0bed0b2d0bed181d182d0b8-d0bfd180d0bed0b5d0bad182d0b0, which is illegal, while the directory under the categories/ is created with the original name. It results in 404 not found error.
This commit fixes that by make sure that SanitizeUrl() is called last.
Fixes#719
- `.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.
- Prevent `.xml` generation for root section
- Remove redundant check for DisableRSS
- Fix permalinks for rel="alternate"
- Rename generated xml file to <type>/index.xml
- Add required description element in default template
- Make default RSS template validate on w3c (timezone format is still an issue)
Conflicts:
hugolib/site.go
- Change order of HasPrefix to match correct order
- Remove theme concatenation to _internal in last loop of
appendthemetemplates so it looks in the right place for internal
templates
Conflicts:
hugolib/site.go
- In `layouts/_default/taxonomy.html`, the `.Data` result does not
provide the same information that `layouts/_default/terms.html` does
for being able to identify the plural value of the term.
- This change adds `.Data.Singular` and `.Data.Plural` to provide
similar capabilities.
- This *may* be incompatible with templates that check for `{{ if ne
$taxonomy "Pages" }}` if the `page.Params` has either the singular or
plural values as keys.
…`map[string]string` to `map[string]interface{}`.
This allows values other than `string` values to be saved to Author,
such as:
```toml
# config.toml
…
[Author]
name = "Austin Ziegler"
social-site = [ "Facebook", "Twitter", "GitHub" ]
```
My specific use-case is that I’m trying to make something work similar
whether it’s specified in `.Params.Author` or in `.Site.Author` without
introducing `.Site.Params.Author`.
Prior to this commit, `HasMenuCurrent` and `IsMenuCurrent` on `Node` always returned false.
This made it hard (if possible at all) to mark the currently selected menu item/group for non-Page content (home page, category pages etc.), i.e. for menus defined in the site configuration.
This commit provides an implementation of these two methods.
Notable design choices:
* These menu items have a loose coupling to the the resources they navigate to; the `Url` is the best common identificator. To facilitate a consistent matching, and to get it in line with the menu items connected to `Page`, relative Urls (Urls starting with '/') for menu items in the site configuration are converted to permaLinks using the same rules used for others’.
* `IsMenuCurrent` only looks at the children of the current node; this is in line with the implementation on `Page`.
* Due to this loose coupling, `IsMenuCurrent` have to search downards in the tree to make sure that the node is inside the current menu. This could have been made simpler if it could answer `yes` to any match of any menu item matching the current resource.
This commit also adds a set of unit tests for the menu system.
Fixes#367
