Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Use 'themes' to group and relate sets of templates #91
digest: a request to improve core templating functionality and terminology with generalizable themes that can tightly integrate across projects
As a further development to a swappable / selectable 'template directory', kindly please introduce the concept of a 'theme'. It might have the same basic contents and a config file, plus one more very valuable feature. Instead of putting every piece of a site's template logic in one set of templates, in a single directory, you could break it up into reusable components shared across projects using sets of themes.
One simple approach, afaics, is for users to put each of their themes in the same directory, then Gutenberg would start by loading the one "site theme" set in the site config file, and then it also would read that theme's config file to load any additional themes set in their configs. When loading them, namespace each template by its theme, and when a template 'extends' another template, first look within its own theme and if not found, look to the themes in that theme's config file in the order in which they are listed.
I began development on a starter theme, which I would like to port to Gutenberg, which demos this feature, called Salutations (renamed from Base) and have a 2 and 3 level inheritance example, Fixed Sidebar and Colored Fixed Sidebar.
They use this functionality I tried producing for Pelican, using Nikola, Sphinx Docs, and Drupal sub-themeing as inspiration. (Note: If you look through these themes, go back one commit because I changed it to use an "explicit inheritance" implementation branch of Pelican rather than the "implicit approach" using config files. (I should have made that change in a separate branch.))
Mild aside: Another foreseeable advantage of using config files comes in setting theme-specific variables, eg for colors, CSS and js includes, etc, and any template logic level variables that would make sense to separate from the site config. (future note: look into potential for using a library for calculated color schemes, mentioned in a YUI video.)
In terms of picking names for this theme variable and the types of relationships, 'parent_theme' seemed to fit at first with themes that extend it called "child themes". Since then, I see "parent(s) + child(ren)" relationships as putting unneeded limits on vocabularies and functionality in order to match our familiar, natural human reproduction terminology. Also, calling this a (2 parent max) "hierarchical inheritance" feature would limit expected possibilities to uni/bi-directionality, while Nature seems to have more flexible sourcing and pandirectional meme transfer, allowing for unforeseeable mixes, hybrids, and crossbreeds. So I would push, ever so lightly, for a
Sorry for the late reply.
I'm planning to add themes but they will be much simpler in scope, more like the hugo ones where they are basically a repo. I'm thinking of adding a command to help that but I will only start thinking about it once Sass support is in