Badlapje
commented
4 years ago We're currently looking into resolving this issue as part of a new theme that is being developed. Below is the idea, any feedback is very welcome! Doubly so feedback from @tvdijen ;-)
- There will be a base theme which will be the fallback theme in case a template is missing in the custom theme of choice. It'd contain:
- generic html: things like all templates necessary for the routing
- generic scss: normalize, mixins, variables, ...
- generic js: atm we're thinking of the search functionality would be the only thing (but I haven't touched this part yet, so there might be more)
- Each custom theme will be fully self-contained and import the css/js it wants from the base theme. The base theme will be set up so as to allow easy overwriting of variables (through the use of the !default option for sass). Only templates from the base theme which need to be overriden should be in here. Anything that can stay the same, simply stays the same. The way that works is described here.
- Switching between themes will be done by changing a new config parameter called theme.name. We could make this an array as well to allow for custom themes which build upon another custom theme (say you find the new theme ok, but you want to override only the footer that should be possible).
- We will use a simple node.js script to ensure that the build of the css / js chooses the right theme(s). It'll also ensure the config values for the twig theme are set according to user preference (as expressed in the theme parameter).
- Documentation will be improved to ensure that it's clear how to override / extend themes.
As for @tvdijen's ideal scenario: i'm not sure that this would make your theme installable via composer. It should be possible to amend the node.js script in such a way that it "sees" that a theme is installed with composer and looks in the right place. But the amount of time i have to look into that depends on how fast i can get the new setup to work.
thijskh
I was asked by @pablothedude to file an issue here to discuss some of the things I ran into during the migration of my custom theme to the new style theming in 5.11..
1) At first, it wasn't clear to me when I followed the docs that I could actually add paths to my custom theme instead of replacing them as suggested. If you replace them, you'd have to copy everything from the base-theme which is exactly what we don't want. It should also be very clear that the order of the paths matters and that your custom theme paths are likely to go first, base theme paths second.
2) It wasn't possible to easily change the base color scheme, which as addressed and solved in #730.. There may be more cases like this.. I haven't ran into them, but I haven't touched JS-overrides at all, so perhaps it needs a quick scan to make sure.
3) Eventually I managed to get a good end result, but one thing that stings is that I have to copy a whole template for only minor changes. @pablothedude suggested that this may or may not be solved using imports..
An example of the changes I make to the templates:
inserting a bit: https://github.com/SSCICT-IAM/OpenConext-engineblock/commit/694b2a80e18c6722b71f080b93723e6ea0d15720#diff-108b1b17d75b6547aabb206228296641R34-R60
replacing two blocks compared to the original template: https://github.com/SSCICT-IAM/OpenConext-engineblock/commit/694b2a80e18c6722b71f080b93723e6ea0d15720#diff-a1fc1f8adf5df700b32c91fcc108bd13R9-R10
4) The custom theme is not really self-containing.. It's still spread over at least three directories:
Even more ideally (a man can dream, right?) I'd install a theme using composer, perhaps with a little help of an installer similar to https://github.com/simplesamlphp/composer-module-installer