Best way to overide plugin CSS?

2 Views

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.

Post Views: 2

Related posts

Leave a Reply

7 comments

  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'); ?>" type="text/css" />
</head>

  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).

  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.

  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;    
}

  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.

  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.