[4.0] [RFC] Refresh Module Chrome/Style System

[mbabker]

Module chrome (as it's called in the code, "Module Style" is the option in the module manager) is a bit of an awkward beast and shows its age. It's basically a decorator for a module's output, enabling users to put a module's output in some form of container with a bit of structure and some parameter integrations (such as showing a title if the chrome supports it). But, from a user and developer perspective, chrome is still a bit clunky:

• No way to override chromes (so the options added by the default system template can't be overridden/customized by a template)
• The chrome options aren't well explained
• The default options of the system template for both apps just feel dated (and actually at least 2 options for admin modules are completely broken on 4.0 right now; sliders and tabs)

So, some ideas I have floating around in my head:

• Deprecate the existing global function mechanism (modChrome_foo)
• Create a new class based mechanism (I don't know if we've gotten to a point where namespaces for templates are even a consideration, failing that some form of class structure akin to the routers and categories and plugins and install script standards will suffice), something close to how JHtml is modeled would suffice (if we couldn't find a way to just use JHtml on its own, the entire point of that API is to be a registry of HTML output helpers and that's what module chromes are by definition)
• Use a registry based system that allows overrides (so we arbitrarily load an application's default chromes from the system template, then an active template can override the system chrome if desired)
  • This gets a little awkward if you have multiple templates installed overriding the same chrome though
• If a registry can't work, what about using layouts?
• Some kind of screen in module or template managers explaining the chromes and how they decorate the module output (so there'd be something explaining what the admin sliders or the frontend's "horz" chromes actually do)

[brianteeman]

I never realised that you can't override them

I do use the chrome quite often though

[mbabker]

There are bigger fish to fry than this.

[ciar4n]

Some of the current system chromes seem very dated. Are we breaking b/c if we remove some of them?

For example, I am pretty sure these multiple divs were a kind of a background image hack for corners before the border-radius CSS property existed... https://github.com/joomla/joomla-cms/blob/staging/templates/system/html/modules.php#L115-L126

[brianteeman]

@ciar4n is there any harm in keeping them and just creating additional ones ??

[mbabker]

I'd suggest marking them deprecated in 4.0 then they can be dropped in 5.0. At this point adding more deprecations to 3.x for things to be dropped in 4.0 (which per SemVer means you'd need a minor release, and since 3.10 is last release...) should be stopped short of critical needs; I'd say the rounded chrome, while not up-to-par to today's standards, isn't something that needs to go away tomorrow.

But, there are chromes in the admin, like sliders and tabs, which either need to be fixed (they use MooTools helpers) or need to be dropped because right now those two chromes are fatally broken in 4.0 (try using one and you should get an error out of HTMLHelper::_() about being unable to resolve whatever class/service supports those).

[ciar4n]

@ciar4n is there any harm in keeping them and just creating additional ones ??

None at all. It was just my initial thought when I looked at them. As suggested by Michael, marking it deprecated in 4.0 and dropping it in 5.0 sounds fair.

[ciar4n]

One issue that sticks out is that the Module Tag, Bootstrap Size, Header Tag and Header Class parameters are only effective depending the chrome that is been selected. Some 'showon' values could be set for the system chromes but things then get hairy if these chromes ever do become overridable.

[Bakual]

I've started with some code to move the chromes to a JLayout: 4.0-dev...Bakual:ChromeToJLayout

The render part was actually surprisingly easy and already works.
Next is the style select field so a module actually can be set to a style. That should be easy as well.

My idea is then to create an XML per Chrome JLayout which would allow to define chrome specifics parameters. But there is a lot to think about here. They ideally should be prefixed with the template name to not clash with other templates chromes. And it needs some UI revamp to move all style related settings into an own tab where the params also change based on the style selection (should be possible using showon). I haven't thought much about it yet.

For the migration part - I would actually remove the old chrome support and only use JLayouts in 4.0. Templates that should work in both Joomla versions could then add the new JLayouts and keep the modules.php. The JLayouts will be ignored in J3 and the modules.php will be ignored in J4. So they would work in both versions. But that's also just an idea yet.

[ghost]

@Bakual should this Issue stay open?

[Bakual]

It's partially solved (eg overrides work now) but Michaels ideas would go further.