I’d like to propose a mechanism by which themes could become more standardized and interchangeable.
I recently started using Hugo. I was immediately impressed by the flexible and rich data-model it supports. On the face of it, the content is all Pages, and you can decide if you want to have specific Sections and related Archetypes. Plus, you have all the power of defining your own Taxonomies and even just straight-up raw Data if all of these other generic concepts cannot be used to provide what you need. Very cool!
But, now I’m looking at the theme gallery and even trying switching from one theme to another. Oh, no! This doesn’t work at all. One theme assumes that I have sections under “post” and “project?” Another theme assumes I have data about each author in a Data.authors listing. The theme is making all sorts of assumptions about my content and data, and requires a bunch of additional configuration specific to that theme to make it work. Now, if I want to switch to some other theme, I’ll have to start all over again! Waaaah!
Themes Aren’t Standardized
So, the problems, as I see them, are that Theme authors are missing advice on how to design their themes to be swappable. Every theme author comes up with her or his own workarounds and hacks to accomplish the same goal, but in a different way. Usually, this involves a lot of Params in the Site config files and in the Archetypes for the various sorts of pages they support.
Introducing Features (or Theme Features)
Wouldn’t it be great if there were a list of features (conventions) that a theme author could promise that they support, and then, users could know that if they are switching from using one theme to another, they need to have overlapping feature sets, or things might break. Also, you could have really clear and standard error messages when you attempt to use a theme which doesn’t support a feature your content is obviously attempting to use. Basically, a Feature set of features would be defined in your config file.
Features = ['multi-author', 'gallery', 'hero-image']
Then, you, the user, would go about configuring your content according to the conventions that each of those features require. Oh, I see, using the ‘gallery’ feature means that I will have to specify a list of GallerySections in my config and then put all the images in those designated sections.
Theme authors would then be able to say that they support certain Features and (implicitly) that they don’t support others. It would also make it the Theme author’s responsibility to gracefully degrade when the content doesn’t use a Feature the theme supports. For example, I don’t have any plans to expose who the authors of my website are. So, even though you support the ‘multi-author’ Feature, you better remove that part of your layout and figure out how to make the theme look good anyway.
Theme authors would actually list the themes they support in their theme configuration file, and it would enable the Theme gallery to be filtered by themes which support the features the end-user is most excited about using.
I can see that some support is currently under consideration for adding standardized support for Authors. But, it makes me wonder if it shouldn’t be extracted into the first example of a Feature. If your site doesn’t use the feature, why should you have the cognitive overhead when reading the documentation of seeing a .Site.Authors variable. I really like the idea of standardizing on very commonly-used features of websites, but I think it would be a more generic enhancement if each of these features could be developed, and reasoned about separately.
Features offer a bridge between the generic nature of the core of Hugo and the specific nature of the Themes currently in existence.