.Store / .Scratch lost in calling tree from bottom to top

[gj52]

hugo version 0.98 and before

Does this issue reproduce with the latest release?

YES

I have a partial templates "tree" a calls b calls c (no partialCached!)
Setting .Scratch or .Store in c is not given back to a, where Scratch or .Store is given back empty.

If .Store and .Scratch belongs to a page, the values should return to the upper caller template.
Is the dot parameter for the called partial read only???

[bep]

Is the dot parameter for the called partial read only???

No.

I'm not totally sure what you're asking for, but I suspect it's related to #9339 ...?

[gj52]

not related, I tryed to do something like this

a.html
{{ partial "b.html" .}}
{{ $sp :=  .Scratch.Get "sprites" }}

b.html
{{ partial "c.html" .}}

c.html
{{  $.Scratch.SetInMap "home" "svg/home.svh" }}

.Scratch.Get returns nil.
Tryed the same with .Store

[bep]

a.html
{{ partial "b.html" .}}
{{ $sp :=  .Scratch.Get "sprites" }}

b.html
{{ partial "c.html" .}}

c.html
{{  $.Scratch.SetInMap "home" "svg/home.svh" }}

You're never setting sprites in the above, so no surprise it returns nil.

Note, I'm 100% sure that this works as designed. I would be happy to help you troubleshoot, but let's take that on https://discourse.gohugo.io/

[gj52]

MUST come back, there is an error with list / pagination, my workaround 👍🏻

part of list.html

	<article>
		<div class=liste>
			{{ $data := newScratch }}
			{{ range $paginator.Pages -}}

			{{ partial "summary.html" . }} <!-- sets .Store data -->

                       <!-- move the data from .Store to .Scratch -->
			{{ $sp := .Store.Get "sprites" }}
			{{ range $key, $val := $sp }}
				{{ $data.SetInMap "sprites" $key  $val }}
			{{end}}

			{{- end }}
		</div>

                <!-- move the date from .Scratch to .Store -->
		{{ range $key, $val := ($data.Get "sprites") }}
			{{ $.Store.SetInMap "sprites" $key  $val }}
		{{end}}

		{{ partial "pagination.html" . }}
	</article>

[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.