Consider _build vs build

[cmahnke]

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

$ hugo version
hugo v0.123.0-DEV-4174a7866b75c6ae10827cc77dbae0676af8e5eb+extended darwin/arm64 BuildDate=2024-02-01T18:42:55Z

Does this issue reproduce with the latest release?

Yes

Description

The site is building with Hugo 0.122.0, using the latest dev version it fails with this rather cryptic message:

ERROR Failed to create content converter: no content renderer found for markup ""

@bep: Cann you please add a hint, like template file and line to be able to narrow it down?

[jmooring]

Are you passing "markup" as a key in the options map for .Page.RenderString? e.g.,

{{ $opts := dict "markup" "pandoc" }}
{{ $s | .RenderString $opts }} 

Or do you have a markup key in front matter, even an empty one?

[cmahnke]

No, neither of both. And just passing a empty string as markup in the font matter doesn't seem to trigger this.

But using disableKinds let me narrow it down to some template that is only called for term's - I'll check that.

[bep]

Cann you please add a hint, like template file and line to be able to narrow it down?

I added some page info ... But I fail to understand why the above happens.

[cmahnke]

@bep: Thanks, that was very helpful.
@jmooring: You were close I've got a front matter field build (since it's a site about architecture and uses the field to indicate when a building was topped out). Commenting this out fixes this message. But I can change that...

Thanks both!

[bep]

build (since it's a site about architecture and uses the field to indicate when a building was topped out). Commenting this out fixes this message. But I can change that...

Hmm... I'm not sure I see the connection, but yea, I boldly renamed the _build to build not thinking that it would have any side-effects...

[cmahnke]

Well, I'm just dumping metadata on a object described by a tag page in the frontmatter.
Just to avoid similar issues: This site also uses a type front matter field for tag pages to distinguish between buildings and architects.

BTW: I really like the error messages with a reference to the causing content file, this also has the benefit that they aren't eaten up.

[bep]

@cmahnke OK. I will see if I can make that change less breaking. Note that we have created a separation between "Hugo page config" and "user defined params", so the recommended setup in 0.123.0 would be:

---
title: My page
params:
   myuserparam: foo
   build: some build setup that's not related to Hugo's build/_build
---

[cmahnke]

@bep Yes, I will do that. I guess the usual deprecation rules will apply for custom front matter fields as well.

Thanks!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.