The world’s fastest framework for building websites.

The goal is to:

• have support to write content/post/whatever.en.md to /en/2015/12/22/whatever/index.html
• do the same with whatever.fr.md into /fr/2015/12/22
• enable or disable with the "Multilingual" switch in the config
• support having language switchers in templates, that know where the translated page is (with .Page.Translations) (when you're on /en/about/, there's a "Francais" link that points to /fr/a-propos)

Missing:

• example usage of the .Page.Translations feature.
• shortcode or function to do i18n of strings, without resorting to: {{ ( index $.Site.Data.translations $.Site.Params.locale ).topslogan }}
  • I'd like it to be based on data / JSON / YAML, but use a convention.
  • https://github.com/nicksnyder/go-i18n seems like a good candidate to do server-side translation if we want all the bells and whistles of a translation engine.. Has tooling to build translation workflows too.
• how to run it with two configs (one for each language), yet having something that writes the root "index.html" and redirect to something that either considers the users' browser, or has a fixed language redirection.

This is basic code to open up a discussion as to how best we could handle that.

I was thinking of exposing more Translations functionalities directly in the .Site, to crawl through one set of pages (instead of looping through all Pages, even though some are duplicated). Something like BaseLanguagePages ? and all those Page would have pointers to their translations.

We could run the generation once for each language, and each time generating a /fr, or /en subtree.. consistent in itself.. and knowing about "the other side" of translations (through .Page.Translations). In that case, maybe Site.Pages could have only those of the current translation, but .Page.Translations would know of the others.. that might simplify menu generation and all, as it would never need to know about other translations, unless explicitly asked to.

So @spf13, what do you think of all that ?

Here's the first attempt at standardizing Hugo author details.

1. Data lives in /data/authors with one file per author. I thought about nesting it in /data/site/authors or /data/hugo/authors, but those seemed unnecessarily hidden.
2. Author front matter is an array to support multiple authors, though it will be up to themes to support multiple authors or not. There is a convenience .Author method to return a single author. if there are multiple authors and this is used, there is no guarantee which author will be returned
3. I changed .Site.Author from map[string]interface{} to Author, though I don't know if that is in use outside of the embedded RSS feed
4. Social data should only be the username
5. For Author social details, I added a .URL() convenience method that returns canonical urls for major social networks
6. I added a params section to the author, though as of right now it is map[string]string instead of map[string]interface{}
7. I use snake_case in the data files but templates will access them with PascalCase
8. Here's a sample author file

given_name      = "Derek"
family_name     = "Perkins"
display_name    = "Derek Perkins"
thumbnail       = "img link"
image           = "img link"
short_bio       = "super short bio"
bio             = "Here's Derek's awesome bio"
email           = "[email protected]"

[social]
    facebook    = "derekperkins"
    github      = "derekperkins"
    twitter     = "derek_perkins"
    googleplus  = "DerekPerkins1"

[params]
   random       = "whatever you want"

I realize you probably picked deliberately, but I will ask anyway. :-)

For personal use the license is fine, but it would be nicer if the software had a properly open license (apache, bsd or MIT for example) for "corporate use". It's not about not contributing back, but just the added legal hassle using contagious licenses in anything.

This is related to #4429 and #4381 but put in its own thread to get the attention it deserves.

| Current Name | What is it| | --- | --- | | resources.Get ✅ | Creates a new Resource object given a path to a file in /assets (configurable). This also works for images that you can then scale. Anything with a MIME type recognized by Hugo (and you can define your own if you want). | | resources.GetMatch | Same as resources.Get, but uses pattern matching to find the first match.| | resources.Match | Create a slice of Resource objects matching the given pattern. See resources.Concat for a function that could use this. | | resources.ToCSS ✅ | Transform a Resource to CSS based on the source MIME type. In the first version, we will support SCSS. An implementation note here is that we will persist the result of this transformation, so if you later run this from a non-SASS-enabled Hugo, it will still work. When we finally get some proper plugin support in Hugo, these resource transformations will be candidates to queue up and send to external processors. | | resources.PostCSS ✅| See #4858 | | resources.Minify ✅ | Minifies the given Resource based on the source MIME type. Currently supports css, js, json, html, svg, xml. It will get a new RelPermalink and Permalink, e.g. /css/main.min.css. | | resources.Fingerprint ✅ | Creates a fingerprinted version of the given Resource; it will get a new RelPermalink and Permalink, e.g. /css/main.eae6b4ebececc2bbd7490966a5e01bcc.css. It defaults to sha256, but you can pass either md5, sha256or sha512 as an argument. | | Integrity ✅ | Available as .Data.Integrity on fingerprinted resources. See https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity. Note that if you want the Integrity, but don't care about the fingerprinting (aka cache-busting part), you can just apply the fingerprint function, and just use .Data.Integrity (i.e. not use RelPermalink etc.) | | 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. Use your imagination for use cases for this one :-) | | resources.FromString ✅| Create a Resource from a string. |

All of the above can be chained. So you can do {{ (resources.Resource "styles.scss" | resources.ToCSS | resource.Minify | resources.FingerPrint).RelPermalink }} etc.

Note that I'm not sure that all of the above will arrive in the next Hugo version, but most of these are cheap to implement once the "resource chain" infrastructure is in place.

So I want your input on the above. And note that most of these requires a Resource object to work. You may like or hate that term, but it's there. Which is a reason I have put all of these funcs into the resources namespace.

Following the discussion at the forum: https://discourse.gohugo.io/t/hugo-vs-the-general-data-protection-regulations-gdpr-in-eu-eea/11526/12

I will focus on the Google Analytics internal template in this first post. But feel free to add suggestions about other templates such as Disqus, Twitter etc

Google Analytics

Notes

1. The following suggestions are for Analytics.js that is used in the current internal template

2. For Google Tag Manager things are more complicated and the user needs to set various settings directly in the Google Analytics dashboard. I'm not using Google Tag Manager myself and I cannot help with it.

3. I am not some expert these suggestions are my own research and feel free to build on them to help @bep build the internal templates that will make Hugo offer GDPR compliant websites out of the box.

The general idea I am proposing is to make the Hugo GA internal template not collect any personally identifiable information so that it falls outside the scope of the GDPR. With such settings a Hugo site admin will not need user opt-in for Google Analytics cookies because no such cookies will be installed on a user's device. However as you may have guessed this will severely limit GA reporting. Namely no returning visitors etc. Also the owner of a GA property should have the User ID, Google Data Sharing and Advertising features disabled on their dashboard.

Note Enabling any of the above features or using the default Google Analytics code as is in the Hugo internal template requires user opt-in on the frontend. The tricky part is that you will need to have Google Analytics disabled until the user agrees to it. I am not going to cover this scenario here.

The key settings that need to change in the internal template are: Anonymize IP The GDPR treats IPs as personally identifiable information so the following should be enabled in the tracking code: ga('set', 'anonymizeIp', true); reference

Disable Cookies and Use Session Storage to Store the Client ID Session Storage is for the duration of a user's visit on a website. Even the Client ID is treated as Personally Identifiable Information in some quarters. There is no consensus about this currently. See a blog post about this here

var GA_SESSION_STORAGE_KEY = 'ga:clientId';
if (window.sessionStorage) {
  ga('create', 'UA-XXXXX-Y', {
    'storage': 'none',
    'clientId': sessionStorage.getItem(GA_SESSION_STORAGE_KEY)
  });
  ga(function(tracker) {
    sessionStorage.setItem(GA_SESSION_STORAGE_KEY, tracker.get('clientId'));
  });
}
else {
  ga('create', 'UA-XXXXX-Y', 'auto');
}
ga('send', 'pageview');

The above is a modified version of Google's sample code for using Local Storage to store the Client ID.

However Local Storage is persistent until cleared by the user and as such a Hugo site admin would still need user opt-in as Local Storage is treated the same as cookies.

There are caveats with the above setup below is the disclaimer by Google in the above page I linked to:

Note: unlike cookies, localStorage is bound by the same-origin policy. If parts of your site are on different subdomains, or if some pages use http and others pages use https, you cannot use localStorage to track users between those pages. For this reason, cookies continues to be the officially recommended way to store the Client ID.

Basically what the GDPR does is to limit Data Collection to the bare minimum. A setup as the one I propose above would make the Hugo GA internal template GDPR compliant but at the expense of GA reporting.

It's up to the community to decide how to go about this.

I know this has been requested before, in the form of some extends = some-other-theme.

This isn't "theme inheritance" in its purest form (which would be "theme1 extends theme2 extends theme3"), more like theme composition. Which is much simpler to understand/implement, but with most of the added benefits.

This relates to my work on https://github.com/bep/html5up-to-hugo -- which, with the current Hugo, becomes less elegant than it could be.

The simple rule is that the themes' files will form a big overlay/union file system from left to right.

So:

theme = ["base", "my-theme" ]

• All files in base will be used unless there is a file with the same name in my-theme.
• This will work with layouts, data, i18n, static (and in the future: content etc.)

What do you say?

This issue has been discussed before: #3462 etc.

• A content folder is identified as a bundle if it contains either a _index.* or a index.* file.
• For index.* files (i.e. single content pages) type of bundles, the bundle will also include any sub folders (i.e. images etc.).

Thinking in Go terms, we add a new Resource type (a Page is a Resource):

interface Resource {
   Permalink() string
   RelPermalink() string
}

• $funnyCatsPage.Pages => [even-more-content.md, more-content.md]
• $funnyCatsPage.Resources => [even-more-content.md, more-content.md, cat.jpg, another-cat.jpg]
• $funnyCatsPage.Resources.ByType "image" => [cat.jpg, another-cat.jpg]
• The sub-content-pages will not have Permalink, i.e they will not be rendered to disk on its own, but will typically be used to compose the "bag page".

A Page is a Resource, but we will need others, one example would be Image, which would have some additional image related properties, such as Width and Height, but also methods to generate alternate versions of that image:

$cat := $funnyCatsPage.GetResource "image" "cat.jpg"
$scaled := $cat.Scale "1000x600"

<img src="{{ $scaled.Permalink }}" width={{ $scaled.Width }} height={{ $scaled.Height }}>

The API above is just an example. But I think this "processing only when needed" will scale better than, say, create 5 different version of every image, even if only a small fraction is in actual use.

NOTE: This proposal is about how the bags in Hugo should look like at its core -- it is not about details in a future image scaling APIs etc. The only way to get this done is to define a fairly narrow scope.

TODO: Permalinking, ...

Related

• Galleries
• Image cropping, resizing and compression, see #3207 etc.
• Resource linking in markdown (with cropping, resizing etc.)
• ??

Previous related issue 'Shortcode output wrapped in <p> tags' #1148 which was closed with 004fcdd.

Consistent incorrect wrapping of shortcode output under certain conditions

Reported in discuss forum here.

Salient points:

1. If there is just one shortcode, it doesn't get wrapped in <p> tags

2. If there are multiple shortcodes, the first doesn't get wrapped in <p> tags (probably related to above)

3. In order to ensure no shortcodes are wrapped in <p> tags, the final shortcode must be followed by a number of distinct <p> tag wrapped lines proportionate to the number of shortcodes in the document.

By that I mean if you have say 6 shortcodes one after the other, you need 16 lines following them in order for none to be wrapped in <p> tags. If you have 5 shortcodes one after the other you need 12 lines.

4. 'Lines following shortcode' don't have to come at the end of the document, if you have a series of shortcodes it seems the number of interceeding <p> tag wrapped lines are cumulatively ranked towards each consecutive shortcode so if you had 30 lines interspaced between shortcodes throughout the document, as long as each shortcode has at least 5 proceeding lines each, they'll all be spared wrapping.

5. Related to point 4, the <p> tags that get wrapped around shortcodes incorrectly also count towards the number of <p> tag wrapped lines needed to follow preceeding shortcodes - so enough shortcodes in a row and you seem to be about to start unwrapping some of the 'first' few in the list.

6. Length of shortcode title attribute also affects whether output wrapped in <p> tags though this has not been investigated in detail

NOTE - I may have miss counted the exact number of lines in between shortcodes, my eyes were actually bleeding...

See:

• The notes in https://github.com/gohugoio/hugo/issues/5681
• The solved issues in https://github.com/gohugoio/hugo/milestone/87?closed=1
• It may also help to look at the open issues: https://github.com/gohugoio/hugo/milestone/87

The important bits of that release is now implemented and merged to master.

I have tested this extensively manually myself, but I would really appreciate that you if you know how to compile Hugo from source, can take this for a spin on your site.

It's cool if you also test the "new stuff", but I'm mostly curious about if this somehow breaks anything in your site. And if it somehow breaks for you, access to the source code so I could see how and what would be gold. I'm not looking for more feature requests (as in "it would be cool if that also ...") as this has already been one of the most work-intensive releases.

I would strongly recommend that you build with the latest Go 1.12.1.

It lives behind a trimTrailingSlash option in config.toml. There is no CLI flag for this option.

It works by hooking into the uglyURLs functionality and then stripping out the .html suffix when generating URLs. This means it generates /filename.html files rather than /filename/index.html. It also handles when there's no trailing slash in the page's URL when set through the front matter.

It's all been tested, but if there are any I've missed please let me know.

I've documented the option in my fork of hugoDocs. I'll create a PR if/when this progresses.

See #3556 and https://discuss.gohugo.io/t/links-without-a-trailing-slash/831.

See https://github.com/bep/hugo/blob/custom-output/docs/content/extras/custom-output-types.md

Also see #2828 Also see https://discuss.gohugo.io/t/custom-output-content-types/4584

Applies to all releases

as per the above image, I would expect that this metadata is embedded in the executable so that I could determine from it what version is being run without needing to run it & as such is a security concern that this information is missing from the build

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.109.0 darwin/amd64 BuildDate=unknown

Does this issue reproduce with the latest release?

Yes, I am using the latest release.

This logic is wrong:

https://github.com/gohugoio/hugo/blob/f2946da9e806c2bafbdd26707fe339db79bd980b/hugolib/content_map.go#L362

Specifically, if a folder inside /content has a prefix matching a taxonomy, then it will be rendered twice, and be buggy.

You can reproduce this with the following commands.

The first build is correct, but the second build shows the buggy behavior.

Notice that the second build will render /tagstest/index.html twice -- the first time as page "Tagstest", the second time as "My test".

# quickstart
hugo new site quickstart
cd quickstart
git init
git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke themes/ananke
echo "theme = 'ananke'" >> config.toml
# create dummy section
mkdir content/test
echo -e "---\ntitle: My test\n---" >> content/test/_index.md
echo -e "---\ntitle: Test post\n---\n\nHello, world" >> content/test/post.md
# generate the page
hugo --debug
...
DEBUG 2022/12/27 19:06:51 Render page Test post to "/test/test/index.html"
DEBUG 2022/12/27 19:06:51 Render page My test to "/test/index.html"
DEBUG 2022/12/27 19:06:51 Render page My New Hugo Site to "/index.html"
DEBUG 2022/12/27 19:06:51 Render page Categories to "/categories/index.html"
DEBUG 2022/12/27 19:06:51 Render page Tags to "/tags/index.html"
...
# rename test folder to tagstest and rebuild
mv content/test content/tagstest
hugo --debug
...
DEBUG 2022/12/27 19:07:40 Render page Test post to "/tagstest/test/index.html"
DEBUG 2022/12/27 19:07:40 Render page Tagstests to "/tagstest/index.html"
DEBUG 2022/12/27 19:07:40 Render page My New Hugo Site to "/index.html"
DEBUG 2022/12/27 19:07:40 Render page Tags to "/tags/index.html"
DEBUG 2022/12/27 19:07:40 Render page Categories to "/categories/index.html"
DEBUG 2022/12/27 19:07:40 Render page My test to "/tagstest/index.html"
...

This is affecting me because I set my taxonomies to t: t:

taxonomies:
  t: t

Then any section starting with t fails to render correctly (in my case, /content/tutorials/_index.md).

I've been thinking about this for a long time, and this recent forum topic prompted me to create this proposal.

In my view, link and image render hooks are essential for:

1. Supporting portable links

2. Determining the URL of a page or resource when:

   • The site is served from a subdirectory (e.g., https:/example.org/foo/)
   • Rendering .Content instead of .Summary on a list page, or within another page
   • Front matter contains slug or url (or cascaded by ancestor or site configuration)
   • Site configuration contains permalinks key
   • Site configuration enables uglyURLs
   • Adding content to a multilingual site
   • And maybe some other things that I'm forgetting

Resolution of markdown links is one of the more frequent issues raised on the forum by new users. Without analyzing the data, I'd guess that it is in the top 10, or maybe the top 20.

With built-in templates, it will just... work.

I recognize that built-in templates are, by their very nature, opinionated—so we'll use mine. The problem with opinions is that everybody has one, as demonstrated by the number of issues and PR's against the existing built-in templates and shortcodes.

And that makes me somewhat hesitant to do this. But the net improvement in user experience may be worth it.

If we do this, there must be a configuration setting to enable the use of these internal templates, and it must default to false to avoid breaking existing sites. And, in my opinion, this is important enough that we might want to include it in the default configuration file generated by hugo new site foo. If I were creating a new site, it would be the first change I would make to the site configuration.

Using resources.Copy with a page resource...

This works:

{{ with .Resources.Get "a.jpg" }}
  {{ with .Resize "200x webp" }}
    {{ with . | resources.Copy "b.jpg" }}
      <img src="{{ .RelPermalink }}" width="{{ .Width }}" height="{{ .Height }}" alt="">
    {{ end }}
  {{ end }}
{{ end }}

This silently fails:

{{ with .Resources.Get "a.jpg" }}
  {{ with . | resources.Copy "b.jpg" }}
    <img src="{{ .RelPermalink }}" width="{{ .Width }}" height="{{ .Height }}" alt="">
  {{ end }}
{{ end }}

Proposal:

1. Improve resources.Copy to handle the case above, OR
2. Create a .Resources.Copy method to handle the case above.

We might want to do both, just to provide parallel methods between global and page resources. There's precedent for this, and I think it makes sense from an API standpoint.

Reference: https://discourse.gohugo.io/t/copying-a-resource-in-page-bundles/42077/2

Release notes for latest version v0.109.0 Section Hugo Module Workspaces: Fourth sentence: See the [hugo.work](https://github.com/gohugoio/hugo/blob/master/hugo.work) file in the Hugo Docs repo ...

The link to the file hugo.work is broken: it points to the hugo repo while it should link to the hugoDocs repo.

Bumps github.com/getkin/kin-openapi from 0.110.0 to 0.112.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.