Builds fail when post draft=true, fine when draft=false

support
1

I’ve been struggling with this for some months now. When I’m generating content for blog posts I’d like to set draft: true in the frontmatter so I can preview the content locally or on netlify using --buildDrafts.

However, this results in a build error for any post content were the draft is set to true:

ERROR render of "page" failed: execute of template failed: template: _default/single.html:9:11: executing "main" at <partial "components/hero-background.html" (dict "title" .Title "description" .Params.description "image" .Params.hero.image "background" .Params.hero.background "blend_mode" .Params.hero.blend_mode "theme" .Params.hero.theme "crop" .Params.hero.crop "anchor" .Params.hero.anchor "quality" .Params.hero.quality "interest_area" .Params.hero.interest_area "view" .Params.hero.view "text_opacity" .Params.hero.text_opacity "text_vertical_position" .Params.hero.text_vertical_position "text_color" .Params.hero.text_color "text_shadow" .Params.hero.text_shadow "height" .Params.hero.height "height_mobile" .Params.hero.height_mobile)>: error calling partial: "/opt/build/repo/themes/hugo-advance/layouts/partials/components/hero-background.html:14:44": execute of template failed: template: partials/components/hero-background.html:14:44: executing "partials/components/hero-background.html" at <$background_image.Fill>: nil pointer evaluating resource.Resource.Fill

This error does not occur if draft: false on the same content and the --buildDrafts flag excluded. It renders correctly with the hero image etc (where the above message suggest there may be an issue).

My workaround has been to set the publish date to some time in the future and use --buildFuture instead. But that’s caused the inevitable issue I had today - some content was inadvertently published… The date wasn’t far enough in the future!

Any ideas what might cause this or where to look? I guess it’s a theme issue but I can’t understand how draft: false works fine and draft: true doesn’t when --buildDrafts is used.

Thanks for any tips.

2

It looks the issue of hero.image (don’t exist) on draft posts, and the theme doesn’t check whether the hero.image exsits.

3

Thanks - yeah that’s what I thought, but the image is there and shows/renders as expected when draft=false and --buildDraft flag isn’t used.

So how can doing the alternative (draft=true & --buildDraft) break things? I don’t understand what, in the template, would be processed differently with those two options flipped.

4

Further thinking out loud - I deleted all other content files that had draft: true so that just one post existed. I also built using the debug loglevel flag, trying to see if the location of the error changed.
This was trying to rule out another draft bit of content existing with an image that didn’t exist.
No change. So it builds post by post, reaches the one with draft:true and fails. Setting to draft: false builds fine.

5

neither of these suggestions directly solve your problem, but might be a workaround:

  1. set your date in the future and draft: false, then use --buildFuture instead for the preview.

  2. use a CI that allows for the non-master branches to be previewed, for example the Cloudflare Pages integration with Hugo gives you a unique pages.dev link for every commit.

6

This appears to be a commercial ($) theme:
https://www.zerostatic.io/docs/hugo-advance

Have you reached out to the vendor?

7

Yeah - that’s what I’ve been doing which led to the problem (inadvertently posting something via an automated, regular CI build once the date changed to the preset future published date), and hence trying to get a proper solution where the draft status would have prevented that.

I’ve a non-master branch for all preview/dev builds, and do a PR to master once all looking good and scheduled appropriately. The non-master builds are the ones where I want --buildFuture and --buildDrafts to work as intended.

8

Yeah, I will do - if it is indeed a theme issue. Although the theme has been heavily customized and extended - included the partial thrown up in the error…

I still don’t understand why it’s only the --buildDrafts flag that causes the issue. I don’t see how something in a partial within a theme would build fine non-draft, but not when marked draft and using --buildDrafts. Nothing changes bar one line of frontmatter and the hugo command option.

But typing this made me want to go and check if there’s a “if not production” region of that partial. Is there a “if draft” construct?

9

I’m not a big fan of guessing. To avoid guessing, I need access to the project repository. But if the terms of your commerical theme purchase preclude you from sharing souce, I’m not sue where that leaves us.

Which is why I encouraged you to contact the vendor.

1 Like
10

Thanks Joe - I hear you.

In parallel I’ll try and make a MWE using the new ‘basic site’ thing I read about, and grafting on the relevant templates / partials. Doing that may expose somewhere I’ve introduced an error.

11

In case it’s something obvious, below is the section from the partial where the error occurs.

{{ $crop := .crop | default "2560x1440" }}
{{ $anchor := .anchor | default "Smart" }}
{{ $quality := .quality | default "75" }}
{{ $quality = printf "q%s" $quality }}
{{ $cropAndAnchor := printf "%s %s webp %s" $crop $anchor $quality }}

{{ $background_image := "" }}
{{ if .background }}
    {{ $background_image = resources.Get .background }}
    {{ $background_image = $background_image.Fill $cropAndAnchor }}
    {{ $background_image = $background_image.RelPermalink }}
{{ end }}

The line {{ $background_image = $background_image.Fill $cropAndAnchor }} is indicated in the error. And from reading around the nil pointer could suggest the line above isn’t returning the image location when in draft?

12

The code should check if Resources.Get returns nil and errorf more information in that case. I suppose that the image file does not exist (typo?).

1 Like
13

Following up after some time to close this off - the issue turned out to be some legacy content (posts or pages marked as draft) amongst the numerous ‘new’ content files that had frontmatter values which broke the build when building the draft content.

Deleting the legacy content resolved the issue. Perhaps a lesson in keeping your repo clean and tidy…

14

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.