On Sun Sep 25, 2022 at 12:56 PM EDT, Edd Salkield wrote:
> Yep, I'm just wondering why trusting the input has to be explicitly
> specified, rather than being default behaviour. Since all content is
> static, there isn't a way for untrusted input to enter the templates
> anyway, so escaping by default doesn't seem to serve a purpose.
>
> I don't see why, for example, anyone would want template content to be
> anything but unescaped.

This is due to the way that Go HTML templates work: they automatically
escape URLs and attributes unless the input is specified as trusted. I
think this is a good default because it prevents users from accidentally
generating invalid HTML.

On Sun Sep 25, 2022 at 10:45 AM EDT, Edd Salkield wrote:
> Since kiln is a static site generator, can we do away with template
> functions safeCSS, safeHTML etc?  There's no way I can see that
> user input gets supplied from an untrusted source.

These functions are not meant for untrusted user input, rather the
opposite: they indicate that the input is trusted and should not be
escaped. The default atom.xml template makes use of some of these
functions.

On Sun Sep 25, 2022 at 10:38 AM EDT, Edd Salkield wrote:
> Under most configurations, a blank index.ext or page.ext template with a base template
> will cause an error because most base templates have something like:
>
> `{{ block "body" $ }}{{ end }}`
>
> Instead, the user would either have to provide index.ext and page.ext
> files like:
>
> `{{ define "body" }}{{ end }}`
>
> or symlink the base template in.  It doesn't seem too intuitive, but it
> would make kiln easier to understand and I think that counts for a lot.

Thanks!

To git@git.sr.ht:~adnano/kiln
   ff4d614..4b39c0b  master -> master

This release brings a few bug fixes and improvements.

Adnan Maolood (8):
      templates/about: Update link to Go documentation guidelines
      internal/server: Don't load packages in the background
      internal/server: Don't log context.Canceled errors
      internal/server: Decrease module count metric timeout
      templates/tools: Update link to Go documentation guidelines
      internal/server: Change sample badge URL
      internal/server: Limit concurrent module fetches
      internal/server: Clarify import graph error message

On Fri Sep 23, 2022 at 2:03 PM EDT, Edd Salkield wrote:
> ---
>  docs/kiln.1.scd | 21 ++++++++++++++++-----
>  templates.go    | 11 ++++++++++-
>  2 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/docs/kiln.1.scd b/docs/kiln.1.scd
> index 4069d89..1c79b8d 100644
> --- a/docs/kiln.1.scd
> +++ b/docs/kiln.1.scd
> @@ -153,7 +153,12 @@ order.
>  # TEMPLATES DIRECTORY
>  
>  The templates directory contains templates for use when building the site.

On Fri Sep 23, 2022 at 2:04 PM EDT, Edd Salkield wrote:
> ---
>  templates.go | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/templates.go b/templates.go
> index 0fc7d94..6004758 100644
> --- a/templates.go
> +++ b/templates.go
> @@ -108,7 +108,7 @@ func (t *Templates) Load(dir string, exts []string) error {
>  		if err != nil {
>  			return err
>  		}
> -		if d.Type().IsRegular() {

Thanks!

To git@git.sr.ht:~adnano/kiln
   90aa756..05fc173  master -> master

On Fri Sep 23, 2022 at 12:57 PM EDT, Edd Salkield wrote:
> I've had a few further ideas whilst thinking about templates from the
> other thread that I'd like to hear some thoughts on.
>
> Does it make sense for pages in the root of content to be templated from
> the root of the templates directory?

I believe this is already the case.

> Would following symlinks when resolving template files provide more
> flexibility for people seeking to share one template between multiple
> directories?

This should already be the case as well, no? kiln doesn't distinguish

On Fri Sep 23, 2022 at 10:29 AM EDT, Edd Salkield wrote:
> Using templates/_default/base.ext as a base in case the
> directory-specific one doesn't exist would be useful for site-wide
> default bases.  The current behaviour could be restored by users by
> putting blank base.ext files in the template directores that they don't
> want to inherit from the default base.
>
> The partial templates would need to be excluded from this new behaviour.
>
> Would you consider a patch for this?

I would consider a patch for this. The patch should be accompanied with
an update to the documentation to clarify how the base template is
selected. Since this is a breaking change, it might be best to include