Component partial grouping / theme framework identifiers

[bennothommo]

One of the common problems I've encountered with plugin components is that the plugin author has written the default components in a different front-end framework and thus the partials are using classes and styling that might not work for another given front-end framework. I've also seen this mentioned a fair few times by the community as well.

Currently, the default workflow with this is generally to expect the theme developer will either override the component partial with their own, or at least define the component's HTML in their own CMS templates. While this is fine in most cases when people are making bespoke themes for their projects, it might be a point of friction for people who want to simply purchase themes and install plugins that the theme developer didn't cater for.

I propose that we could implement a partial grouping system which would work with a set of framework identifiers and allow plugin authors to develop partials for common front-end frameworks that, when used in conjunction with the theme specifying that same framework identifier, will allow the component to deliver the partials for that framework and making the plugin components more "drop-in".

The proposed workflow would be as follows:

• The plugin author defines, for each component, that it supports an array of framework identifiers (ie, bootstrap, tailwind, etc.) in the component configuration. One of the frameworks must be specified as a default.
• The plugin author develops the partials for the component the same as before. In addition, they can specify a subfolder within the partials directory that matches the framework identifier, and inside, they can add the same partial filenames and adjusting the HTML to match the given framework.
• The theme developers, in conjunction, as part of the theme.yaml file, can specify that their theme is a given framework identifier, matching the framework they used to build the theme.
• Winter CMS, when loading up the theme and processing a component, will go through the following steps:
  • If the theme overrides the partial, this is used first, before any other options are considered.
  • If the theme reports a framework identifier, and that framework is supported by the component, load the partial for the framework.
  • If the theme reports a framework identifier, and that framework is not supported by the component, load the default framework's partial.
  • If the theme doesn't report a framework identifier, load the default framework's partial.

Proposed identifiers

• bootstrap: Bootstrap
• tailwind: Tailwind CSS
• spectre: Spectre.CSS
• foundation: Foundation CSS
• semantic: Semantic UI
• bulma: Bulma
• uikit: UIKit

[mjauvin]

That would add quite a bit of complexity. How do you cope with differences in frameworks versions (i.e. bootstrap 3/4/5, uikit 2/3)?

[bennothommo]

I suppose we could support different major versions. bootstrap3, bootstrap4, perhaps. I think most frameworks tend to keep support for old class names.

[bennothommo]

@mjauvin is there anything that is unclear in my proposal above? The way I see it, I don't find this complex at all, given that it is an optional layer of templating from the plugin-side. It just means one extra file lookup, really.

[LukeTowers]

How is this handled by other projects, i.e. WordPress?

[bennothommo]

Not sure - haven't researched it yet. I posted this up more as a conceptual idea.

[mjauvin]

@bennothommo it's clear, but I really don't think this is the framework's role to do this. It's always been clear that component partials are there mainly as a placeholder for demonstration purpose and should be replaced.

To be frank, I really doubt plugin authors will start writing partials for multiple css frameworks.

[bennothommo]

The framework would just be providing the conduit to make it happen - it's still up to the plugin and theme developers to utilise it.

My line of thinking is - would plugin authors not write for multiple frameworks, or are they not writing for multiple frameworks just because there's no mechanism to do so?

[LukeTowers]

Personally I think it's because even if authors provided multiple base versions for different frameworks, pretty much every theme is going to require customization work to make it work perfectly within that theme anyways, so why bother?

[damsfx]

Having "child themes" for which one could find partials per component (plugin) also gives a solution to this problem, no?
It is up to the theme designers to offer components for the most common plugins.

I make a Tailwind theme and offer the "demo" child theme which offers the required partials for the demo plugin.

[bennothommo]

The gist of this idea is to give the plugin developers some way of providing example partials for a wider variety of frameworks - of course, theme developers are still free to apply their own design, and if we support child themes, this too would help with that.

I just feel that reducing friction for people to install plugins and have those provided components simply work on any given theme would be a net positive for Winter, especially for casual users who are trying out Winter but might not necessarily have the knowledge to customise it to their theme.

[LukeTowers]

I appreciate the sentiment, but I think the entire theme user experience needs to be a lot smoother in general before we actually run into that as the main pain point blocking people from becoming comfortable with Winter.