Update: When I view it on the front-end as a non-admin, the background has changed, but when I view it on the back-end as an admin, it looks exactly the same, despite clearing the caches. Any ideas?
For non-logged in users the current rule that is in effect is:
body.page.page-id-4637 {
background-color: #FFFFFF !important;
}
If you get something else when logged in, there must be a different rule that takes precedence due to what order the CSS rules occur in. If you have any kind of CSS optimization taking place, this can be the cause of different precedence.
To override whatever might be taking precedence, instead of Additional CSS, try outputting the above rule in its own <style> block through the “wp_head” action hook. Add your callback using a very large $priority arg to help ensure your callback is called after all others, giving it a better chance of having precedence.
Thank you so much for the insight! I bet you’re right that there are different rules for logged in users and non-logged in users.
I’m embarrassed to admit my knowledge of WordPress is lacking in regards to implementing your instructions. From Google, I can probably figure out how to make my own <style> block and use the wp_head hook. I’m not familiar with using the $priority argument. Can you please recommend a reference for me to read about this? Thank you very much for your time and patience.
Nothing to be embarrassed about, not everyone desires to be a WP coder. I applaud your willingness to try.
A general overview of using action hooks: https://developer.wordpress.org/plugins/hooks/actions/
Doc page for the “wp_head” hook: https://developer.wordpress.org/reference/hooks/wp_head/
The last is not too useful in itself, but the examples near the bottom might be useful. The main reason for this particular hook is it’s usually the last one to fire before the body tag is output.
Before embarking on a coding adventure, you should identify exactly which rule is preventing the desired background from appearing. In order to best override it you’ll want to use the same or more specific CSS selectors. It might be better to prevent the offending rule from occurring on the page than to try to override it. But to do that you’d need to determine where it’s coming from.
Thank you for the kind words and advice.
I found my current theme’s (blockbooster) style.css file, and when I search for “log”, the only relevant code that exists is
body.logged-in .wp-block-group.blockbooster-sticky-menu.sticky-menu-enabled { top: 30px; }
No other code is specified for logged-in users, but I do see other code indicating the primary color should be used as the background for blocks mostly related to woocommerce and contact forms.
I’m surprised no other code in that file mentions specifics for logged-in users. Would that be in another file?
Thank you so much!
There could be any number of files. Also, “log” might not be part of the pertinent selector. Use your browser’s element inspector tool to help you learn what rules are in effect for any particular element. The tool will also tell you in which file the rule resides. Right click on a blank part of the page, then select “inspect” (exact wording might vary by browser). The tool will appear with the clicked element highlighted and its applicable CSS displayed in the sidebar. It may not be the right element with the undesired background color though. You may need to work your way up through the DOM to find the right element. Or directly locate the body element which is a likely contender for aberrant CSS.
Thank you so much for your help! I had no idea the inspect element even existed. I was able to temporarily select the whole page when I selected this HTML code:
<div class=”editor-styles-wrapper block-editor-writing-flow” tabindex=”0″ style=”height: 100%; width: 100%;” data-is-drop-zone=”true”>
Then, I looked at the code to the right of it in the CSS (?) pane, and saw by toggling this line of code, the background color changed:
.editor-styles-wrapper{
background-color: #00000;
….}
I looked online, and it sounds like I have to copy/paste this .editor-styles-wrapper{…} code to the additional CSS? At first, it seemed like I needed to download a Chrome extension to be able to save the changes I made in the inspector element, but I think I have to copy/paste this new CSS code into my additional CSS box on my homepage, and somehow indicate which page I’m trying to change. Is that correct? Thank you very much for your patience and help!
I’ve always copy/pasted useful CSS from the inspector to Additional CSS. I don’t see much point in a formal extension that lets us save changes. Apparently others find such a tool useful 🙂
You may need to alter the CSS selectors in order to target a particular page. Using only .editor-styles-wrapper will affect all instances of that class on any page. To target only that one linked page you could instead use .page-id-4637 .editor-styles-wrapper selectors. (the page-id class comes from the page’s body element)
Typically any CSS in Additional CSS will override any equivalent existing CSS because Additional CSS is loaded after all other external .css files. Be aware though that browsers often aggressively cache CSS and altering CSS on your server may not be reflected in your browser until you flush its local cache.
Darn, I was hoping you wouldn’t say that. I’ve tried various variations of this CSS code, without successful results:
.page-id-4637 .editor-styles-wrapper {
background-color: #f2f5fb ;
}
You’re right in that without the “.page-id-4637”, the rest of my website begins to change color. I’ve tried other similar lines of code like .page-id-4637.editor-styles-wrapper, .editor-styles-wrapper.page-id-4637, and .editor-styles-wrapper .page-id-4637, but this page stubbornly refuses to change colors. Thank you again for your continued patience and advice.
.editor-styles-wrapper does not appear to be the correct selector. The rule currently in effect is:
body.page.page-id-4637 {
background-color: #f2f5fb !important;
}
If color #f2f5fb is the one you want, it’s working! If you’re not seeing that color, the old CSS has likely been cached by your browser. If you clear your browser cache and reload the page you should see the right color.
When I delete the rule
body.page-id-4637 {
background-color: #f2f5fb !important; }
the public page does change to color #f2f5fb as desired due to the .editor-styles-wrapper code, however, the admin view remains the same, even after clearing my cache multiple times from different plugins.
I can change the public view of my pages no problem, but my admin view remains stuck. My only remaining guesses are that I cannot clear the admin cache properly, or perhaps there is code enforcing a different background (and other features outside the scope of this question) for the admin than for the public. Thank you again for the continued help and patience, but it appears I’m at a dead end.
Editor styling is independent of front end styling. It’s normally the responsibility of your theme to coordinate the two views. But if you add custom front end CSS it becomes your responsibility to coordinate if you’re so inclined. This would involve adding appropriate admin styling as well. It’s doable, but a bit involved.
My suggestion of adding custom CSS the way I did is really a bit of a cheat. It works better for ad hoc front end styling than for proper coordination with the editor. If you require editor coordination in a block theme, the proper approach is outlined in this topic reply.
Thank you very much for all of the info and help! I’ll give that link a try.
