Using site variables in front matter



Is there any way to use Site variable variable in config.toml in front matter, fo example:

    "title" : "My page title | {{ .Site.Title }}"



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:

  • Mobile
    • Page A -> title should be Page A | Mobile
    • Page B -> title should be Page B | Mobile
  • Web
    • Page A -> title should be Page A | Web
    • Page B -> title should be Page B | Web

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.

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 :slight_smile: .