? ? No Code Attached Yet J4 Issue
avatar mbabker
mbabker
25 Jun 2018

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)
avatar mbabker mbabker - open - 25 Jun 2018
avatar joomla-cms-bot joomla-cms-bot - change - 25 Jun 2018
Labels Added: ? ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 25 Jun 2018
avatar joomla-cms-bot joomla-cms-bot - labeled - 25 Jun 2018
avatar brianteeman brianteeman - change - 25 Jun 2018
Labels Added: J4 Issue
avatar brianteeman brianteeman - labeled - 25 Jun 2018
avatar brianteeman
brianteeman - comment - 25 Jun 2018

I never realised that you can't override them

I do use the chrome quite often though

avatar franz-wohlkoenig franz-wohlkoenig - change - 25 Jun 2018
Category com_modules
avatar franz-wohlkoenig franz-wohlkoenig - change - 25 Jun 2018
Status New Discussion
avatar mbabker
mbabker - comment - 9 Sep 2018

There are bigger fish to fry than this.

avatar mbabker mbabker - change - 9 Sep 2018
Status Discussion Closed
Closed_Date 0000-00-00 00:00:00 2018-09-09 16:37:26
Closed_By mbabker
avatar mbabker mbabker - close - 9 Sep 2018
avatar ciar4n
ciar4n - comment - 14 Jan 2019

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

avatar brianteeman
brianteeman - comment - 14 Jan 2019

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

avatar mbabker
mbabker - comment - 14 Jan 2019

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).

avatar mbabker mbabker - change - 14 Jan 2019
Status Closed New
Closed_Date 2018-09-09 16:37:26
Closed_By mbabker
avatar mbabker mbabker - reopen - 14 Jan 2019
avatar ciar4n
ciar4n - comment - 14 Jan 2019

@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.

avatar ciar4n
ciar4n - comment - 14 Jan 2019

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.

avatar Bakual
Bakual - comment - 14 Jan 2019

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.

avatar franz-wohlkoenig franz-wohlkoenig - change - 4 Mar 2019
Status New Discussion
avatar franz-wohlkoenig
franz-wohlkoenig - comment - 2 Apr 2019

@Bakual should this Issue stay open?

avatar franz-wohlkoenig franz-wohlkoenig - change - 2 Apr 2019
Title
[4.0][RFC] Refresh Module Chrome/Style System
[4.0] [RFC] Refresh Module Chrome/Style System
Status Discussion Information Required
avatar joomla-cms-bot joomla-cms-bot - edited - 2 Apr 2019
avatar Bakual
Bakual - comment - 3 Apr 2019

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

avatar franz-wohlkoenig franz-wohlkoenig - change - 3 Apr 2019
Status Information Required Discussion
avatar jwaisner jwaisner - change - 19 Mar 2020
Build master 4.0-dev
avatar joomla-cms-bot joomla-cms-bot - change - 19 Mar 2020
Labels Removed: ?
avatar joomla-cms-bot joomla-cms-bot - unlabeled - 19 Mar 2020
avatar joomla-cms-bot joomla-cms-bot - change - 19 Mar 2020
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 19 Mar 2020
avatar Hackwar Hackwar - change - 18 Feb 2023
Labels Added: ? ? No Code Attached Yet
Removed: ? ?
avatar Hackwar Hackwar - labeled - 18 Feb 2023

Add a Comment

Login with GitHub to post a comment