Currently, I use CSS specificity to override plugin styles. I prefer this for editing the plugin as it makes less headaches when you update.
It would be nice if my style sheet loaded after the plugins, so that I only have to be as specific, not more. This would make my stylesheets much prettier.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
As you suggest, the most elegant approach is when your CSS overrides are loaded after the CSS injected by the plugins. This is quite easy to achieve – you just need to make sure that your header.php calls wp_head() before it references your style sheet:
<head>
<!-- all the usual preamble stuff goes here -->
<?php wp_head(); ?>
<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" rel="nofollow noreferrer noopener" type="text/css" />
</head>
Method 2
There are several ways plugins can handle CSS.
- best case: plugin queues CSS and provides option to disable it (disable it, copy CSS code to your stylesheet and be happy);
- good case: plugins hooks function that queues style (unhook function, hook your own with mods if needed);
- usual case: plugin queues CSS directly. See How to dequeue a script? (applies to styles as well). Short version – there will be dequeue function in future WP release, for now could work around with
wp_deregister_* - bad case: plugin echoes CSS among bunch of other things. Case by case…
Overall in my opinion it is better and easier to disable separate stylesheets and incorporate them in your own to minimize issues and improve performance (less files to fetch).
Method 3
Another quite elegant way is to use specificity of CSS.
So if the css of the plugin says:
div.product div.images img {
......
}
you define in your css:
body div.product div.images img {
......
}
Also see the answer of Michael Rader for a similar question.
Method 4
I save a copy of the “not willing” plugin CSS to the theme folder and import it into the theme css by adding
@import url('name-of-the-plugin-css.css');
to it (replacing, of course, the name of the .css by the one I’m injecting). Then I modify the css copy in the theme folder and save it to server as I do for the other files. Oh, yes, sometimes it may be necessary to “nail” the IDs or classes altered by assigning them an “!important”.
I do not know if this is state of the art, but it does no harm and works just fine.
Method 5
I ended up using !important for my custom css and that override the styling for the plugin that I was having trouble with. The developer of the plugin was using !important throughout the plugin css and that is why I could not overwrite it without !important.
body {
font-family: "Open Sans", Arial, sans-serif !important;
font-weight: 300 !important;
}
Method 6
To override the css of plugin, that was already using specificity and !important, I used the id to override the classes. This did clean up my code a bit. Of course, it too is not a perfect solution in that it only works when if there are id’s assigned to elements as well as classes.
You could also use attribute selectors in theory. However, I have yet to put that theory to test.
Method 7
To override the css of plugin, that was already using specificity and !important, I used the id to override the classes. This did clean up my code a bit. Of course, it too is not a perfect solution in that it only works when if there are id’s assigned to elements as well as classes.
You could also use attribute selectors in theory. However, I have yet to put that theory to test.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0