The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
It's not possible to control the classes of a button if its text matches with any of those listed in _bootstrap_colorize_button(). Its classes will be changed without any consideration whether the button already has classes added. New classes might override appearance of a button. For example btn-success will override btn-primary.
Proposed resolution
Check if the button already has any btn-... classes applying colorization or provide alter hooks to control colorization process.
Remaining tasks
Create a patch and discuss if its approach is good.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | bootstrap-do-not-colorize-2176521-5.patch | 574 bytes | balintbrews |
| #1 | bootstrap-do-not-colorize-2176521-1.patch | 621 bytes | balintbrews |
Comments
Comment #1
balintbrewsComment #2
markhalliwellI do not see how bootstrap_preprocess_button() "removes" classes, it only ever adds them (ie: []), if a class is returned by _bootstrap_colorize_button(). Please explain to me what it is you are attempting to do and it's use case.
Comment #3
bcostlow commentedI'd guess balintk has links that already have btn classes set before they hit the theme layer. Then _bootstrap_colorize_button() is applying additional classes, which are overriding the initial classes because they come later in the class array.
It is nice to have bootstrap automatically colorize and iconize local items but both of those features probably should have hook_alters to allow themers to set these up as needed. I don't think that detecting for classes is the way to go.
I've been getting around this by overriding theme_menu_local_(tasks|actions) in my subtheme, but it would be much nicer to have hooks to control those features.
Comment #4
siliconmind commentedSame here.
_bootstrap_colorize_button()is driving me nuts as it adds classes to the buttons that override previously added classes. Classes are not overwritten, but newly added classes might override those added earlier. For example if I add btn-primary to the button, and the_bootstrap_colorize_button()detects that the button text is "Create..." then it will add btn-success class even if I already added btn-primary. Now the btn-success will override my btn-primary appearance and render the button in different color than I wanted.Providing alter hook is nice, but you could also use the same mechanism as inside
bootstrap_button(). Inside that function if no btn-... class is present then btn-default is added. So_bootstrap_colorize_button()could work the same way (if you don't want alter hooks) - it could add new btn-... class only if there is no btn-... class already.Id say it's a bug, not a feature request, because this behavior prevents users from styling buttons the way they want.
Comment #5
balintbrewsI've rerolled the patch, so that it still applies.
While it's definitely nice that there are automatic class assignments built into the theme, I still think it should not make any actions when there are classes already present. It should instead respect it, and get out of the developers' way.
Introducing an alter hook would force us to write more code, just because the theme makes assumptions and aggressively applies them.
Comment #6
mfernea commentedAs I see it, since "c72a302" (2014-02-17), the code no longer adds classes if one of the standard "btn-..." classes is present.
So this issue is only present in 7.x-3.0.
Comment #7
markhalliwellCorrect. This was indeed fixed by c72a302.
It was a direct commit follow-up (unfortunately without an actual issue, should have used this one) to the related issues.
Comment #8
andre.morales commentedThe problem continues. Could someone re apply that patch?
Comment #9
markhalliwellI cannot fix 7.x-3.0. Releases are set in stone, which is why we have new versions. You will have to apply the patch yourself if you wish to add support to 7.x-3.0.