Non-Standard Template Extensions | Template Extensions other than .html | Functionality akin to resources.ExecuteAsTemplate and resources.FromString in Hugo

Feature requests
1

Can template files have non-standard extensions like .webmanifest, .json, etc.?

2

Not right now, except for feeds.

3

Is it possible to enable this general files? There is hardly any work to enable this. For:

  • JSON
  • webmanifest
  • manifest
  • ini
  • amp
  • XML
  • txt
  • toml
  • yaml
  • etc.

Also instead of hardcoded logic in applying index.html, list.html, section.html etc. can this be made an overridable option in the config as to which template applies to what processing pattern. This mechanism can perhaps then used to write out generated files which are not HTML or standard types. The files processed can be configured in the config. This will make Zola a lot more powerful and versatile.

4

you could rename zola’s output by script if you want, on any OS it is possible with regular expression applied to a folder. But I can’t imagine how zola can generate it all, especially strong validated formats. It would be extremely slow.

can this be made an overridable option in the config as to which template applies to what processing pattern

Sorry if I got you wrong, you feel free to apply specific template to specific content file Page | Zola

5

Hugo has the ability to create a resource from a template: https://gohugo.io/hugo-pipes/resource-from-template/, resources.ExecuteAsTemplate. This can be used to generate lined content.

No need of validating the output. Just apply a template and save the output so it can be linked.

6

Another thing to consider is the following flow in sass processing being also the use a template to generate the sass files and then process as save as a named css file and get the urls of the resulting css files and finally minify the whole build.

So sass processing can be:

  • automatically triggered when you have a link like ./public/style.css, ./public/site.webmanifest, ./public/me.jpg, etc. or
  • manually triggered resources.ToCSS ... or resources.ExecuteAsTemplate ... | resources.ToCSS

Also, make the resource processors configurable. sass to css can be a default processor. Also being able to hook say image compressor when an image is included (./public/me.png) it gets compresses using the image processor. This will be registered for input type & location and target type & output location, of which the type can be the same in the case of images.

Also, a way to register Rust function or template or macro or command-line program or script to which page, template and resource processing can be delegated. This way the users can add other content types like AsciiDoctor as a plugin. Also, add steps like PostCSS. This brings up Zola execution life cycle which can have serial and parallel elements.

7

Anyway for the time being is there a quick workaround or solution to writing out:

  • humans.txt
  • site.webmanifest
  • browserconfig.xml
    files using a template? Currently, this uses Hugo but I want to port it to Zola.
8

No workaround I’m aware of right now

9

Wondering if this can added in the near future?

10

Not planned right now no.

11

Apologies for being persistent.

I believe this does not really involve much work to implement but gives a lot of benefit in writing out resource files, manifest files and other site related metafiles.

In the frontmatter can have the file name to save to like <out_file_name>.<ext> and the template name to use like <the_template_file_name>.<ext>. E.g. <dummy_file_name>.md can have:

+++
target_file = "<out_file_name>.<ext>"
template_file = "<the_template_file_name>.<ext>"
+++

or

+++
target_file = "<out_file_name>.<ext>"
template_file = this_file_content
+++

The above template may return the target_file if needed for hashing or any other output.

In this case process, the frontmatter of <dummy_file_name>.md as with any other file and then pass it to be processed as by <the_template_file_name>.<ext> as any other template and finally write out the output to <out_file_name>.<ext>.

Alternatively, for site level files this can be specified in the configuration.

For resource processing, it would be nice to have something like execute_as_template(<output_file_or_string_as_a_file>, <template_file_or_string_as_a_file>, <optional_file_or_string_as_a_file_with_frontmatter_and_content>) which would return the link to the template output. This can be used as a link and also can be used for fingerprinting. This is not necessary but nice to have as long as there is a way to fingerprint the output of a template using the above methods, i.e., templates calling get_file_hash with the output file needs to be processed after the files are written. Most convenient would be to have both as then if are hashing is needed one can call execute_as_template.

The page variables ideally should be able to access the following within the template <output>, <optional_with_frontmatter_and_content>, <template> in all the cases. The <output> could be pipped into sass processing.