Bug #103388
closedBackend button with class different than "btn-default" fails to render with given class
0%
Description
Creating a button in a TYPO3 backend module and setting a different class:
$buttonBar = $moduleTemplate->getDocHeaderComponent()->getButtonBar();
$lockButton = $buttonBar->makeLinkButton();
$lockButton->setClasses('btn-warning');
results in a the following class attribute:
<a href="..." class="btn btn-sm btn-default btn-warning">
</a>
The style of "btn-warning" is never used, as "btn-default" is still in the class list.
There is currently no way to remove the class "btn-default".
Looks like a mismatch in the backend.css file, where "btn-warning" is defined before "btn-default".
.btn-warning{--bs-btn-color:#000;--bs-btn-bg:#e8a33d;--bs-btn-border-color:#e8a33d;--bs-btn-hover-color:#000;--bs-btn-hover-bg:#ebb15a;--bs-btn-hover-border-color:#eaac50;--bs-btn-focus-shadow-rgb:197,139,52;--bs-btn-active-color:#000;--bs-btn-active-bg:#edb564;--bs-btn-active-border-color:#eaac50;--bs-btn-active-shadow:inset 0 3px 5px rgba(0, 0, 0, 0.125);--bs-btn-disabled-color:#000;--bs-btn-disabled-bg:#e8a33d;--bs-btn-disabled-border-color:#e8a33d}
.btn-danger{--bs-btn-color:#fff;--bs-btn-bg:#c83c3c;--bs-btn-border-color:#c83c3c;--bs-btn-hover-color:#fff;--bs-btn-hover-bg:#aa3333;--bs-btn-hover-border-color:#a03030;--bs-btn-focus-shadow-rgb:208,89,89;--bs-btn-active-color:#fff;--bs-btn-active-bg:#a03030;--bs-btn-active-border-color:#962d2d;--bs-btn-active-shadow:inset 0 3px 5px rgba(0, 0, 0, 0.125);--bs-btn-disabled-color:#fff;--bs-btn-disabled-bg:#c83c3c;--bs-btn-disabled-border-color:#c83c3c}
.btn-light{--bs-btn-color:#000;--bs-btn-bg:rgb(245, 245, 245);--bs-btn-border-color:rgb(245, 245, 245);--bs-btn-hover-color:#000;--bs-btn-hover-bg:#d0d0d0;--bs-btn-hover-border-color:#c4c4c4;--bs-btn-focus-shadow-rgb:208,208,208;--bs-btn-active-color:#000;--bs-btn-active-bg:#c4c4c4;--bs-btn-active-border-color:#b8b8b8;--bs-btn-active-shadow:inset 0 3px 5px rgba(0, 0, 0, 0.125);--bs-btn-disabled-color:#000;--bs-btn-disabled-bg:rgb(245, 245, 245);--bs-btn-disabled-border-color:rgb(245, 245, 245)}
.btn-default{--bs-btn-color:#000;--bs-btn-bg:rgb(245, 245, 245);--bs-btn-border-color:rgb(245, 245, 245);--bs-btn-hover-color:#000;--bs-btn-hover-bg:#f7f7f7;--bs-btn-hover-border-color:#f6f6f6;--bs-btn-focus-shadow-rgb:208,208,208;--bs-btn-active-color:#000;--bs-btn-active-bg:#f7f7f7;--bs-btn-active-border-color:#f6f6f6;--bs-btn-active-shadow:inset 0 3px 5px rgba(0, 0, 0, 0.125);--bs-btn-disabled-color:#000;--bs-btn-disabled-bg:rgb(245, 245, 245);--bs-btn-disabled-border-color:rgb(245, 245, 245)}
Updated by Garvin Hicking 5 months ago
- Status changed from New to Needs Feedback
The PHP code of typo3/sysext/backend/Classes/Template/Components/Buttons/LinkButton.php
uses this:
'class' => 'btn btn-sm btn-default ' . $this->getClasses(),
so indeed the 'btn-default' cannot be removed. However, afaics this is intention, to be sure that a link from LinkButton is always rendered as a btn-default, to ensure that the look of all buttons there is "default". Backend modules then use javascript to dynamically modify the buttons in case of additional attribution (for example on validation).
If we would remove btn-default
from the stringlist in case either
- setClasses() has been used at all
- or if setClasses() has been used with a distinct set of one of a list of classnames (btn-warning, btn-danger, btn-light)
then it could happen that the buttons are no longer displayed as originally implemented, causing sideffects.
Could you maybe elaborate in which case you would already initially (without any JS interaction) want to display non-default buttons in the UI, what they should look like?
Updated by Netresearch DTT GmbH 5 months ago
It can be the case that btn-default is set, but the passed class should also be taken into account. Hence my suspicion that the order of the class definitions in the CSS is the wrong way round, since btn-default is last here (or before btn-warning) and thus overwrites the others, even though "default" suggests that it is the standard and the rest inherits from it (that's what I would expect).
But that's no longer the case, since I now set my own class and use the CSS for "btn-warning" in it and put the CSS into the backend via the PageRenderer. It's not really nice, but it can't be done any better.
Updated by Garvin Hicking 5 months ago
Thanks for the feedback. Actually the order of CSS elements comes directly from bootstrap, so we ourselves can't even change it - and I suppose bootstrap has their reasoning on why the 'default' class is defined as last one (probably because they dictate a button having the default class should always appear default and not as something else).
So our only chance to adjust this would be to remove 'btn-default' with the methods I described, which feels very unstable.
How do you feel how to proceed with this? Is using your own CSS something you feel okay to close this issue with?
Updated by Netresearch DTT GmbH 5 months ago
Yes, I've solved it that way now. The case can be closed as far as I'm concerned.
Updated by Garvin Hicking 5 months ago
- Status changed from Needs Feedback to Closed
Thanks a lot! ☺️