Why does one inherit a theme rather than copy it? I think I’ve heard the statement that it should be inherited because you will inherit any updates that are made. Is that correct? But what if one is 100% satisfied with an existing theme and doesn’t want any updates? Maybe updates will not be wanted. Maybe updates will insert bugs, etc.
An important argument is that Theme Inheritance deduplicates functionality, rather than reinvent it. Which is to say, it is easier to add on or adjust the large feature-set most themes come with. You don’t need to update the parent-theme if you don’t want or need to, but having a child theme often makes it easier to ascertain what changes you made to the original without digging into code-history and comparing changes. You can just switch between them.
Some themes also optimize for this, allowing more advanced functionality to override the original theme, without the need for monkey-patching code.
1 Like
Here is my current understanding of inheritance.
If a new theme is created by inheritance, then the new theme has a dependency relationship to the parent theme, and is, therefore, not independent. And the new theme is not fixed; it may change if the parent theme is changed.
I think, in most cases, if I create a new theme, I would like it to be independent so that it is fixed, and I know it will not change unless I change it.
Not entirely; the child-theme utilizes components such as templates, scripts, styles, and logic from the parent-theme, but it will not change by itself. There’s also the option to create a copy of a theme with a new name, which shares no components. DevTools has an easy command for this.
In terms of dependency, if I create a child-theme of a theme I would generally not update the parent-theme unless I reviewed and tested the upstream changes. I would rather consider it’s version fixed.
1 Like
Thanks for setting me straight. Since I have almost no understanding of how Grav works, I was under the impression that if someone else other than me was the creator of the parent theme, they could change it and my inherited theme would also change. What you said makes sense, but I still like the idea of having independent themes. Maybe as I learn more I will change my mind.
That’s a good attitude and I won’t be surprised if you do.
It’s when you want to add to or change something in the theme, apart from the settings it provides (which can go in user/config/themes/[themename].yaml), that you’ll appreciate inherited themes. Some themes like Quark and Canvas embed a lot of customisation in their configs so I could understand you’d be happy with that.
I tend to automatically inherit because it’s simple once you know how, with devtools, and it leaves the door open to customise more readily.
1 Like
What I do not yet understand is why it is easier to customize an inherited theme than it is to customize a copied theme. When you create a new theme via inheritance, is there something extra that is added that is not in a copied theme? If so, what is added?
I don’t think that claim has been made. Closest I can see is where @OleVik said “having a child theme often makes it easier to ascertain what changes you made to the original without digging into code-history and comparing changes. You can just switch between them”
It’s easier to manage and, importantly, to put under version control cleanly, and it doesn’t close off the possibility of incorporating improvements to the parent theme should there be any.
Like I (kind of) said earlier above, you may or may not see the benefit after some playing around. If you don’t, then stick with what works for you.