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:
So, some ideas I have floating around in my head:
modChrome_foo
)Labels |
Added:
?
?
|
Labels |
Added:
J4 Issue
|
Category | ⇒ | com_modules |
Status | New | ⇒ | Discussion |
There are bigger fish to fry than this.
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-09-09 16:37:26 |
Closed_By | ⇒ | mbabker |
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
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).
Status | Closed | ⇒ | New |
Closed_Date | 2018-09-09 16:37:26 | ⇒ | |
Closed_By | mbabker | ⇒ |
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.
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.
Status | New | ⇒ | Discussion |
Title |
|
||||||
Status | Discussion | ⇒ | Information Required |
It's partially solved (eg overrides work now) but Michaels ideas would go further.
Status | Information Required | ⇒ | Discussion |
Build | master | ⇒ | 4.0-dev |
Labels |
Removed:
?
|
Labels |
Added:
?
|
Labels |
Added:
?
?
No Code Attached Yet
Removed: ? ? |
I never realised that you can't override them
I do use the chrome quite often though