Appending a page to a page collection: append or union?

I have periodically wondered if this construct (line 3) might be a bit sketchy:

{{ $currentPage := . }}
{{ $posts := where site.RegularPages "Section" "posts" }}
{{ $pages := $posts | append $currentPage }}

And today I experienced intermittent, unexpected results where the appended page seemed to get stuck, using the same value from page to page. It’s difficult to describe, but easily repeatable.

I saw this when running hugo server and when building the site with hugo.

So I did this instead.

{{ $pages := $posts | append (slice $curentPage) }}

No change; still intermittent problems. But this seems to work fine:

{{ $pages := $posts | union (slice $curentPage) }}

When appending a page to a page collection, should I always use the union function instead of the append function?

The results of my tests seem indicate the later.



git clone --single-branch -b hugo-forum-topic-41532 hugo-forum-topic-41532
cd hugo-forum-topic-41532
hugo server

I’m trying to understand your question. What does “get stuck” mean?

I’m viewing the page /section-1/section-1-2/section-1-2-1/page-13/ (then click other pages) as example.

Here is what I’m seeing:

{{ $pages := $posts | append $currentPage }} works as expected: $currentPage is “always” appended to the slice (4 links).

{{ $pages := $posts | append (slice $curentPage) }} does the same thing.

{{ $pages := $posts | union (slice $curentPage) }} joins two slices without duplicated items. The expression is same as union (slice $currentPage) $posts. The link of the current page is on top of the page list.

It seems kind of normal. What do you want to achieve?

I want to learn from this example too. Thank you.


I’m still guessing but I push a PR anyway.

Both “append” and “union” approaches with slice creates multiple slices. And I personally think that the expression is quite complicating. I try to make it simple using Hugo’s in function:

{{- if not (in $regularPagesInFirstSubsection $currentPage) }}
  <h3 style="background: yellow;"><a href="{{ .RelPermalink }}">{{ .Title }}</a> (weight = {{ .Weight }})</h3>
{{- end }}

Then you can {{- range $regularPagesInFirstSubsection }} directly.

It seems to be easier to read.

Hope it helps :slight_smile:

If you want to append, use append. union has a different meaning (and is more compute intensive).

When you run the example site, the home page asks you to run the given command repeatedly in your terminal, so that you can easily see the inconsistent results from one build to the next.

Did you do that?

Yes. I tried repeating the command a few times. Those two approaches have different results. But the results for each approaches are consistent. (Hugo v0.105.0)

Let me rephrase the question. When you ran the command repeatedly with the unmodified repository, did you see different results from one run to the next?

No. The results are the same:

      <h3><a href="/section-1/section-1-1/page-04/">Page 04</a> (weight = 4)</h3>
      <h3><a href="/section-1/section-1-1/page-05/">Page 05</a> (weight = 5)</h3>
      <h3><a href="/section-1/section-1-1/page-06/">Page 06</a> (weight = 6)</h3>
      <h3 style="background: yellow;"><a href="/section-1/section-1-2/section-1-2-1/page-13/">Page 13</a> (weight = 13)</h3>

When I run it 20 times, I get the wrong results at least 10 times. Page 13 is replaced by something else.

It is quite strange. I’ve tried > 30 times but the results are consistent. I’m using a basic instance of Lightsail VPS to test your repo. The server is slow but I think it doesn’t matter. Build time is around total in 50 ms.

I might if you’re limited to one CPU.

I can reproduce that issue on my MacBook. Hmm… that’s really weird, as the implementation of append should be straight forward (no magic caching going on). Almost like I suspect there is a issue in the templating (Go stdlib) code.

Btw, you can append single objects to a slice, no need to make a slice.

1 Like

Yeah, tried it both ways to see if it made a difference. Thank you for testing this. I though I was losing it…

Sorry I didn’t have a MacBook yesterday. Now I try again and reproduce the problem you’d got.

Yes. The 4th line of the grep output are inconsistent starting from 2nd run of the command.

I have updated the issue above. So, I would call it a Hugo bug, but it should be not be a common thing to experience. I need to think a little about how to fix it, because the current behaviour has its upsides for the majority of the append use cases (it does not allocate memory if the slice has the needed capacity, which is especially great when appending in a loop).

1 Like

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