Cascading Themes?

[adrexia]

Is it possible to use cascading themes with subsites? Or to define the allowed themes from yml? It looks like they might currently be able to be set from config.php, but it would be super handy if we could define a list of themes from yml. eg:

SilverStripe\Subsites\Model\Subsite:
  allowed_themes:
    - '/theme-default'
    - '/theme-other'

Or, if cascading needs to be defined:

SilverStripe\Subsites\Model\Subsite:
  allowed_themes:
    defaultThemeName:
       - '$public'
       - '/theme-default'
       - '$default'
    otherThemeName:
       - '$public'
       - '/theme-other'
       - '$default'

[NightJar]

We talked on slack around how the following code sets a protected static variable in a form of memory cache that lasts the request, as opposed to config.

silverstripe-subsites/src/Model/Subsite.php

Lines 175 to 180 in 5b8a0db

	* @param array $themes - Numeric array of all themes which are allowed to be selected for all subsites.
	*/
	public static function set_allowed_themes($themes)
	{
	self::$allowed_themes = $themes;
	}

This led to conversation opining about how this may be due to per-subsite theme restrictions.

I think it is probably because it's dynamic per subsite.
an config is not dynamic, and for all subsites.
(sic)

Am I understanding the usecase you're after here in that you'd like to have a way to set themes subsites can use globally, before then filtering that list down via the current process (allowed_themes)?

[adrexia]

There doesn't seem to be an interface for setting allowed themes based on subsite, so I guess currently that would have to be hardcoded to a SubsiteID if used dynamically?

Our current use-case is to be able to define our themes (at all). Other than this module, there is no requirement with Silverstripe 4 for themes to live in a themes folder, so our themes normally don't. But on top of that, we have some cases where the subsite theme differs very little from the original theme, and it would make sense to use the cascading theme behaviour of SilverStripe 4. There are work arounds for that if we need them (e.g. moving theme templates out into a module).

One other thing to consider is that cascading themes make little sense on their own. Its only with Subsites that they start to have value.

[NightJar]

Neat, thanks for the extra info :)

[NightJar]

I'm going to increase the impact on this since for CWP the Watea theme would cease to function, as it relies on the cascade.

[robbieaverill]

I think we can also call this a bug too

[ScopeyNZ]

Ok I've looked into this a bunch.

Themes do cascade by default in subsites. The theme you choose with the dropdown available in subsites will pick a theme to be moved to the "top of the list". It will then cascade down your existing theme definitions.

I'm going to prep a patch that will basically ignore all themes defined above the theme in your themes definition when you choose a theme using the dropdown. This is a bit of stop-gap fix.

I think @adrexia's suggestion of defining cascading theme "bundles" is still really good. I like the following example configuration - we can do it in a non-breaking way - essentially defining a different way of declaring the theme dropdown. It might be better to give it a different config key though

SilverStripe\Subsites\Model\Subsite:
  allowed_themes:
    defaultThemeName:
       - '$public'
       - '/theme-default'
       - '$default'
    otherThemeName:
       - '$public'
       - '/theme-other'
       - '$default'

This is definitely an enhancement. I'll create a PR for the aforementioned patch but I'll change this back to an enhancement.

[robbieaverill]

Fixed in subsites 2.1.x