This commits reworks how file caching is performed in Hugo. Now there is only one way, and it can be configured.
This is the default configuration:
```toml
[caches]
[caches.getjson]
dir = ":cacheDir"
maxAge = -1
[caches.getcsv]
dir = ":cacheDir"
maxAge = -1
[caches.images]
dir = ":resourceDir/_gen"
maxAge = -1
[caches.assets]
dir = ":resourceDir/_gen"
maxAge = -1
```
You can override any of these cache setting in your own `config.toml`.
The placeholders explained:
`:cacheDir`: This is the value of the `cacheDir` config option if set (can also be set via OS env variable `HUGO_CACHEDIR`). It will fall back to `/opt/build/cache/hugo_cache/` on Netlify, or a `hugo_cache` directory below the OS temp dir for the others.
`:resourceDir`: This is the value of the `resourceDir` config option.
`maxAge` is the time in seconds before a cache entry will be evicted, -1 means forever and 0 effectively turns that particular cache off.
This means that if you run your builds on Netlify, all caches configured with `:cacheDir` will be saved and restored on the next build. For other CI vendors, please read their documentation. For an CircleCI example, see 6c3960a8f4/.circleci/config.ymlFixes#5404
This commit also pulls down the log level for a set of WARN statements to INFO. There should be no ERRORs or WARNINGs in a regular Hugo build. That is the story about the Boy Who Cried Wolf.
Since the WARN log is now more visible, this commit also improves on some of them, most notable the "layout not found", which now would look something like this:
```bash
WARN 2018/11/02 09:02:18 Found no layout for "home", language "en", output format "CSS": create a template below /layouts with one of these filenames: index.en.css.css, home.en.css.css, list.en.css.css, index.css.css, home.css.css, list.css.css, index.en.css, home.en.css, list.en.css, index.css, home.css, list.css, _default/index.en.css.css, _default/home.en.css.css, _default/list.en.css.css, _default/index.css.css, _default/home.css.css, _default/list.css.css, _default/index.en.css, _default/home.en.css, _default/list.en.css, _default/index.css, _default/home.css, _default/list.css
```
Fixes#5203
We do that by re-render visited pages that is not already in the stack. This may potentially do some double work, but that small penalty should be well worth it.
Fixes#5281
The main item in this commit is showing of errors with a file context when running `hugo server`.
This can be turned off: `hugo server --disableBrowserError` (can also be set in `config.toml`).
But to get there, the error handling in Hugo needed a revision. There are some items left TODO for commits soon to follow, most notable errors in content and config files.
Fixes#5284Fixes#5290
See #5325
See #5324
Given this content:
```bash
archetypes
├── default.md
└── post-bundle
├── bio.md
├── images
│ └── featured.jpg
└── index.md
```
```bash
hugo new --kind post-bundle post/my-post
```
Will create a new folder in `/content/post/my-post` with the same set of files as in the `post-bundle` archetypes folder.
This commit also improves the archetype language detection, so, if you use template code in your content files, the `.Site` you get is for the correct language. This also means that it is now possible to translate strings defined in the `i18n` bundles, e.g. `{{ i18n "hello" }}`.
Fixes#4535
commands/hugo.go:65:1: exported method Response.IsUserError should have comment or be unexported
commands/import_jekyll.go💯21: error strings should not be capitalized or end with punctuation or a newline
commands/server.go:417:1: receiver name sc should be consistent with previous receiver name s for serverCmd
Hugo Pipes added minification support for resources fetched via ´resources.Get` and similar.
This also adds support for minification of the final output for supported output formats: HTML, XML, SVG, CSS, JavaScript, JSON.
To enable, run Hugo with the `--minify` flag:
```bash
hugo --minify
```
This commit is also a major spring cleaning of the `transform` package to allow the new minification step fit into that processing chain.
Fixes#1251
Before this commit, you would have to use page bundles to do image processing etc. in Hugo.
This commit adds
* A new `/assets` top-level project or theme dir (configurable via `assetDir`)
* A new template func, `resources.Get` which can be used to "get a resource" that can be further processed.
This means that you can now do this in your templates (or shortcodes):
```bash
{{ $sunset := (resources.Get "images/sunset.jpg").Fill "300x200" }}
```
This also adds a new `extended` build tag that enables powerful SCSS/SASS support with source maps. To compile this from source, you will also need a C compiler installed:
```
HUGO_BUILD_TAGS=extended mage install
```
Note that you can use output of the SCSS processing later in a non-SCSSS-enabled Hugo.
The `SCSS` processor is a _Resource transformation step_ and it can be chained with the many others in a pipeline:
```bash
{{ $css := resources.Get "styles.scss" | resources.ToCSS | resources.PostCSS | resources.Minify | resources.Fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
The transformation funcs above have aliases, so it can be shortened to:
```bash
{{ $css := resources.Get "styles.scss" | toCSS | postCSS | minify | fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
A quick tip would be to avoid the fingerprinting part, and possibly also the not-superfast `postCSS` when you're doing development, as it allows Hugo to be smarter about the rebuilding.
Documentation will follow, but have a look at the demo repo in https://github.com/bep/hugo-sass-test
New functions to create `Resource` objects:
* `resources.Get` (see above)
* `resources.FromString`: Create a Resource from a string.
New `Resource` transformation funcs:
* `resources.ToCSS`: Compile `SCSS` or `SASS` into `CSS`.
* `resources.PostCSS`: Process your CSS with PostCSS. Config file support (project or theme or passed as an option).
* `resources.Minify`: Currently supports `css`, `js`, `json`, `html`, `svg`, `xml`.
* `resources.Fingerprint`: Creates a fingerprinted version of the given Resource with Subresource Integrity..
* `resources.Concat`: Concatenates a list of Resource objects. Think of this as a poor man's bundler.
* `resources.ExecuteAsTemplate`: Parses and executes the given Resource and data context (e.g. .Site) as a Go template.
Fixes#4381Fixes#4903Fixes#4858
This was a un-intended change in Hugo 0.42. Most sites will have a static directory so this should not be a big issue, but this commit will revert back to old behaviour.
Fixes#4846
This commit adds support for theme composition and inheritance in Hugo.
With this, it helps thinking about a theme as a set of ordered components:
```toml
theme = ["my-shortcodes", "base-theme", "hyde"]
```
The theme definition example above in `config.toml` creates a theme with the 3 components with presedence from left to right.
So, Hugo will, for any given file, data entry etc., look first in the project, and then in `my-shortcode`, `base-theme` and lastly `hyde`.
Hugo uses two different algorithms to merge the filesystems, depending on the file type:
* For `i18n` and `data` files, Hugo merges deeply using the translation id and data key inside the files.
* For `static`, `layouts` (templates) and `archetypes` files, these are merged on file level. So the left-most file will be chosen.
The name used in the `theme` definition above must match a folder in `/your-site/themes`, e.g. `/your-site/themes/my-shortcodes`. There are plans to improve on this and get a URL scheme so this can be resolved automatically.
Also note that a component that is part of a theme can have its own configuration file, e.g. `config.toml`. There are currently some restrictions to what a theme component can configure:
* `params` (global and per language)
* `menu` (global and per language)
* `outputformats` and `mediatypes`
The same rules apply here: The left-most param/menu etc. with the same ID will win. There are some hidden and experimental namespace support in the above, which we will work to improve in the future, but theme authors are encouraged to create their own namespaces to avoid naming conflicts.
A final note: Themes/components can also have a `theme` definition in their `config.toml` and similar, which is the "inheritance" part of this commit's title. This is currently not supported by the Hugo theme site. We will have to wait for some "auto dependency" feature to be implemented for that to happen, but this can be a powerful feature if you want to create your own theme-variant based on others.
Fixes#4460Fixes#4450
We have no global `Hugo` object no more (yay!), and there are some external tools that depends on that value.
These tools need to use get that value from `Response.Result`.
Note that `commands.Execute` now also takes the arguments as a string slice. This should also make it easier to use, not having to modify `os.Args`.
This commit also wraps up this particular issue. Phew!
Test coverage in /commands before: 14.4%
Now: 53.5%
Still work to do, now it is at least possible.
Closes#4598
A sample config:
```toml
defaultContentLanguage = "en"
defaultContentLanguageInSubdir = true
[Languages]
[Languages.en]
weight = 10
title = "In English"
languageName = "English"
contentDir = "content/english"
[Languages.nn]
weight = 20
title = "På Norsk"
languageName = "Norsk"
contentDir = "content/norwegian"
```
The value of `contentDir` can be any valid path, even absolute path references. The only restriction is that the content dirs cannot overlap.
The content files will be assigned a language by
1. The placement: `content/norwegian/post/my-post.md` will be read as Norwegian content.
2. The filename: `content/english/post/my-post.nn.md` will be read as Norwegian even if it lives in the English content folder.
The content directories will be merged into a big virtual filesystem with one simple rule: The most specific language file will win.
This means that if both `content/norwegian/post/my-post.md` and `content/english/post/my-post.nn.md` exists, they will be considered duplicates and the version inside `content/norwegian` will win.
Note that translations will be automatically assigned by Hugo by the content file's relative placement, so `content/norwegian/post/my-post.md` will be a translation of `content/english/post/my-post.md`.
If this does not work for you, you can connect the translations together by setting a `translationKey` in the content files' front matter.
Fixes#4523Fixes#4552Fixes#4553
This allows a `config.toml` (or `yaml`, ´yml`, or `json`) in the theme to set:
1) `params` (but cannot override params in project. Will also get its own "namespace", i.e. `{{ .Site.Params.mytheme.my_param }}` will be the same as `{{ .Site.Params.my_param }}` providing that the main project does not define a param with that key.
2) `menu` -- but cannot redefine/add menus in the project. Must create its own menus with its own identifiers.
3) `languages` -- only `params` and `menu`. Same rules as above.
4) **new** `outputFormats`
5) **new** `mediaTypes`
This should help with the "theme portability" issue and people having to copy and paste lots of setting into their projects.
Fixes#4490
According to @bep, it is easier to undraft content by
editing manually the frontmatter of said content by
setting the draft flag to `false`, or removing it completely,
than to rely on the undraft command which is a source of
many bugs.
Fixes#4353
The current behaviour addes a `url` attribute to the frontmatter of all posts imported from Jeklly and assumes the desired permalink structure is /:year/:month/:day/:title/. This may be the case for most peeps, but poses a problem for those that don't use this permalink structure as the `url` attribute takes precedence over the `permalink` attribute in the site-wide configuration meaning it can't be overruled.
This changes the behaviour to only set the `url` attribute if the `permalink` attribute is set in the Jekyll frontmatter.
The duplication of the confirmation message is also removed.
Tests have been updated to reflect this change in behaviour.
Fixes#1887
This commit adds a new config setting:
```toml
disableLanguages = ["fr"]
```
If this is a multilingual site:
* No site for the French language will be created
* French content pages will be ignored/not read
* The French language configuration (menus etc.) will also be ignored
This makes it possible to start translating new languages and turn it on when you're happy etc.
Fixes#4297Fixed#4329
* Page without front matter now treated same as a page with empty front matter.
* Test cases added to cover this and repro issue #4320.
* Type safety of front matter code improved.
Fixes#4320
The `--renderToMemory` flag stopped working on `hugo` in 0.32.
Note that this is only useful for benchmark testing, as there is no easy way to actually view the result.
Fixes#4212
This commit is not the smallest in Hugo's history.
Some hightlights include:
* Page bundles (for complete articles, keeping images and content together etc.).
* Bundled images can be processed in as many versions/sizes as you need with the three methods `Resize`, `Fill` and `Fit`.
* Processed images are cached inside `resources/_gen/images` (default) in your project.
* Symbolic links (both files and dirs) are now allowed anywhere inside /content
* A new table based build summary
* The "Total in nn ms" now reports the total including the handling of the files inside /static. So if it now reports more than you're used to, it is just **more real** and probably faster than before (see below).
A site building benchmark run compared to `v0.31.1` shows that this should be slightly faster and use less memory:
```bash
▶ ./benchSite.sh "TOML,num_langs=.*,num_root_sections=5,num_pages=(500|1000),tags_per_page=5,shortcodes,render"
benchmark old ns/op new ns/op delta
BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 101785785 78067944 -23.30%
BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 185481057 149159919 -19.58%
BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 103149918 85679409 -16.94%
BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 203515478 169208775 -16.86%
benchmark old allocs new allocs delta
BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 532464 391539 -26.47%
BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 1056549 772702 -26.87%
BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 555974 406630 -26.86%
BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 1086545 789922 -27.30%
benchmark old bytes new bytes delta
BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 53243246 43598155 -18.12%
BenchmarkSiteBuilding/TOML,num_langs=1,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 105811617 86087116 -18.64%
BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=500,tags_per_page=5,shortcodes,render-4 54558852 44545097 -18.35%
BenchmarkSiteBuilding/TOML,num_langs=3,num_root_sections=5,num_pages=1000,tags_per_page=5,shortcodes,render-4 106903858 86978413 -18.64%
```
Fixes#3651Closes#3158Fixes#1014Closes#2021Fixes#1240
Updates #3757
This commit adds support for multiple statDirs both on the global and language level.
A simple `config.toml` example:
```bash
staticDir = ["static1", "static2"]
[languages]
[languages.no]
staticDir = ["staticDir_override", "static_no"]
baseURL = "https://example.no"
languageName = "Norsk"
weight = 1
title = "På norsk"
[languages.en]
staticDir2 = "static_en"
baseURL = "https://example.com"
languageName = "English"
weight = 2
title = "In English"
```
In the above, with no theme used:
the English site will get its static files as a union of "static1", "static2" and "static_en". On file duplicates, the right-most version will win.
the Norwegian site will get its static files as a union of "staticDir_override" and "static_no".
This commit also concludes the Multihost support in #4027.
Fixes#36Closes#4027
Hugo already, in its server mode, support partial rebuilds. To put it simply: If you change `about.md`, only that content page is read and processed, then Hugo does some processing (taxonomies etc.) and the full site is rendered.
This commit covers the rendering part: We now only re-render the pages you work on, i.e. the last n pages you watched in the browser (which obviously also includes the page in the example above).
To be more specific: When you are running the hugo server in watch (aka. livereload) mode, and change a template or a content file, then we do a partial re-rendering of the following:
* The current content page (if it is a content change)
* The home page
* Up to the last 10 pages you visited on the site.
This should in most cases be enough, but if you navigate to something completely different, you may see stale content. Doing an edit will then refresh that page.
Note that this feature is enabled by default. To turn it off, run `hugo server --disableFastRender`.
Fixes#3962
See #1643
This commit adds a "cache potential" column when running `hugo --templateMetrics --templateMetricsHints`.
This is only calculated when `--templateMetricsHints` is set, as these calculations has an negative effect on the other timings.
This gives a value for partials only, and is a number between 0-100 that indicates if `partial` can be replaced with `partialCached`.
100 means that all execution of the same partial resulted in the same output.
You should do some manual research before going "all cache".
This makes live reloading behind a HTTPS proxy working, as in the example below using the service from https://ngrok.com:
```
hugo server -b https://ba6sdfe72.ngrok.io --appendPort=false --liveReloadPort=443 --navigateToChanged
```
Fixes#3882
This rewrites the release logic to use CircleCI 2.0 and its approve workflow in combination with the state of the release notes to determine what to do next.
Fixes#3779
Why:
* first time using hugo I got very little info from --verbose output
but I noticed there is quite a lot of useful DEBUG logging
* asked for in other issues like https://github.com/gohugoio/hugo/issues/3514
This change addreses the need by:
* adding a simple --debug flag which simply turns on debug level in stdout
and logoutput if enabled.
This ensures the new "open 'current content page' in browser" works
on Windows, especially with Emacs and Vim.
Special thanks to @bep for coming up with the idea of the fix.
See #3645
This commit adds a new `--navigateToChanged` and config setting with the same name, that, when running the Hugo server with live reload enabled, will navigate to the current content file's URL on save.
This is really useful for site-wide content changes (copyedits etc.).
Fixes#3643
This commit completes the "The Revival of the Archetypes!"
If `.Site` is used in the arcetype template, the site is built and added to the template context.
Note that this may be potentially time consuming for big sites.
A more complete example would then be for the section `newsletter` and the archetype file `archetypes/newsletter.md`:
```
---
title: "{{ replace .TranslationBaseName "-" " " | title }}"
date: {{ .Date }}
tags:
- x
categories:
- x
draft: true
---
<!--more-->
{{ range first 10 ( where .Site.RegularPages "Type" "cool" ) }}
* {{ .Title }}
{{ end }}
```
And then create a new post with:
```bash
hugo new newsletter/the-latest-cool.stuff.md
```
**Hot Tip:** If you set the `newContentEditor` configuration variable to an editor on your `PATH`, the newly created article will be opened.
The above _newsletter type archetype_ illustrates the possibilities: The full Hugo `.Site` and all of Hugo's template funcs can be used in the archetype file.
Fixes#1629
This commit removes the fragile front matter decoding, and takes the provided archetype file as-is and processes it as a template.
This also means that we no longer will attempt to fill in default values for `title` and `date`.
The upside is that it is now easy to create these values in a dynamic way:
```toml
+++
title = {{ .BaseFileName | title }}
date = {{ .Date }}
draft = true
+++
```
You can currently use all of Hugo's template funcs, but the data context is currently very shallow:
* `.Type` gives the archetype kind provided
* `.Name` gives the target file name without extension.
* `.Path` gives the target file name
* `.Date` gives the current time as RFC3339 formatted string
The above will probably be extended in #1629.
Fixes#452
Updates #1629
This issue is more visible now that we support nested sections.
This commit makes operations like pasting new content folders or deleting content folders during server watch just work.
Fixes#3570
We still have go-toml as a transitive dependency, and it is the way to go eventually, but we care about speed, so let us wait that one out.
Note that the issue this fixes is about taxonomies, but I guess this is a general issue for sites with many pages that uses TOML as front matter.
```
benchmark old ns/op new ns/op delta
BenchmarkFrontmatterTags/TOML:1-4 23206 8543 -63.19%
BenchmarkFrontmatterTags/TOML:11-4 80117 18495 -76.92%
BenchmarkFrontmatterTags/TOML:21-4 140676 28727 -79.58%
benchmark old allocs new allocs delta
BenchmarkFrontmatterTags/TOML:1-4 173 60 -65.32%
BenchmarkFrontmatterTags/TOML:11-4 625 138 -77.92%
BenchmarkFrontmatterTags/TOML:21-4 1106 210 -81.01%
benchmark old bytes new bytes delta
BenchmarkFrontmatterTags/TOML:1-4 9231 2912 -68.45%
BenchmarkFrontmatterTags/TOML:11-4 19808 5184 -73.83%
BenchmarkFrontmatterTags/TOML:21-4 31200 7536 -75.85%
```
See #3541
Updates #3464
This commit adds a work flow aroung GoReleaser to get the Hugo release process automated and more uniform:
* It can be run fully automated or in two steps to allow for manual edits of the relase notes.
* It supports both patch and full releases.
* It fetches author, issue, repo info. etc. for the release notes from GitHub.
* The file names produced are mainly the same as before, but we no use tar.gz as archive for all Unix versions.
* There isn't a fully automated CI setup in place yet, but the release tag is marked in the commit message with "[ci deploy]"
Fixes#3358
This makes it consistent with how it behaves when it's set in config.toml.
This commit also unifies BaseURL in Site.Info so we now have one source for this value.
Fixes#3262
This commit also adds a new command, docshelper, with some utility funcs that adds a JSON datafiles to /docs/data that would be a pain to create and maintain by hand.
Fixes#3242
Lots of cleanups here:
- Refactor InterfaceToConfig and InterfaceToFrontMatter to use io.Writer.
- Simplify InterfaceToFrontMatter by wrapping InterfaceToConfig.
- Export FrontmatterType since we return it in DetectFrontMatter.
- Refactor removeTOMLIdentifier to avoid blindly replacing "+++".
- Update HandleJSONMetaData to return an empty map on nil input.
- Updates vendored goorgeous package and test for org-mode frontmatter.
- Add tests and godoc comments.
Coverage for parser package increased from 45.2% to 85.2%.
Note that this looks like overkill for just the logger, and that is correct,
but this will make sense once we start with the template handling etc.
Updates #2701
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
* Add information about average time, memory consumption and
allocations.
* Fix situation, when user provides memprofile and cpuprofile, but
cpuprofile will not created.
Fixes#2432
This commit adds a `GitInfo` object to `Page` if `EnableGitInfo` is set.
It then also sets `Lastmod` for the given `Page` to the author date provided by Git.
The Git integrations should be fairly performant, but it adds "some time" to the build, somewhat depending on the Git history size.
If you want, you can run without during development and turn it on when deploying to the live server: `hugo --enableGitInfo`.
Fixes#2102
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.
Changes `%q` to `%s`. `%q` was safely escaping the `\` in windows so that it was printing `\\`. Uses `filepath.Join` for example filepath so that the output is OS specific and since this required splitting up the multiline string, it's refactored into a separate function..
Fixes#2401
* Fall back to default language on missing translation file
* Add a i18n-warnings build flag
* If that flag is set, print a parseable and greppable string on missing translation strings
See #2303
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
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
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..
Hugo seems to ignore the meminterval I specify and always uses it's default of 100ms.
This seems to be because Hugo tries to take the meminterval from the command line
(an Int) and converts it to a String and passes it to time.ParseDuration. If you pass a
different meminterval (such as `1000` as above) it will fail (time.ParseDuration requires
some units) and use the default instead.
Changed `meminterval` to be a String and added better documentation for valid time units.
Resolves: #2325
On 4679fbee41, rebuild was disabled on
CHMOD filesystem events, but the code is overly aggressive.
In some situations, specially with older Mac's (using a Late 2008
Macbook), the events we receive might be aggregated. On my
particular laptop, I get this events:
INFO: 2016/07/26 18:08:51 hugo.go:737: Received System Events: ["<path>": WRITE|CHMOD]
These events are ignored because the code only checks for Chmod. This
commit fixes this by checking that the event is also not a Write or Create.
Related to #1587.
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 disables highlighting for fenced code blocks without explicitly specified language. It also introduces a new `PygmentsCodeFencesGuessSyntax` config option (defaulting to false).
To enable syntax guessing again, add the following to your config file: `PygmentsCodeFencesGuessSyntax = true`
This is a breaking change.
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
NewContent is refactored to use the afero.Fs interface that should allow
full testing. This commit also pulls the metadata creation logic out of
NewContent and into a separate function to decrease the cyclomatic
complexity of NewContent.
This uses the Emoji map from https://github.com/kyokomi/emoji -- but with a custom replacement implementation.
The built-in are fine for most use cases, but in Hugo we do care about pure speed.
The benchmarks below are skewed in Hugo's direction as the source and result is a byte slice,
Kyokomi's implementation works best with strings.
Curious: The easy-to-use `strings.Replacer` is also plenty fast.
```
BenchmarkEmojiKyokomiFprint-4 20000 86038 ns/op 33960 B/op 117 allocs/op
BenchmarkEmojiKyokomiSprint-4 20000 83252 ns/op 38232 B/op 122 allocs/op
BenchmarkEmojiStringsReplacer-4 100000 21092 ns/op 17248 B/op 25 allocs/op
BenchmarkHugoEmoji-4 500000 5728 ns/op 624 B/op 13 allocs/op
```
Fixes#1891
See #1772
Also, force DisableLiveReload to true when running "hugo --watch"
(build-only non-server mode) to prevent livereload.ForceRefresh(),
which would end up blocking watchConfig() forever, from being called
because livereload.Initialize() is never called in this case.
This fixes the bug where "hugo --watch" could only reload config.toml
once before it gets stuck for good at livereload.ForceRefresh().
This is also consistent with Hugo's existing behaviour:
Non-server "hugo --watch" has never injected livereload.js
since the inception of the "watch" feature in Hugo v0.12.
