Hello,
Is there any way to use Site variable
variable in config.toml in front matter
, fo example:
{
"title" : "My page title | {{ .Site.Title }}"
}
Thanks.
Hello,
Is there any way to use Site variable
variable in config.toml in front matter
, fo example:
{
"title" : "My page title | {{ .Site.Title }}"
}
Thanks.
No it isnât. You can, however, use it in your front matter in the archetype file (i.e. the one used in hugo new
).
But for your use case, I recommend adding this in your template.
Thanks for such a quick answer.
Have you any plan to add this ability?
No plans. It does not make much sense.
My site have multiple section/concept. I need to each related sectionâs page (not Hugoâs section) have itâs related extra title, for example:
Can you please show me some light about it, if there is some feature that Hugo can help.
Actually, to me it makes a lot of sense. We use variables, for example, for the company and product names and for the latest-release version, and on occasion we want to use these values also in page titles. One of the main advantages of using variables is that when a value changes you only need to make the update in one place. (There are also other advantages, such as ensuring consistency and avoiding spelling errors.)
Using archetypes or templates wonât help us because thereâs no unified title format, itâs just that some titles might need to reference one or more variables. Also, archetypes are used to generate MD files, but once generated, if a variable value changes, we would need to manually change it in the relevant front-matter page titles.
Of course, often you can do a global search-and-replace, but not only is this less convenient and more error prone than just updating the variable value, sometimes the value is not sufficiently unique to support a simple search and replace.
Itâs also worth noting that while some variable values are not likely to change frequently (although in our case, because the product is relatively new, the terminology is still changing), other variables are by nature expected to change â such as a variable for the latest product version number.
I believe it should be possible to implement a custom solution to this, but currently, in our specific case, itâs not something that we can prioritize.
Templates will help you. Templates fit your need exactly.
Can you clarify how I can use templates to enable the use of variables in page titles? 10x.
Wherever you show a page title, add the variable there. Maybe you want to clarify, in a separate thread, about what you need done, and show how you currently generate your titles in your templates.
I donât have a variable that I want to insert in all titles according to a specific format. I just might want to use some site variables as part of the text of some titles, on a case-by-case basis, which is the reason I think templates canât be the solution because there isnât a general title âtemplateâ.
As a simple example, assume a config.toml file with a product
variable that translates to the product name. I donât want to insert the product name in all page titles, but I do want to use it in some titles. The same goes for the names of specific product components or the company name, or for the latest-release version. Note that not only donât I need to use the variables in all titles (including not in all titles of a specific site section) but when I do want to use it the usage doesnât follow a predefined structure.
You can use the âwithâ function to test if a certain variable exists and if so add the value of it into the template where you want it. https://gohugo.io/functions/with#readout
You could use a collection of tests like this to build a more complex page title out of different variables in front matter.
I understand how to conditionally test for and insert site variables/parameter values in templates. But thereâs no generic templating scenario here: the title of each page is different, and the occasional need to use a variable in the title is not consistent and doesnât follow a predefined templating logic, including which variables to use and where to insert them. Perhaps we could set the title in a custom front-matter variable, use site variables within the value (using a custom syntax), and then write a template to set the page title correctly, using the variables. However, currently this seems like an unjustified overhead. My point was that there are scenarios in which using variables in page titles can be useful, and it would be great if Hugo were to inherently support this ⌠.
It will kill performance and you are the first person to ask for it. So it isnât likely.
This thread is a little out of hand, because we are saying there is a way to do what you want without the feature you are asking for, and you are insisting it isnât possible. What you are asking for isnât so simple we can spin up an example easily, so you are gonna need to do more research and experimenting.
I will quickly describe a way to do it, but you or a dev will need to build it. @zivbk1 already pointed it out, but I want folks finding this conversation to realize it.
@sharonl, let go of a âsite variableâ based solution. Just use page variables, but consistently.
So in your archetype create a parameter called something like titleoverride
. Then give it a value, like featured
. Then, in your template, conditionally load a title line if a post has titleoverride
set to a particular value. Bonus points: make it output some parameter in your config that matches.
This is essentially what you want. It makes a lot of sense for folks maintaining the content, too. And I doubt it will create a lot of overhead.
Thanks @maiki. I actually think I already understood the direction that was being suggested (although it took me time). Your explanation seems to align with what I wrote in my last post:
Perhaps we could set the title in a custom front-matter variable, use site variables within the value (using a custom syntax), and then write a template to set the page title correctly, using the variables. However, currently this seems like an unjustified overhead.
As I wrote, for our current needs itâs probably not worth it; itâs not a major issue for us (which is why I never opened my own issue for this), and while I would have preferred a built-in solution, we can definitely go without it and if the need arises, implement a custom solution. Since bep says supporting this feature will kill performance, I wonât press this further. Hugoâs performance was one of the main reasons I selected it over other solutions .
Solution for variable in front matter text
I do not want to open a new topic so I use this one. Maybe this solution helps other hugo fans.
ISSUE:
On my site I have a lot of metaTitles with YEAR. For example:
The Best LED Light Kits to Buy in 2018
The Best Photo Light Boxes in 2018 to Buy
TOP2018: The Best Drones to Buy for Kids
etcâŚ
In Content: the-best-8-led-light-kits-to-buy.yaml
I need:
---
metaTitle: The 8 Best LED Light Kits to Buy in 2018
(other values like Title, metaDescription, whatever..)
---
Every new year I need to change to current year for all metaTitle
s (from value 2018 to 2019)
How to do that in bulk ?
SOLUTION:
1)
In Content: the-best-8-led-light-kits-to-buy.yaml
I simply change 2018 to unusual word:
---
metaTitle: The 8 Best LED Light Kits to Buy in varYear
(other vaules)
---
and then I set varYear
in all metaTitle I need.
2)
In global congfig.yaml
I set a Site variable
(doc):
params:
currentYear: 2019
3)
In my partial head.html
I set:
<head>
<title>{{ replace .Params.metaTitle "varYear" .Site.Params.currentYear }}</title>
</head>
And voilĂ
⌠all metaTitles are changed.
Provided that all your Best Of titles display the year in the end there is a much simpler way to use the year site parameter, without the cost of using the replace
function.
Eliminate varYear from the frontmatter of all your posts.
In partial head.html
enter the following:
<head>
<title>{{ .Params.metaTitle }} {{ .Site.Params.currentYear }}.
</title>
</head>
Thanks @alexandros for notice.
I have edited my wrong example above:
ISSUE:
On my site I have a lot of metaTitles with YEAR. For example:
The Best LED Light Kits to Buy in 2018
The Best Photo Light Boxes in 2018 to Buy
TOP 2018: The Best Drones to Buy for Kids
etcâŚ
varYear
could be placed anywhere in metaTitle
text (in the beginning, in the middle,at the end,âŚ)