Digital experiences for all disciplines
New Landing › How can we help? › Cardinal › Cardinal: Child theme CSS vs Admin custom CSS
New Landing › How can we help? › Cardinal › Cardinal: Child theme CSS vs Admin custom CSS
- This topic has 29 replies, 3 voices, and was last updated 9 years by Kyle – SUPPORT.
-
Posted in: Cardinal
-
September 12, 2014 at 9:39 am #109995
Hey,
I am trying to tidy my site up a little bit; one of the first things I am trying to do is to move all my custom css rules (over 1200 lines) from the custom css box in the Cardinal admin section to my child themes css file.
The issue is this; lots of my rules stop working after moving to the child theme css, but some do work.
It seems as though the custom admin css box takes on more importance and as such, all of the rules in it are reflected on the front end; conversely, when you cut and copy those rules into the child theme css file, the rules do not take on the same importance and as such, are in a lot of cases overwritten and rendered useless on the front end.
In the next post I will show you a few screen-shots that give a good example of the issue and my login details.
Thanks.
September 12, 2014 at 9:43 am #110002This reply has been marked as private.September 12, 2014 at 10:01 am #110015Hi
Yes that’s correct, css works on the order it is loaded. The theme options custom css is loaded last (after the color customiser styles) therefore it will overwrite anything. However the child theme css is loaded before the color customiser styles, therefore it will not overwrite the styles unless you add !important on the end.
– Kyle
September 12, 2014 at 10:05 am #110018Hmm, is that the optimal implementation?
I was always under the impression that the child theme CSS file should be the optimal way to style your website – having to put !important after each rule to make sure it works does not seem to align with that theory?.
September 12, 2014 at 10:10 am #110021It’s not possible to do it any other way, the styles from the theme options and color customiser are dynamic, therefore they have to be applied using php, and imported into the head section. Where as the child theme style.css is a file.
The only things you will need to apply !important for is things like font sizes and colors, as they are part of the dynamic css (chosen in theme options)
– Kyle
September 12, 2014 at 10:18 am #110024I understand.
Also effects other things apart from font sizes and colors.
In my screen-shots example, the following rule gets overwritten in the child theme css unless the !important declaration is added.
.product-type-booking.product .cart-overlay .shop-actions > a, .virtual.product .cart-overlay .shop-actions > a { width: 132px; }
I assume there is no way on hiding the custom admin css rules in the view source of a page?
September 12, 2014 at 10:21 am #110025Not sure about that one.
And no I’m afraid not
– Kyle
September 12, 2014 at 2:33 pm #110153Ok thanks anyway.
September 12, 2014 at 2:45 pm #110158No problem
November 10, 2014 at 12:53 pm #126957Hi,
Re-opening this topic as I am struggling to comprehend how the current setup is optimal.
Here is what I am trying to do:
I have a lot of custom css rules for Cardinal – best practice in WordPress is to setup a child theme stylesheet and load the rules that way. That is what I have done.
However, with Cardinal, that does not work well at all, i.e.
#1. A lot of the time, the rules in the child theme stylesheet do not work unless you use the !important declaration. It’s not css best practice to be using !important the whole time.
#2. In some cases, using the !important declaration does not work. For example, the customizer outputs the following code by default when Cardinal is installed:
.article-share label { background-color: #fe504f!important; color: #ffffff!important; }
Because the child theme stylesheet is loaded before the customizer rules are output, it is not possible to change that rule in the child theme.
#3. Putting all the rules in Cardinals custom css box resolves this issue but that is not the optimal way imo. – 1. It slows down the loading on the admin page. 2. You may not want your client to see all those css rules and/or change any of them. 3. Its easier to move that child theme stylesheet across different websites. 4. If something goes wrong with the theme and all the options are wiped, that won’t be a major issue if the rules are stored in the stylesheet. 5. It easier to manage the stylesheet with a huge amount of rules in an off-line editor. Copy and pasting back and forth between the custom css box is not ideal. 6. Finally, performance wise, I would guess that loading 2000 or so lines of custom code in an external stylesheet is better than loading it dynamically on every page?
==============================
What are the solutions to this?
1. Is it possible to stop the customizer from outputting its rules using !important – thus allowing all rules to be changed in the child theme?
2. Would it be possible to load the child theme css file after the customizer rules are output in the header?. Similar to the above, that would solve the !important issue.
November 10, 2014 at 1:07 pm #126966I’ll forward this to Ed as he can better explain it to you
– Kyle
November 10, 2014 at 1:23 pm #126972Ok thanks.
November 10, 2014 at 5:48 pm #127096Hi Anthony,
Child theme css is optimal in very basic themes, but with advanced themes it becomes increasingly more difficult.
The main issues occur with plugins such as WooCommerce, where we have to introduce !important to override their colour styling for example.
There are various methods for outputting the dynamic css, however outputting to the source is by far the best method of the bunch – we’ve tried the others and far too many issues occur because of those other methods. It may not be the prettiest, but it’s by far the quickest.
If you have that many lines, it may be worth putting them in a css file, and then including it to the page with a custom wp_enqueue_styles function, through your child theme – over all being in the custom css output.
– Ed
November 10, 2014 at 6:37 pm #127112Hi Ed
Thanks for the feedback.
Can you elaborate a bit further on that last paragraph?.
I have around 2000 lines of custom css code. Managing that in the custom css box is a nightmare.
With your suggestion, would all the styles be loaded after the customizer code and the custom css code?
Would this not introduce a slight delay in the css code being applied… I.e. Load the page and you can see the layouts before the css you want is applied?
November 10, 2014 at 6:44 pm #127116No, as it will be loaded in the head of the page, so before content is loaded. I’m hoping it will be loaded after the plugin css files, but we may need to tweak the code. Try this:
function custom_style_sheet() { wp_enqueue_style( 'custom-styling', get_stylesheet_directory_uri() . '/custom.css' ); } add_action('wp_enqueue_scripts', 'custom_style_sheet', 100);
Then you can keep your custom css there.
– Ed
-
Posted in: Cardinal
You must be logged in and have valid license to reply to this topic.