I keep a journal with Hugo. It includes all my posts. I would like to have Hugo produce a second website which is strictly a subset of the posts in the /content directory. To start, the subset would be “all posts with tag ‘mt3’” but in general it would be good to allow this to be flexible.
Looking through documentation, it seems maybe I could use the internationalization to produce the second website, but that would be creating incorrect meta data about the language used in each post.
I wonder if the same system that Hugo uses to ignore drafts could ignore everything except tag ‘mt3’…
Is there a canonical way to create two websites based on which posts have certain tags?
Spitballing: I’d probably create a theme that uses templates to exclude the posts I wanted, and then deploy with that specific theme (I normally use CI to deploy my sites).
For instance, I clone my theme before deploying, and I’d use a separate job with a different theme to create the site I wanted.
Thank you for this idea. I will look into excluding tags via themes.
Off topic, but can cloning the theme each deploy open you up to breaking changes?
I am still refining deployment technique. My deal is that I don’t want to include a theme in my content repo, even as a submodule.
Also, that repo is my fork of the Heather theme, so I can hack on it directly to learn more about theming; I’ve basically forked away from it and will never rebase from upstream again.
Also also, my deploy script doesn’t cache anything, but that is an option if one is going with GitLab CI.
Also also also, I don’t ever pull from source repos, especially for something like a theme; there are too many things I personally find unacceptable that can creep in with other enhancements, such as loading a Google Font, or adding some extraneous scripts that don’t do anything except slow down my site.
Locally my content repo is .gitignore-ing
themes, which has the repo of my fork there, so as I make changes to it, they get picked up in my deployment.
I may eventually add a theme as a submodule, but it will of course be a mirror or my original repo, rather than pulling from someone else’s public repo, which could just disappear one day.