I would appreciate so much that Hugo had theme inheritance abilities. This is what we can do on eg. wordpress and this functionality is extraordinary: this way, you can make your own theme based on an existing one, while still getting updates from the base theme. If you don't do so and want to get the updates, you have to merge some git branches (for instance), and that contributes to keep non-developers away from using hugo.
What I suggest is like Wordpress: in the child theme, setting which is the base theme (that can be done inside the theme's config file like parent = "hugo-material-docs"), and always preferring a new file when available.
Note: to my mind this functionality does not seem to exist inside any other static site generator for now, but I assume this is a must-have in a widely used static site generator!
What do you think of it?
lebarde
All 14 comments
this is a must-have
That is taking it too far, me thinks. There are lots of theme related stuff that comes further up the ladder than this one (standards, widgets ...).
bep
on 27 Oct 2016
There are lots of theme related stuff that comes further up the latter than this one (standards, widgets ...).
Do you mean functionalities that are more important to develop first? (in which case I agree!)
lebarde
on 27 Oct 2016
Do you mean functionalities that are more important to develop first?
Yes, I meant to write "ladder".
bep
on 27 Oct 2016
Okay! Anyway I think this is not too difficult a task to develop.
lebarde
on 27 Oct 2016
On the Hugo discussion site, this thread is similar, to wit:
For each directory (anywhere) named themes/, everything under a certain subdirectory of it is fallback for everything outside that themes/ directory; themes/../config determines which subdirectory.
What new behavior would we (hypothetically) obtain? Perhaps sub-themes, or theme families.
So fileOne would be inherited from [parent theme] themeOne, and fileTwo would be inherited from [child theme] themeTwo.
MarkDBlackwell
on 19 Jan 2017
What Hugo should have is:
- A way to say that a theme extends another theme, i.e. in some theme config
extends: someother-theme
It does not need to be hard, but we should probably first address the somewhat clumsy theme addressing scheme (now people have to manually download themes and put them in a magic folder).
bep
on 19 Jan 2017
See also this discussion here:
https://discuss.gohugo.io/t/theme-standards-and-general-experience/6438
lebarde
on 4 May 2017
@bep, for the naming convention of a config file: Actually a lot of theme designers already use config to put a sample main config file inside the theme tree, so using this name would break all those themes.
What would you tell about a theme.toml (or theme.yaml, and so on) for a theme configuration filename? IMO that would be clear enough.
lebarde
on 18 May 2017
theme.toml is already part of themes; e.g.:
https://github.com/sethmacleod/aerial/blob/master/theme.toml
rdwatters
on 18 May 2017
Snif… What would be suited best?
If that filename is less used than config.toml, maybe we could contact the theme creators who use that name. What else could be imagined as a filename?
lebarde
on 18 May 2017
@lebarde please don't start discussions on tiny implementation details when the full picture is so unclear. That is just a waste of everyone's time. I have said it before, but I can say it again: Before we even start to think about theme inheritance, we need to handle external resources in a much better way than it is today. And that is a task much bigger than a simple config file.
bep
on 19 May 2017
@bep Thanks for clearing the situation!
You are right about the fact that the picture is unclear. When I dived into the code I effectively saw that I would have to hook every access to a file to look for a parent. That would be made things most complicated.
It does not need to be hard
And I may have misinterpreted your statement. Anyway, I did not know (or remember) that you said that. As you said it did not need to be hard, I started to try. I recognize that external resources have to be handled another way before starting that, so I will not go further on that case!
lebarde
on 19 May 2017
When I dived into the code I effectively saw that I would have to hook every access to a file to look for a parent. That would be made things most complicated.
The inheritance part of this is easier than you think, but again, this must come after some other thing.
bep
on 19 May 2017
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.
![stale[bot] picture](https://avatars3.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 6 Dec 2017
Related issues
bep
·
3Comments
MunifTanjim
·
3Comments
VoidingWarranties
·
3Comments
carandraug
·
3Comments
digitalcraftsman
·
3Comments
Most helpful comment
@lebarde please don't start discussions on tiny implementation details when the full picture is so unclear. That is just a waste of everyone's time. I have said it before, but I can say it again: Before we even start to think about theme inheritance, we need to handle external resources in a much better way than it is today. And that is a task much bigger than a simple config file.