I’m running a website where we use affiliate partners to monetise. I would like to store reusable (description, logo++) information regarding these affiliates in data files (data/affiliates/“affiliateName”.yaml). Then when I want to list this affiliate partner as a store in my posts I would like to echo that information by calling the parameter affiliateName to get the reusable information, in addition I’d like to be able to supply a custom link to the affiliate partner to the specific product (affiliateLink).
I’m having troubles getting this up and running. This is what I have so far:
“affiliateName”.yaml-template:
It is. However, range redefines the current . (context). Meaning that the dot that used to be your page (usually) now is the item you’re ranging over. See Introduction to hugo templating about iterations.
So in this case, inside your range, . designates a child of .Params.affiliates, and therefore the affiliateName key is accessed with .affiliateName. That’s also why you need to use $.Site.Data, because .Site.Datadoes not exist anymore in your range context.
You could also use a variable name as the affiliate, instead of the dot context:
Okay, I’m getting this error now though: Building sites … ERROR 2018/04/22 17:23:55 Error while rendering "page" in "concursos/": template: /Users/olafg/Development/proximo-concurso/layouts/single.html:57:16: executing "main" at <.Params.affiliates>: range can't iterate over estrategia
Related could work, but they should be specified for each post, not automatic and the link is usually unique per post (a so-called deep link).
I was just thinking whether headless bundles might be a better idea rather than data files. I still wasn’t able to solve with data files and the suggestions posted above, though.
It does require gulp/node.js/npm to run because of the asset compilation. I’m looking to move most of it over to the Hugo native asset processing though.
The case is explained above, but I’m thinking that headless pages might be a better option than Data files for what I am trying to achieve.
I would indeed use headless pages and then retrieve them using a Front Matter param and .GetPage. This way you can benefit from Page Resources, image processing etc…