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
Page Params got lowercased #2590
Comments
https://gohugo.io/templates/variables/ Have you tried changing |
That fixed the issue. However, this is a recently added feature. My site was working fine until my last deployment last month. I hope Hugo maintains backward compatibility and documents breaking changes somewhere. |
What version did you upgrade from and to? Are you compiling off of master? This particular part of the documentation was last updated January 27, 2015 so it's been this way for a long time: https://github.com/spf13/hugo/blame/master/docs/content/templates/variables.md#L73 |
@moonytheloony I've left you a github issue on one of your projects Blog-Web with a recommendation of how to install hugo for usage in travisci. Using Hope that helps! |
I will reopen. This lower-casing of |
Maps in Viper, Hugo's config backing store, is now properly lower-cased not just on top level, the current situation. While this is mostly a good thing, as you don't need to know the original casing to look up a value, it will be breaking for people doing direct lookups in the ´Site.Params` map. We will try to find a solution to this "breakage", but the recommended method to get params values is via the `.Param` methods. This method is now implemented on `Node`, `Page` and `Site` and is case-insensitive: * Use `.Param "someKey" ` if you want page param with fall back to site param if not found on page. * Use `.Site.Param "someKey"` to get a site param See #2590
Also ran into this unexpectedly as my Travis deploy of compiled assets to github pages were missing all param attributes. Glad for this issue to know it wasn't a misconfiguration ^_^ |
What would you advice for themes maintainers ? We have the problem with the cocoa theme where we can't support both Hugo 0.17 and Hugo 0.18 because one looks for case sensitive variable in Params and the latter is looking for the lowercased ones. Maybe changing all the sample |
There are currently several Params and case related issues floating around in Hugo. This is very confusing for users and one of the most common support questions on the forum. And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work: `Params.myCamelCasedParam` Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys. But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`. This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys. This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling". Tests are added for all the template engines: Go templates, Ace and Amber. Fixes gohugoio#2615 Fixes gohugoio#1129 Fixes gohugoio#2590
There are currently several Params and case related issues floating around in Hugo. This is very confusing for users and one of the most common support questions on the forum. And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work: `Params.myCamelCasedParam` Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys. But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`. This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys. This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling". Tests are added for all the template engines: Go templates, Ace and Amber. Fixes #2615 Fixes #1129 Fixes #2590
There are currently several Params and case related issues floating around in Hugo. This is very confusing for users and one of the most common support questions on the forum. And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work: `Params.myCamelCasedParam` Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys. But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`. This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys. This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling". Tests are added for all the template engines: Go templates, Ace and Amber. Fixes gohugoio#2615 Fixes gohugoio#1129 Fixes gohugoio#2590
There are currently several Params and case related issues floating around in Hugo. This is very confusing for users and one of the most common support questions on the forum. And while there have been done some great leg work in Viper etc., this is of limited value since this and similar doesn't work: `Params.myCamelCasedParam` Hugo has control over all the template method invocations, and can take care of all the lower-casing of the map lookup keys. But that doesn't help with direct template lookups of type `Site.Params.TWITTER_CONFIG.USER_ID`. This commit solves that by doing some carefully crafted modifications of the templates' AST -- lowercasing the params keys. This is low-level work, but it's not like the template API wil change -- and this is important enough to defend such "bit fiddling". Tests are added for all the template engines: Go templates, Ace and Amber. Fixes #2615 Fixes #1129 Fixes #2590
Maps in Viper, Hugo's config backing store, is now properly lower-cased not just on top level, the current situation. While this is mostly a good thing, as you don't need to know the original casing to look up a value, it will be breaking for people doing direct lookups in the ´Site.Params` map. We will try to find a solution to this "breakage", but the recommended method to get params values is via the `.Param` methods. This method is now implemented on `Node`, `Page` and `Site` and is case-insensitive: * Use `.Param "someKey" ` if you want page param with fall back to site param if not found on page. * Use `.Site.Param "someKey"` to get a site param See gohugoio#2590
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. |
I used to have images displayed through a dynamic url e.g.
<img src="{{ .Site.Params.resourcesBaseUrl }}/profilePicture.jpg" class="img-responsive" alt="Profile Picture"/>
This used to work fine until recently. Now Hugo is not able to concatenate the two strings and just outputs image source as /profilePicture.jpg which does not render any images.
I am using the latest build to deploy my website.
The text was updated successfully, but these errors were encountered: