Closed uzantome closed 3 years ago
Looks like Hugo changed the lookup order and fallbacks for the .Param
variable. Some research needs to be done to see exactly what the "new" order is now, and why .Site.Params.*
is not being checked as fallback to .Params.*
like it used to. If you have some time this would be a good place to start. I prob can't look at it for another couple weeks.
As far as an Axiom fix/PR goes, manually checking all the diff places settings can be stored would be an approach we would not want to take. So first we need to get to the bottom of the new look up orders and fallbacks for params
in general and find out what's going on there. There's got to be a single check that cycles through the hierarchy and fallbacks.
Here's the expected behavior and how Axiom worked previously:
I just bumped into this issue as well. I'm new to Hugo so I can't speak for past behavior, but according to the docs the Param method mentions this fallback behavior, but Page-level Params do not.
For example, a quick test shows that changing the following from layouts/_default/single.html
:
<div class="ax-l-i{{ printf " %s" (.Params.maxWidthContent | default "max-w-680") }}">
...
</div>
To this using the Param
method instead:
<div class="ax-l-i{{ printf " %s" (.Param "maxWidthContent" | default "max-w-680") }}">
...
</div>
Produces the expected behavior as described above. Not sure what the best practices are for doing this with Hugo, but happy to create a PR if that looks accurate to others.
Submitted change as #26 for review.
Ping for thoughts here. @Radler77 does this fix solve the issue for you as well?
Hi guys, thank you for all the contribs, much appreciated. I'll try and get into them this weekend.
Ping for thoughts here. @Radler77 does this fix solve the issue for you as well?
yes, thank you
when adding the following code to the config.toml the width of pages doesn't change (expected behavior described here: https://www.axiomtheme.com/docs/configuration/ )
maybe it's because pages use Page Variables instead of Site Variables (using the Code as Front Matter works as expected) therefore a potential fix could be checking Site Variables then Page Variables and then revert to the default value (currently only Page Variables are checked before using default values)