Themes in UF4

[alexweissman]

Per my discussion with @lcharette in chat, we've decided that the best way to go forward with themes, is to simply define a "dynamic theme" as a series of Sprinkles from which to dynamically add paths to templates, assets, and locales. Please note that there might be some overlap with "static themes", which would simply be additional Sprinkles that are loaded on top of the rest of the Sprinkles in the SprinkleManagerctor in index.php.

We've also discussed the difference between a "community theme" - a Sprinkle or Sprinkles that is generic enough that it could be useful to other developers doing other UF-based projects, and "site themes" which are highly specific to a particular project's layout and functionality, and so would not be useful to the wider community.

[lcharette]

As with the current V4.0-alpha release, a theme doesn't need to merge multiples sprinkles anymore. Twig's namespace can be used instead.

The theme list and UI for the user theme still need to be done. Available themes should be listed in the sprinkle.json.

[alexweissman]

a theme doesn't need to merge multiples sprinkles anymore. Twig's namespace can be used instead

That would work for templates, but what about assets?

[lcharette]

Right, assets. As long as the assets build actually pick up the sprinkles not in the main sprinkle.json list, it could work. Not 100% foolproof, but still... We still have to figure something more robust for this.

[Silic0nS0ldier]

My idea is have a themes index in sprinkles.json, which would allow easier listing of themes in UF itself, plus more intelligent building of assets.

[lcharette]

To be clear, the current problem is more related to assets overlap between multiple sprinkles/themes. Let's say my sprinkle.json is defined like this:

{
    "base": [
        "account",
        "admin",
        "MyTheme"
    ],
    "themes": [
        "MyTheme",
        "MyOtherTheme"
    ]
}

Let's say MyOtherTheme is picked up by the asset build system... If MyTheme and MyOtherTheme both define a css/global.css file, currently only one of those two will be loaded / available at the css/global.css path. This is wrong, as one of the two will include the wrong css file... But it could be right to overwrite a css fie if MyTheme want's to replace, for exemple, one the the css file loaded by the core sprinkle....

It could be that the build system load them in different path inside assets/ when landing theme, but then it get complicated to write the bundle (is it where I really put the file or somewhere else?).

On the other hand, if MyTheme defines css/myTheme.css and MyOtherTheme defines css/myOtherTheme.css, then we're good. Even if MyOtherTheme requires both css files, it's just a matter of listing them both in the bundle. As long as they are both loaded by the build script.

(That's what I mean when I say it could work, but not 100% foolproof)

[Silic0nS0ldier]

And so we would enforce rules in the build system that would prevent overwriting of base assets.

So, if a theme attempted to overwrite css/main bundle, it'll stop and tell the dev that a theme was attempting to overwrite required assets. Same sort of thing for static assets.

[lcharette]

...and so it's the dev job to make sure his theme work with the rest of the system and fix the conflicts? I'm not sure this is a nice solution in the long term where I could download two UF "theme" from the internet. Fixing a conflict from an existing theme/sprinkle could be a pain...

[Silic0nS0ldier]

True, but ultimately the issues can be resolved with the appropriate design choices.

For instance, to prevent conflicts with static assets, have theme specific assets inside a folder named after the theme (eg: assets/local/mygreattheme).
Similarly with bundles, the names should give some reference to the theme they relate to.

Of course, there would still be the issue of conflicts with vendor assets, like a bootstrap v4 based theme would conflict with the core Sprinkles own bootstrap v3. So I see you point.

[lcharette]

I have a general idea how I want to handle themes in UF. Spoiler alert, it involves composer.json. Unfortunately, this will requires a lot of work plus building an entire new theme for UF as a test / demo. This issue is then pushed back to the 4.2 milestone.

[lcharette]

In reference to #818, the second "official" UF theme could be Bootstrap 4 based...