-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Scratch.Add with a mix of types #5361
Comments
Thanks for the report. I see how this was an unintended change, and I will see if I can fix it, but I suspect that this is both very rare and almost always a sign that something else is wrong. From what I read from your template, you start out by creating a
Then you do some looping and continue to add |
We'll see how a fix makes sense. Another idea would be to move to the new variable overwrite in Go templates, but that's a much bigger change. What's your general stance on this. It's a bug, but works as it should be now more than it did before or Hugo should preserve the old way instead of breaking this? |
Sure, it's a bug. Scratch should be able to append strings and pages in the same slice. I will fix it. But I also claim that there is a logical flaw in your template -- the new |
The type handling in these was improved in Hugo 0.49, but this also meant that it was no longer possible to start out with a string slice and later append `Page` etc. to it. This commit makes sure that the old behaviour is now possible again by falling back to a `[]interface{}` as a last resort. Fixes gohugoio#5361
The type handling in these was improved in Hugo 0.49, but this also meant that it was no longer possible to start out with a string slice and later append `Page` etc. to it. This commit makes sure that the old behaviour is now possible again by falling back to a `[]interface{}` as a last resort. Fixes #5361
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. |
With the change in v0.49 to restrict scratch to the string type only it broke quite a bit of existing behavior using scratch as a variable (this was necessary before variable overwrite was a thing and also has other benefits).
One behavior that broke was the possibility to assign hugo.PageOutput to scratch.
One occurrence is this line: https://github.com/okkur/syna/blob/master/layouts/partials/helpers/fragments.html#L85
Error output:
We assing a hugo.PageOutput to scratch instead of a plain string.
Related to #5275
The text was updated successfully, but these errors were encountered: