Generate CSS independent of DB

[umulmrum]

Describe the solution you'd like Currently we generate CSS from Less online, as we need to have a DB connection. This is because we generate CSS for each portal and portals are defined in the DB. In order to simplify deployment (by generating CSS on a build server), we should do a few changes:

• Move the content of the field "Own LESS file" in "Website presentation / themes" to file-based configuration. This means that a theme itself needs to be defined in file-based configuration (details yet to be discussed).
• In "Website presentation / themes" we need a new field that links the theme defined in file-based configuration to the DB, so we can assign a theme to a portal as before.
• When generating CSS, we generate one file per theme instead of one file per portal.

[umulmrum]

Before we start working on this feature, we should contemplate the mid-to-long-term goal: Frontend assets should be generated by standard tools such as Webpack Encore, and a solution for this problem shouldn't stand in the way of future changes.

[umulmrum]

Configuration could look like this:

chameleon_system_view_renderer:
    frontend_themes:
        my_theme_name:
            less:
                entrypoint: '/assets/standard-assets/less/chameleon.less'
                snippet_paths:
                    - '@ChameleonSystemCoreBundle/Resources/views'
                    - '@ChameleonSystemCookieConsentBundle/Resources/views'
                    - '@ChameleonSystemChameleonShopThemeBundle/Resources/views'
                    - '../extensions'
                    - 'standard'
        another_theme_name:
            less:
                ...

In the backend's theme management we could then let the user select the theme from a select box (in this example the select box contains "another_theme_name" and "my_theme_name"). This would then link the theme definition to the DB entry, and from then on it would work mostly unchanged compared to the current implementation. The Less generation would create e.g. web/chameleon/outbox/static/less/my_theme_name/theme.css files.

The example is just a 1:1 port from the current standard configuration without too much attention to detail. While there will be several details to discuss, I'd like to focus on the coarse concept for now. Is this viable?

Pro:

• Independence from the DB.
• Snippet chain can still be modified in the project.
• Quite easy implementation.

Con:

• Changes in snippet chain entries must be performed manually (also making it more difficult to add third-party themes; users might want to try different themes rapidly).
• Not that user-friendly having to manage themes both in config files and in the DB.
• Symfony container is required to build Less, which doesn't play well with Webpack Encore (not worse than the current implementation, but not better either).

In the future I'd like to drop the snippet chain completely, but doubt that we can currently find the time. If we did this, we could use a tagged service that provides the required information for each theme.

We should try to avoid distributed configuration. As a user I find it hard to grasp that there is a backend entry "My theme" in which I need to select another thing named "My theme" from a select box; this is a purely technical distinction. Maybe we can remove or hide the backend's theme configuration entirely? The theme selection in a portal could then load the available themes directly, and instead of a theme ID we could link by name. We would need to remove "theme block layouts" and the "directory" - I do not know if these features are widely used and didn't think about how they could be replaced yet.

As for usage with Webpack Encore, I'm quite clueless yet. We can neither use the DIC nor the DB but have overriding logic - I think we'll need custom code to do this, and guess that we can ignore it for now.

WDYT @rnuernberg ?

[rnuernberg]

The reason we need the container ist, that we collect additional .less files from the snippet folders - korrekt? The intention behind that was a) I can overwrite a less file by defining a new configuration further down the snippet chain b) Less files a generated with only the styles that are actually used on the page

I know that at least (b) never worked as intended. So we can ignore this.

(a) may be used in some projects to remove/add less and js - but I think it would be OK to deprecate this, if we provide a sensible alternative. Keeping the snippet chain itself should not pose a problem for encore as soon as we remove the asset handling from it.