I noticed in developing a staging site on 1.5 beta that it seems the Global Theme Styles > Colours overrides the Button (and possibly other elements). In my example, I have the following colours set in Theme Styles:
My button is set to “Secondary” and so I expect the white background since that’s the background colour set and I’d expect it to override the Global Colours section… but here’s how it looks on the frontend (note it’s picking up the secondary colour set in the Global Colours section instead of off the Secondary Button style):
Basically it seems the Colours in Theme Styles is overriding the Background Colours I set on the Button Element Theme Styles section, when I’d expect it to be the other way around. If I remove the Secondary global colour then it loads as expected on the Button Element secondary styles. This seems like a bug but please let me know if I’m perhaps doing something wrong here too. Thank you!
We will deprecate the theme style colors (they are back from the early days when there were no color palettes) in one of the next versions, so it’s best to avoid using them anymore.
It looks like this is still an issue in 1.9.4, well over a year since the first report was made.
Side question: It seems like Theme Styles has had a number of issues in the past (and present) and excludes so many possible CSS options too from some elements and whatnot (not to mention just missing general site-wide CSS which should be there instead of the Bricks Settings IMO but that’s a separate topic), so makes me wonder…
is it perhaps best for users to just drop their use of the Theme Styles functionality completely on new site builds for example or is it still best practice / recommend to use Theme Styles functionality?
will it be removed completely in 2.0 perhaps, or is it just the theme style colours section and references from elements like button to it that will be removed one day? Curious what changes are coming up that will finally fix this for users.
I assume Theme Styles is still recommended for use as it seems that the newer Bricksbuilder.io website design uses theme styles, right?
If there’s any ETA on when this will be fixed, I’d appreciate it as it’s been a very long time now for “one of the next versions” to still apply. Thanks in advance Bricks team.
Hi Dustin,
As you should know by now, we almost never call ETAs.
My statement at the time was based on information I had at the time. The task was created and still exists - I can’t say why it hasn’t been edited yet, but I don’t question every decision made by our developers, but assume that they have good reasons for doing so.
I don’t understand where you got these ideas from. The theme styles are still intended for general, global styles, but nobody is forcing you to use them. You can just as well write global styles in the Bricks settings or use an external stylesheet for your global styles - just as you like. And yes, of course, we use the theme styles on bricksbuilder.io
With this, I really don’t understand how you came up with it. This report (and my answer from back then) is only about the theme style colors - nothing more and nothing less.
My thought process was that between this defect (that’s still an open defect 1.5 years later!); the number of open and past defects as if it wasn’t given enough time/attention for testing with; how many properties have never been added to it that people have requested be added; and combining all of that with rumblings from some respected power users in FB groups about how they believe Theme Styles is leftover cruft from a time before Bricks has CSS classes and don’t use it anymore, it seemed like it was maybe going away or else going to be overhauled.
I hope you can appreciate why I asked those questions even if they seemed out of left field. Since the defect has existed for so incredibly long, it’s not a stretch to think that it’s maybe not addressed because it’s part of a larger system overhaul possibly to theme styles. I’m very happy to hear it’s still alive and well then, hopefully Bricks will now finally improve this functionality and more importantly fix the outstanding bugs with it sooner than later.
Sometimes questioning is necessary to make sure Development doesn’t overlook things. But yes I am aware that you don’t like to give out dates and that’s fine, but let’s also be understanding here please… bugs have been overlooked before and can always be missed / fall through the cracks of whatever software or processes they’re added in. It’s a very fair ask 1.5 years later to make sure this is still on the roadmap for fixing, and whether it’s perhaps shorter term or longer term (i.e. pre-2.0 or after 2.0).
Ultimately I am wanting to make sure this hasn’t fallen through the cracks as has happened from time to time, I hope you can appreciate that. If you are certain this remains on the bug/defect tracker, then that’s good to hear.
PS - it might be a good idea for the Bricks team where forum posts in the WIP state that haven’t been active for more than 6-9 months for example receive a brief proactive update from the team even just to say it’s still being worked on or even to ask if it’s still an issue (if it’s hard one to reproduce for example and so many changes have happened since that could affect the original report). I believe doing something like this would serve a few useful purposes: 1) Keeping paying users in the loop so they’re not feeling neglected/overlooked, and 2) Act as a second verification for Bricks team to ensure the associated defect ticket exists in the system and has been filed properly with all the necessary tags, etc. to prevent it from being overlooked. 3) Improve user satisfaction. It’s always better to be proactive than reactive. Cc’ @Thomas to consider this feedback too.
Thanks in advance Bricks team.