I built a front end to let a user make edits to the Hugo Agency theme and to save markdown for a blog post. I looked at extending it to some other themes, but noticed that there’s variation in the config files as well as where to save content and images.
I can crib Hugo’s code for managing the configuration files, so I can be sure to stay in sync with the config formats. That’s not a pain point. It’s dealing with the different ways that themes are using configs and data files that I’m wondering about. A while back there was some discussion on standardizing things like authors and social links, but I can’t find a post with a definite conclusion.
Is there a standard? If anyone else had done this, or is doing this, what’s your approach? Are you trying to be flexible about configurations or targeting a single theme?
In other words, it’s great that Hugo’s not opinionated, but it’d be nice sometimes if it were. Maybe the best that I can do is say “if your theme is willing to accept this convention, you can get this result.”
I’m not asking about an API or the internals of Hugo. I’m interested in how themes are using the config.(json|tomlyaml) file , data files, and how content is being filed away (blog vs post vs article). I don’t think that it’s possible (or even desirable) to build a front end that works for all themes. Is there something that I could target that would work with a good chunk of them, though?
Not really. From what I’ve seen from other front ends one has to make some adaptations to a theme to make it work. For example Forestry relies on front matter parameters mostly.
If I were you I would try to cater for the things are usually present in Hugo themes.
The Agency theme has its own special way to deal with data and so do other themes as you’ve seen. So that’s something that you cannot know in advance.
Also whenever bundles become available static assets’ location will change if a user desires to have them alongside content.
I’ve started working on an interactive application to help generate configuration files for Hugo sites using a question/answer system. The way I’ve been going about it is providing a base set of Hugo configuration options, then a theme “overlay” on top of that. The two sets of configurations are merged into a single survey of sorts that the user can then populate, then the program puts those responses into a configuration file.
Or that’s how it will work, at least, when I have time to work on that. Anyhow, that’s what I figure your best option would be - have a hardcoded Hugo configuration set and maybe some built-in theme configurations, plus the ability to (up)load alternate configurations for other themes.