davidsneighbour / hugo-modules Goto Github PK

Some HTML validators complain about <meta http-equiv="x-dns-prefetch-control" content="on/off"> which is not false per se, but better located in the headers of a page than on the page itself. Moving it out will remove those false errors and keep the feature alive. It's also a "forbidden header", meaning it must not be changed during it's lifetime. Moving it out of the scope of any JS will help with that.

Move the evaluation of the parameters into the shortcode or template, then run, based on global config or local type parameter a layout file that receives a specified object (dict) to create a gallery based on the "types" requirement. currently we have bootstrap 4 and 5 implemented with not much config parameters for prev/next nav and such things.

• add individual options parameter
• add default/global gallery type
• add more gallery types via easy plugin (maybe modules but vendored into this module?)

This modules figure shortcode overrides the GoHugo internal shortcode figure.

• add all "official" parameters working to the shortcode
• add a notice that the hugo-pictures figure shortcode can do more with link to the docs
• add hugo-pictures module to hugo-internals

See https://www.netlifycms.org/docs/add-to-your-site/#installing-with-npm

• create a webpack configuration
• re-create JS on publishing

Currently the ahrefs check complains about the feed links having language attributes that all point to the same language. Find out how to properly mark up these links without them being marked as translations.

Also: shouldn't they be listed only on the home page?

Entries currently come up without article images. Add an image tag to the templates.

Having an HTML string in a variable will lead to it being parsed into the debugging table instead of displayed as HTML string.

Sample:

{{ partial "debugprint" .NextPage }}

will render the link to the next page instead of displaying the HTML but should display the type and the string itself.

It would be nice to have a hook return values (or a value). Depending on the hookname (ret-hookname?) the hook could execute the linked layout and return a value or multiple values.

{{ $returnedvalue := partial "func/hooks" "hookname" }}

One main issue is, how to tell func/hooks that a return value is expected and if it's safe enough to just pipe through what the template returns.

Adding [[redirect]] sections to the data configuration is not working. The redirects don't work on Netlify. Need to investigate if they are in _redirects or not.

dnb-org/dnb-hugo-netlification was moved to davidsneighbour/hugo-netlification. This change will introduce some issues for projects using this module. The proper path (wooden mallet method) to update the project is as follows:

• Delete the temporary cache of Hugo. On Ubuntu/Linux this is done via sudo rm -rf /tmp/hugo_cache/, this path will vary depending on your system. This step might not be required.
• Check modules section of your config and change all occurrences of dnb-org/dnb-hugo-netlification to davidsneighbour/hugo-netlification. Or change all occurrences of dnb-org/dnb- to davidsneighbour/ if you use multiple modules by ex-dnb-org.
• Delete go.sum.
• Delete everything between and including require () in go.mod.
• Run hugo mod get -u ./... to update go.mod and recreate go.sum.

Some options are not required, but available. Try to add them somehow to the system without enforcing them.

see https://developer.mozilla.org/en-US/docs/Web/Manifest/background_color

The idea is to set the resizing strategy via front matter cascade per section. On kollitsch.dev images look skewed now, because the strategy was set to resize, which shamelessly stretches weird image sizes. Better be .Fit by default and .Resize via front matter or something like that. Right now it looks "sucky".

There seem to be issues with .Fit and cutting off things around the image, but it seems to be a better fit for the overall design... or .Resize with only a width?

See title

Is your feature request related to a problem? Please describe.

Hooks map onto files with the same name as the hook (and its cached variant). For instance, taking the head-start hook from the Best Practice list, the hook will load:

• layouts/partials/hooks/head-start.html
• layouts/partials/hooks/head-start-cached.html

But there can only be a single file implementing that hook as a result, which means that the hook implementation is custom to a site or theme and not really pluggable.

Describe the solution you'd like

What if we would change this to work with folders? Taking the same head-start hook, resolving this hook would load all files in this folder(s):

• layouts/partials/hooks/head-start/
• layouts/partials/hooks/head-start-cached/

More than one Hugo module could then contribute snippets to the same hook.

For backwards compatibility, we could still resolve the files (current implementation) as a last resort.

Describe alternatives you've considered

Making a "clone" of your hugo-hooks, but I rather bundle forces instead of creating my own hugo-hooks variant.

Additional context

I use hugo-netlification. If we would implement folders as hooks, the netlification module could be updated to provide the snippets placed in the correct folder(s):

• layouts/partials/hooks/setup/netlification.html
• layouts/partials/hooks/head-start/netlification.html

After adding the hugo-netlification module to my site, only the netlification configuration is required separately. Files are already at the correct place for inclusion.

• user_comment (what is this feed for)
• next_url (pagination?)
• icon 512/512
• favicon 64/64
• authors
  • name
  • "URL"
  • avatar 512x512
• expired (optional, boolean) says whether or not the feed is finished — that is, whether or not it will ever update again. A feed for a temporary event, such as an instance of the Olympics, could expire. If the value is true, then it’s expired. Any other value, or the absence of expired, means the feed may continue to update.

Litetube works only if it's concatenated to a script, not via require or import. Change that.

Make debug-partial notices silenceable via slug, as opposed to setting the level of verbosity for all messages of this level to disappear

This seems to be undocumented and the feature also needs a decision matrix when to use what setting.

If an image in a gallery has a different height then the whole page flickers when a smaller height is displayed. make the gallery div the maximum size of all images displayed.

Add robot tags and configuration. This probably is already somehow configurable via dnb-hugo-robots and/or dnb-hugo-sitemap

This allows users to configure their own content type setup.

• create default data structure
• make structure extensible via data/config
• add config template and testing

WordPress filter feature for GoHugo basically. Hand data to a filter(-hook) partial and if a filter partial exists for that filter term then run the data through it and return whats returned or the data unchanged.

See for instance https://codepen.io/huphtur/pen/mNbGeb - add parameters for the svg tag:

• class
• width
• height
• viewbox

Add a global scratch that collects debugging output and then show where the developer adds an output partial.

This can be done with a debug parameter. Collecting data over the page and then in the footer show everything collected.

We have hooks that execute and print code in our templates. How about having some form of pluggable truth giving variables.

Sample:

in the config:

[truther]
some.parameter.name = false

in the layout:

{{ with (site.Params.some.parameter.name | default true) }}
do something
{{ end }}

Sure, this could be on a per template/theme base, but with a reusable system this could be used to enable/disable date display, comment forms on a global or even local (frontmatter params) level and reuse documentation for these settings.

The executing code could be some form of

{{ if partial "truths.html" (dict 
                 "variable" "some.parameter.name" 
                 "value" "local value" 
                 "default" true) }}
do something
{{ end }}

and the partial could take care of sanitisation, comments in the CLI output, collection of available settings, etc.

As described in Advanced Usage a custom theme can be added. Let's implement it here too.

The setup would be as follows:

config

[outputs]
home = ["GISCUS_THEME"]
[params.dnb.giscus]
theme = "dark"
[params.dnb.giscus.theme]
stylesheet = "scss/giscus/theme.scss"
colorPrettylightsSyntaxComment = "#768390"
colorPrettylightsSyntaxConstant = "#6cb6ff"
...

stylesheet is a path to a stylesheet (looks by default for assets/scss/giscus/theme.scss). This stylesheet will import the original theme selected under giscus (loading via getRemote), then subsequent properties under theme are added as overrides and exports the finished stylesheet.

The camelcased syntax of the theme variables are corresponding to the CSS variables in the sample theme.

The pain point here is how to map this without having to add all items to the template. I think there should be a way to transform camelcase to title-case in Hugo.

Currently I think it's a sequence like this:

• Do a replaceRE over the key (see this regexp test)
• lower case it
• trim extra dashes - no idea why the last item in the sample adds a dash in the end

If GISCUS_THEME is set in the outputs, then a custom stylesheet will be linked, so a custom theme without any settings in the theme config section still can add custom styles via theme.scss.

Currently the canonical link is set on EVERY page, which is not required. It makes sense to add canonical only to pages that have multiple URLs (including forwards) that they can be reached at.

With the current (new, but wrong) way of adding the label and description of debugging types to the configuration file we can't translate it easily, so changing it around to the following method:

• adding translation in i18n/en.toml for the defaults
• label-$slug and description-$slug connects to the type configurations slug parameter

This will lead to three locations that new formatters need to be added to, config, i18n and formatter layouts. I wonder if it's possible to encapsule all parts in a single config file per formatter?

Add a scratch that collects hooks to be printed with dnb-org/debug so we can see what hooks a theme implements.

• search field/filter
• own design in a class

Gitlab pages uses the same format for HEADERS and REDIRECTS files (maybe a different name). Cloudflare has a similar feature. Write up docs how to use netlification for these services.

The default formatter (catches types the component does not know) throws a warning at the moment that it does not know type x. This should be extended into a nice preconfigured system that enables a quick notification to create a new formatter.

• print out the formatter type/catch signature
• print an understandable message to go to the issue form for new formatters and add this
• create the form (with Github Issue Formsetup) with enough clarity to have usable user cases.

Each formatter requires

• documentation/sample page in dev-site
• test cases and integration

Current formatters to do:

• bool
• default
• fileinfo
• float
• gitinfo
• int
• map
• menuentry
• number
• orderedtaxonomyentry
• outputformat
• page
• pager
• position
• resource
• shortcode
• siteinfo
• slice
• string
• time
• weightedpage

It appears that the context is delivered sometimes as "context" sub items of . and sometimes as . itself.

• external_url (very optional, string) is the URL of a page elsewhere. This is especially useful for linkblogs. If url links to where you’re talking about a thing, then external_url links to the thing you’re talking about.
• summary (optional, string) is a plain text sentence or two describing the item. This might be presented in a timeline, for instance, where a detail view would display all of content_html or content_text.
• image (optional, string) is the URL of the main image for the item. This image may also appear in the content_html — if so, it’s a hint to the feed reader that this is the main, featured image. Feed readers may use the image as a preview (probably resized as a thumbnail and placed in a timeline).
• banner_image (optional, string) is the URL of an image to use as a banner. Some blogging systems (such as Medium) display a different banner image chosen to go with each post, but that image wouldn’t otherwise appear in the content_html. A feed reader with a detail view may choose to show this banner image at the top of the detail view, possibly with the title overlaid.
• authors
• tags (optional, array of strings) can have any plain text values you want. Tags tend to be just one word, but they may be anything. Note: they are not the equivalent of Twitter hashtags. Some blogging systems and other feed formats call these categories.
• language (optional, string) is the language for this item, using the same format as the top-level language field. The value can be different than the primary language for the feed when a specific item is written in a different language than other items in the feed.
• attachments (optional, array) lists related resources. Podcasts, for instance, would include an attachment that’s an audio or video file. Each attachment has several members:
  • url (required, string) specifies the location of the attachment.
  • mime_type (required, string) specifies the type of the attachment, such as “audio/mpeg.”
  • title (optional, string) is a name for the attachment. Important: if there are multiple attachments, and two or more have the exact same title (when title is present), then they are considered as alternate representations of the same thing. In this way a podcaster, for instance, might provide an audio recording in different formats.
  • size_in_bytes (optional, number) specifies how large the file is.
  • duration_in_seconds (optional, number) specifies how long it takes to listen to or watch, when played at normal speed.

currently everything in site.Params.dnb.pwa is printed into the manifest file. This should be filtered against a list of available options and sanitized.

see also #53

• add hooks to add feed-level fields and item-level fields.
• add filter hooks for content fields

Author tag generation is quite simple done still, but the plan is a bit more explicit, maybe even an external module for authors:

see also https://discourse.gohugo.io/t/site-author-usage/31459/11

The author section of the config is relatively un-regulated, so the following structure is what I will attempt to build in:

• authors-frontmatter with at least name and a fitting site.data.authors.author.name parameter
• authors-frontmatter with at least name in a subarray of one or more authors
• [author] config section with at least one sub-array
• [author] config section with at least name parameter

Add a way to make the <base> tag configurable. Currently it is set to baseURL but that doesn't make much sense in many cases. For instance  won't work with that.

Add a parameter globally and locally to set the baseURL and add a parameter to set a method of what content the base tag should use (local permalink or baseurl).

Keep an eye on this issue and integrate the debugging functions (or, if it turns out as I understand it might, deprecate the debug partial or modify to be a formatted debugging option).

The PostCSS processing is failing currently and disabled. There needs to be a check if postcss is configured (check for file postcss.config.js?) and if so it runs.

• add data configuration for shares ✔️
• add local configuration object to site.Params ✔️

  [params.dnb.social]
  [params.dnb.social.sharebuttons]
  icons = true
  sharetext = true
  networks = ["facebook", "twitter", "linkedin"]
  

• add partials for share buttons ✔️
• sort items by networks configuration ✔️
• enable/disable items by `networks configuration ✔️
• write up documentation ❗

Add a template file to a hook via for instance:

[[dnb.hooks]]
hookname: templatepath

This can be used by plugins to add hooks without them being overridden by local hook files.

Add options object with parameters to:

• hide overview links
• set template for pages output

See https://gohugo.io/functions/hugo/#hugodeps and add a graph for Deps.

{{- partial "func/pictures/getArticleImage.html" $page $cache_id -}}

will return the article image for the given context ($page) as a resource object or an empty dictionary. This function might become resource-intensive without the most common (low number) settings, so use it cautiously and cached. $cache_id should be the page object (untested).

Path of checking

Returns immediately on any successful hit starting with method 1; not checked boxes mark features that are not implemented yet in the current version.

1. check for an image header.* in a leaf bundle
2. Check for frontmatter headerimage
   • If it's a URL, use that, else
   • it looks for the image in assets/, then
   • it looks for the image in static/ and
   • ignores the front matter if it is not found.
3. Check for tags, then keywords frontmatter and
   • check if the tag or keyword coming FIFO has a default image associated with it
4. Check for resources that are images
   • check for an image that has params mainimage set to true (if multiple items exist, then the first one is used)
   • takes the first image of the resources array
   • Note: If there is no resources frontmatter, it will still use the first image resource found in the page leaf. To stop this, add frontmatter use_resource with false.
5. check for configuration parameter [params.dnb.pictures] > default_headerimage and
   • If it's a URL use that
   • looks for the image in assets/
   • looks for the image in static/

Notes:

• if the file found is in resources or assets, then it will be preprocessed and return a responsive picture tag
• if the file found is in static, then it will be inserted as is or per configuration (see below)
• Method 3 (use the default keyword or tag image is a thought and needs some research. For instance, the taxonomy type should be configurable; it doesn't make sense to blindly test for available frontmatter. It won't be implemented soon.

ToDo:

• notes about configuration of responsive sizes
• notes about configuration of default sizes

Input

the page object for which to extract the image.

Output

dictionary with

• image: information about the image (src, name, description, params)
• isResource: boolean denoting if the image can be pushed through resize/optimise procedures or is singular static image
• properties: (properties of a singular static image)
  • width
  • height
  • description

Create a custom .htaccess file from header/redirects configuration.

see https://web.dev/compress-images-avif/

Move all debugging ability by default to the development environment and add a variable that enforces debugging in the production environment (or any other environment existing).

This module should not debug on live sites.

Currently the debugprint partial evaluates the following check to determine if the variable is a slice:

which doesn't cover variables built by slice "bla" (it would print only the "bla" part without indicator, see davidsneighbour/hugo-debug#69.