I’m a huge fan of Hugo and have had no problems with it so far, but I’m slightly puzzled by what I thought would be a common requirement.
I’m building a CMS that ‘deploys’ a Hugo site, and the CMS allows for the addition of directories, markdown files, images etc. Now, my plan was to add a .info.yml file to a directory when it is created, and inside it store some YAML with its display_name and a description of the contents that would be displayed at the top of the file listing.
I have this working (with JSON instead of YAML because getYAML isn’t a thing yet!) but in my template I can’t work out how to access the contentDir value from my config file in the template. Here’s a simplified section of my template, as you can see I’m hardcoding ../repo/.
So, is this possible? Can I replace the hardcoding with something a bit more flexible? Or, have I taken the wrong route entirely and there’s a better way of doing this kind of thing in an automated fashion? Any pointers are welcome.
I don’t think the contentDir is available from templates.
getJSON reads local files relative to the workingDir, so I’m not sure I understand your example. Using the full path to the content dir would not work.
I don’t quite understand what you are trying to do in the example, but it looks like something that could be accomplished with either a combination of _index.md files and front matter or by using data files under the /data directory. Do neither of those approaches work?
@bep yes, you’re right - thank you. The “flexibility” I was looking for is already there, I was trying to force it into the template rather than use it as intended and structure my application properly.
Thinking about it, a single symlink might make everything “just work”, I’ll try later.
@Shadow53 this was the approach I originally took, but as far as I know that approach would require the modification of the theme in addition to the content (which my CMS is managing and storing in a separate Git repository). I believe that I’d have to add a _index.md file for each corresponding directory in my content for that to work?
I hadn’t considered storing the files in /data, but that might be the most sensible option. I’ll definitely investigate that further.
Originally, what I wanted was something like “frontmatter for directories” that could be stored with the content and kept under version control, something like this:
@Shadow53 this was the approach I originally took, but as far as I know that approach would require the modification of the theme in addition to the content (which my CMS is managing and storing in a separate Git repository). I believe that I’d have to add a _index.md file for each corresponding directory in my content for that to work?
The theme wouldn’t necessarily need to be modified if it’s all just front matter. Your example .info.json could be represented in _index.md as:
+++
title = "A partial list of colours"
description = "rainbows, etc"
+++
Both variables set are page variables available to all themes, so most (if not all) should support such a method using .Title and .Description on their list pages.
You would have to include an _index.md file for each directory, but it would be the same for your .info.json method.
… Rereading your first post, I think I may be misunderstanding what you are looking for. Is this information being created for the generated site (as I assumed) or for the CMS only, and is this information supposed to be available via the published site?
If it’s for the CMS only, you could put a .info.json or other file in the content directories and I think Hugo will just ignore them, maybe copy them directly into the generated site. Modifying the _index.md file will cause changes to the site (changing the list title, etc.).
Edit: If you go ahead with a custom data file, you can make Hugo ignore them when rendering.
Ah, thank you. This is exactly what I was looking for!
I didn’t realise I could add _index.md files in my content directory (I thought that notation was limited to the theme) and I didn’t know I could add files that only contain frontmatter and have the variables picked up by the outer template.
Essentially Hugo already did exactly what I wanted but I couldn’t work it out
Is this information being created for the generated site (as I assumed) or for the CMS only, and is this information supposed to be available via the published site?
Sorry, my original post might not have been the clearest. This is data that is managed by and displayed in the CMS that will be displayed in the published site. It’s intended to allow the CMS users to ‘describe’ the directories they add, add some data about the contents that will be displayed along with the list of files. Additionally, it makes things easier if titles contain accents or other funny characters. For example: