Create Theme as ValueObject and add theme inheritance

[Koc]

Imho Theme should be not just string but class (VO). And also it will good support inheritance of themes.

[Koc]

I cann't select what be better:
a) each theme bundled with their own class wich impliment ThemeInterface or
b) one class Theme + configurations (but where this configuration should be stored and in what format?)

interface ThemeInterface
{
    function getName();

    function getParentThemeName();

    function getAssetsVersion();
}

What do you think, @lsmith77 , @ebi , @beberlei ?

[lsmith77]

One thing to keep in mind here is that some users have dynamic themes, aka they do not hardcode the list of themes. i don't really want to complicate their use case. As such I am not yet sure if there is really a benefit here that warrants the added complexity.

[Koc]

are you talking about ValueObject or about theme inheritance in whole?

[lsmith77]

both ..

[lsmith77]

so in other words to convince me .. you will have to present a more complete argument .. maybe the others are easier to convince :)

[Koc]

Theme inheritance is most often thing. Magento has similar to now fallback mechanism, but in Magento2 will present real theme inheritance http://dimitrigatowski.com/2011/06/19/magento-2-preview/

For example now I'm working with one sport social network. There is two sites: for riding sports (bike, ski) and for commans sports types (hockey, football). Second site will extend theme from first. There is also mobile (light) version, wich will override some layouts from second site.

And other case (fabricated): there is SAAS and customers can use own themes. And like in Magento they want use themes inheritance.

VO just helps create hierarchy of themes, this is optional.

[lsmith77]

ok .. talked to some people ... and it seems there is demand for this feature. can you make a proposal for an implementation?

[lsmith77]

as for your question from above .. i tend toward b) as this will likely make the life easier for people with dynamic themes

[Koc]

I will try to do something with this at weekend

[Koc]

sorry for delay, haven't yet time to seat and consider how it should be realized :(

[COil]

Interested in this too...

[skydiablo]

me too

[DanielFatkic]

I'm interested in this too!

Anybody started with this?

[trsteel88]

Is #68 what you are after?

[yellow1912]

This is a feature request. I wonder if there is a good way to do this. Let me try to elaborate with an example:

Lets say I have a theme called MyBeautifulDefaultTheme which is used for the site official layout. However, since XMas is coming, I want to create a variant of the theme (perhaps with the red/white theme color etc...).

I don't want to (and should not have to) clone the full MyBeautifulDefaultTheme theme and edit it. I can simply created a new theme called MyBeautifulXmasTheme specify that it inherit MyBeautifulDefaultTheme. Now, for every template and asset files that are not present in the new theme Liip should automatically fall back to the parent theme to see if they are there.

(I believe with the current system Liip can already loop through the list of all themes to look for files. However, this is not the best approach I believe. The reason is that I can have 10 themes in stock and they are not all related to each other. Without proper ordering of themes (and sometimes it's also impossible to do so) we will have un-intended fallback.

[oleg-andreyev]

We have similar situation for our websites (we have multiple websites on platform), each website has two theme <website_name> and <website_name>_phone, so for example: if FileLocation won't find x.html.twig in .._phone, it will try to find x.html.twig from regular theme (fallback, see: https://github.com/liip/LiipThemeBundle#change-theme-cascading-order), so you just need set MyBeautifulXmasTheme as active theme, and if some template won't be found in this theme it should load from original theme

[yellow1912]

@oleg-andreyev yup, we are using that solution as well. The only issue is that if you have more than 1 active set of themes, say

1. Theme A with a subset of B,C,D
2. Theme E with a subset of F,H,G

Now there will be a problem because we may want to fallback for G to stop at E only and not going any further than that. But with the current solution you must place A,B,C,D,E,F,H,G all into the list thus the fallback may go beyond what is desired.

Why do we have 2 active sets of themes? Well a real life example is to serve different customer segments with custom layouts. Another real life example is when you want to do A/B testing on the whole site.

For now, we get around this by overriding the ActiveTheme service and set themes upon each request. For example, if we decide to serve theme C then we will set A and C only into the theme list. We are still doing some tests to see how it work with assets however.

[lsmith77]

I think finding a solution for A/B testing is certainly interesting. That being said, its certainly a whole new level of complexity that you describe above. So if someone does come up with a solution for what you describe, we should be careful to not make the current solution more complex for people that are happy with the current feature set.