Can someone tell me what goes in the "Additional CSS classes" field in the Style Settings section of the Configure block window?
Is it
#1. CSS code defining the class
or
#2. only the name of the class which I should define in a CSS file associated with the new theme (just a duplicate of the Basis theme) I'm using.
And if the answer is #2, in which of the default css files that come with the theme should I define the class?
Thanks.
#2
You would just put the name of the class there. You would define the class in the css files for your theme.
You can define the class anywhere, just make sure that whichever file you use is loaded by the theme (check the .info file for your theme). Or you can use an existing class in that field.
If you are using the Bootstrap theme (for example), Bootstrap defines many classes that can be used in this "additional CSS classes" field without giving them any additional definition.
Thanks for your quick reply.
If I understand you correctly, if it says in the theme .info file:
; Add theme CSS files
stylesheets[all][] = css/base.css
stylesheets[all][] = css/layout.css
stylesheets[all][] = css/component/small-text-components.css...
That means that base.css, in the css directory, is loaded by the theme.
So if I add this class to base.css and save
.searchpink {
background-color: pink;
}
And then type searchpink into the Additional CSS classes field and click "Update Block" , the block should have a pink background.
But that's not what happened, in spite of refreshing the browser, turning on/off the MAMP server, ensuring the theme is the default, looking for theme update/refresh options and checking everything 3 times. The background is still white. Did I misunderstand or am I doing something wrong?
Thanks.
So, in theory, what you did should work.
Here are a few things to try, if you have not tried these already.
1) You didn't mentioned clearing the Backdrop cache. This is frequently a problem when theming (it's frequently a problem with anything I do). Always be sure to clear the Backdrop cache. Forgive me if this is obvious to you.
- admin/config/development/performance
2) When theming, it's good to turn off aggregation - admin/config/development/performance
3) Hopefully you know how to "inspect element." Use this to troubleshoot problem. From this you can tell if your classes have been applied? Do they have the styling you expect? Was your styling overridden for some reason? Is the stylesheet loading as expected?
Maybe a little off-topic, but there's a utility module (Utility CSS) that seems to provide autocompletion for that layout form field, based on the active theme.
I didn't use it yet, but it seems to be a good solution for less technical users, so they don't have to remember the css class names.
Remembering css class names doesn't strike me as an especially technical issue.
The issue here is that something does not work as advertised. I've only been playing around with this CMS for a couple of days and it's not an encouraging sign. I expect I'd figure out an alternative to using the class field to change the block background, if I poked around long enough. The issue for me is whether it's worth the time.
Maybe I'll just go back to doing everything in PHP.
I expect I'd figure out an alternative to using the class field to change the block background
That's an easy task with a contrib module: https://backdropcms.org/project/block_background_color
Or if you need something different, search here:
https://backdropcms.org/modules?s=background
No need for php code. But, of course, if you prefer php code, use that instead.
Yeah, maybe a PHP framework is what I really need. There are too many choices and too much abstraction in Backdrop ( and never mind Drupal 8) for my purposes.
Thanks.
Hey, that sound so me, like you don't want a web CMS anyway. ;-)
Happy coding.
The issue here is that something does not work as advertised. I've only been playing around with this CMS for a couple of days and it's not an encouraging sign. I expect I'd figure out an alternative to using the class field to change the block background, if I poked around long enough. The issue for me is whether it's worth the time.
Applying CSS classes works as advertised, but as mentioned above, you are most likely experiencing a cache issue.
If you add a new CSS definition to a stylesheet that has previously been aggregated, you will need to clear the CSS cache (or disable aggregation). If you add an entirely new stylesheet into the theme (css/component/small-text-components.css) you will also need to rebuild the theme registry to make sure that new stylesheet gets picked up, too. Flushing all caches includes rebuilding the theme registry.
refreshing the browser, turning on/off the MAMP server, ensuring the theme is the default, looking for theme update/refresh options and checking everything 3 times.
Unfortunately, none of these things you tried would flush the CSS cache, and only turning on/off the MAMP server would rebuild the theme registry.
You to raise a great point here though, that someone new to Backdrop will look for theme update/refresh options, and we should make it easier to find the link to flush the CSS and Javascript cache. I am going to open an issue recommending we add a button for this onto the appearance page.
The issue for me is whether it's worth the time... Maybe I'll just go back to doing everything in PHP.
Backdrop is intended save you time over coding your own:
If you don't need any of these things and find that Backdrop is taking more time than coding it yourself in PHP - then Backdrop is not the right tool for your project.
However, if you find yourself needing any of these things in the future, I'd encourage you to come back and try it again. Backdrop also evolves quickly, and maybe we'll get that CSS/JS cache clear button up before the next time you give it a try :)
Here's the issue for the new button, incase anyone here wants to weigh in: https://github.com/backdrop/backdrop-issues/issues/4289
Should we also improve the description text on the Additional CSS classes field so that it's clear that the class name goes in there, and not the CSS code itself? I'll create an issue for that one too.
Thanks for sharing your thoughts.
But the issue isn't making a cache clear button available, the issue is that I would never have guessed that a two-day old, barely used, almost-empty installation of Backdrop would require a cache clear simply to display the results of a reference to a css file.
And as soon as someone suggested I clear the cache I did that. It did not fix the issue.
I coincidentally watched that Andrew Sorkin movie about Jobs on Netflix the other day and it stressed the point that one of the reasons the Mac became so popular with consumers was because it was not infinitely customizable - it was focused on helping people get stuff done, not catering to computer hobbyists and tinkerers.
I suspect the Backdrop UI reflects the atomized complexity of its content management paradigm more than the technology requires because the people who work on it are strongly influenced by their deep knowledge of that paradigm and it all seems perfectly intuitive to them. But clearing a cache to display a style sheet change doesn't strike me as intuitive. Refreshing the browser, yes.
Perhaps there could be a fork from Backdrop that focuses on limiting customizability in favor of the top 50 tasks users wish to perform in order to manage content.
It's not about the age of the site. If CSS and JS aggregation are enabled then you need to rebuild them in order to get any CSS changes to take affect.
I've tested this out again to refresh my memory. Adding and removing a class on a block doesn't require a cache clear. It's only the change to the CSS, and then only if CSS aggregation is enabled.
Backdrop (and Drupal before this) can automatically optimize external resources like CSS and JavaScript, which can reduce both the size and number of requests made to your website. CSS files can be aggregated and compressed into a single file, while JavaScript files are aggregated (but not compressed). These optional optimizations may reduce server load, bandwidth requirements, and page loading times.
When I added my new theme, I followed these instructions:
https://backdropcms.org/news/build-sub-theme-basis-default-frontend-them...
I originally thought I should create a sub-theme before I realized I could just copy and rename an existing theme.
Anyway, I followed the instructions - the first thing I did was turn off CSS/JS aggregation.
I realize the tendency is to assume that issues are likely caused by "non-technical" users but that is not what appears to have happened, at least in this case.
So my next question is - has anybody here managed to get this to work - to call a CSS class from the additional CSS classes field in the Configure Block window?
Yes, I've done this before. In the screenshot above, you can see that I successfully added a class this way. However, there are MANY things that can go wrong in terms of getting your styles applied properly, even if the class is there as expected. Here are a few of the many possible mistakes that I've made in the past in a similar situation:
Have you checked the inspector to see your class is being added and whether or not your CSS rules are being applied?
Are other CSS changes taking effect?
Sometimes when I can't get CSS to behave properly, I add something like this to my css:
p { border: 5px solid blue}.
If I get big blue lines around every paragraph, I know that my css is loading properly and the problem is more specific. If I don't get those blue borders, then my problem is that Backdrop is not loading the correct CSS file and I need to figure out why.
If you can provide answers to the above questions, we might be able to provide additional debugging tips.
Yes a lot can go wrong which is why I decided to try to keep things as simple as possible, use only the simplest CSS code, in only a development environment, using a copied standard theme etc. And of course during this ongoing discussion I've been checking and rechecking to make sure I didn't just do something dumb.
Here are the steps I took after reading existing documentation and receiving advice in this forum (thanks to everybody who offered advice.)
From my perspective, there are lot of steps to change the appearance of an individual web site component compared to every other web site I've worked with. The usual process is:
Wouldn't it be possible to allow Admin users to access WYSIWYG controls for each component? That already exists for Appearance ->Theme -> Settings so why not on a component basis?
Using Inspect Element in Chrome I see the pink background tag is mentioned but doesn't appear to have any effect. And a PHP document is involved, block.tpl.php - I'm not sure what that's all about.
It seems like there are a lot of steps needed to do something that is so simple in the traditional file/directory system.
There is already a WYSIWYG screen for the theme at Appearance/Theme/Settings. Couldn't there be something like that for individual blocks?
The block.tpl.php is the template that Backdrop is using to generate the markup for your block. You can override this template, but I don't think you need that yet. The tpl.php files only show up in the markup if you turn on "theme debug." I always turn this on while theming, it's very helpful.
What the above screen shot proves is that Backdrop is adding the class as expected. The problem is that the CSS rule from your theme is not being applied. That could be for any of the reasons I listed above.
The next step is to determine if the stylesheet from your sub-theme is loading. Are you able to make ANY css changes that appear on your site?
When you click on any element in the inspector, you should be able to see any css rules applied to it in the inspector. Look between "Styles" and "Console." If you can't find your css rule in here, then it's not being applied and you need to figure out why. Again, have you successfully applied ANY css changes?
You still have something like the following in your theme, right?
.background-color {
background-color: pink;
}This seems like an awful lot of work, especially when it's possible to make changes to the over-all template through WYSIWYG without the necessity of flushing any caches. Why can't the same WYSIWYG functionality be available for blocks?
I agree, but it is the way it is. We have 100's of things we'd like Backdrop CMS to do and many of us are spending a great deal of time trying to make it happen. But, we do this as volunteers, in addition to providing help in the forum for users like yourself.
Since you have very strong feelings about what Backdrop CMS SHOULD do, I'd like to invite you to give us a hand in making these things happen. Rather than spending your time telling us what we didn't volunteer to make available for you for free already.
Building sites with Backdrop CMS is not trivial. It will require some effort on your part.
My final piece of advice would be to look at either of these modules (provided by volunteers):
https://backdropcms.org/project/block_background_color
https://backdropcms.org/project/configurable_block_style
But, you will need to invest some effort in learning how to use them. Good luck.
EDIT: Here is link to a video on Configurable Block Style module:
https://youtu.be/WfuUIVzjQUg
I wonder if you were using the color module. I just ran into a situation like yours, where I was unable to get a new css rule to take effect and it turns out that the color module was the culprit.
I had to resave my color settings in the theme in order to get the CSS change to take effect.
This is really weird and hard to figure out. I've opened an issue to try and fix this, because I can see new users getting terribly frustrated by it.
https://github.com/backdrop/backdrop-issues/issues/4295
Would love other ideas on how to solve this problem.
Hello, I am also new to BackdropCMS, and I have used the CSS injector module to customize the blocks without problems.
regards
Hello, I realize this is long after this issue, but maybe it will help someone else having similar issues.
I had a problem with not being able to set the background color for the entire custom block, which was an image floated next to body text.
No matter how I targeted the block with css, the image kept extending out of the block color at certain screen widths.
Finally solved it by:
1) Making sure that the block was set to "use theme colors" which I defined in the custom CSS file. (It already was, so made no change for me).
2) Under style settings in the block configuration and directly under the box to enter custom css, check the Content Container box to:
"Add div with container class to align text with other regions."
This solved the issues I had.
(I also have the configurable block style module enabled.)
Maybe a little off-topic, but there's a utility module (Utility CSS) that seems to provide autocompletion for that layout form field, based on the active theme.
I didn't use it yet, but it seems to be a good solution for less technical users, so they don't have to remember the css class names.