Css style

Why Your Custom CSS Isn’t Working in WordPress and How to Fix It

Sometimes you may find that when you add custom CSS to your website, it just doesn’t seem to be applied correctly. There are a lot of reasons why this could be the case, but the main one is the heart of the “C” in the full name of CSS (“Cascading Style Sheets”) and the way WordPress enqueues your style sheets. waiting on your site.

We’ll walk through these basics so you understand what’s going on, how to diagnose the problem, and how to fix it.

What is happening

Here is an example. Let’s say you have a child theme and you have a plugin that has its own stylesheet. For this example, let’s call it “Reaction Buttons”. If you were to activate this plugin and then try to override your child theme’s styles, you’ll notice that it just doesn’t work.

There is a technical explanation: the plugin is enqueuing its corresponding stylesheet with the wrong action. But the result is that the stylesheet is added later in your page

thus taking precedence over any style that precedes it.

You see, this is the “Cascading” part of “Cascading Style Sheets”, aka CSS. Here is another example. Let’s say I want to make all my H2 elements red and all my P elements blue. I could do this:

H2 {color: red;}
p {color: blue;}

But if I then style the H2 to be orange, later in the same stylesheet, then ALL of my H2s will be orange. Like that:

h2 {color: red;} /* ← this one is not applied /
p {color: blue;}
h2 {color: orange;} /
← because this one appears later in the file */

Hence the term “cascade”. The same thing happens with multiple style sheets. If this orange h2 had entered into a stylesheet that was output in the

later than red, orange would be applied and red totally ignored.

How to diagnose the problem

Luckily, it’s fairly easy to find and diagnose the problem. Go to any page on your site and in Chrome right-click and select “Inspect”. This will open a new window containing all sorts of codes. Find the item

and expand it. There you will see a long list of items . It’s your many style sheets that are queued up from a wide variety of sources. When done correctly, each should have an identifying ID. Most likely you will notice that your plugin style is later in the as your theme style.

This is exactly what happens with our poor child theme and the Reaction Buttons stylesheet. See:

Note: You will also know you have this problem if you start adding CSS and find yourself having to add !important to all of your styles. Generally, you should never need to do this as long as everything is properly enqueued.

What to do about it

We now understand the “cascade” and we know that the order of the style sheets is wrong, but how do we fix it?

The short answer is that you rearrange the style sheets. But how do you do this specifically in WordPress? In this case, the plugin author needs to update the plugin to properly enqueue the stylesheet. But what can you do in the meantime?

Part of how WordPress displays stylesheets on the page is to ask if this stylesheet is “dependent” on any other stylesheet. You don’t want to edit the plugin files directly, but you do have control over your child theme and how it enqueues its stylesheet. For example, most child themes enqueue their styles like this:

get_stylesheet_directory_uri() . ‘/style.css’, array(‘total-parent-css’), ‘1.0’, all );

Between the parentheses, you will notice that there are five arguments separated by commas. The third argument is called the “addiction”. In this case, it says that the child theme depends on the parent theme and it calls it according to the “handle” of the parent theme.

Here’s the trick: Make sure the child theme ALSO depends on the Reaction Buttons stylesheet. All we have to do is find the “handle” of this stylesheet and add it to our dependency array.

Unfortunately, WordPress doesn’t make it easy to find the handle of stylesheets. You can do it in two ways:

  1. You can open the Reaction Buttons plugin files and search for “wp_enqueue_style”. The first argument of this function is that stylesheets “manage”.
  2. If you don’t like to touch the code, install two plugins: Debug Barand Debug Bar Script and Style Dependencies. Once they are enabled, go to any homepage and in your admin bar you will see a link called “Debug”. Click on it and choose the tab labeled “Script and Style Dependencies”. Look through this list to find the Reaction Button stylesheet handle. Here’s what it looks like:

css2 troubleshooting

Now that we know what the handle is, let’s add it to our child theme dependencies, like this:

get_stylesheet_directory_uri() . ‘/style.css’, array(‘total-parent-css’, ‘reaction_buttons_css’), ‘1.0’, all );

That’s it! Now when you write custom styles in your child theme, they will automatically override any styling in the Reactions Buttons plugin.

The stunt can get complicated

Like all things in web development, this topic can get a lot more complicated. For example, WordPress queues all plugins in alphabetical order. If you’re building a plugin with styles and want it to be applied late, you’re kinda stuck.

There is also the issue of CSS specificity. Themes sometimes create extremely specific styles; so even if your new stylesheet is released later in the

you still don’t override their styles unless you get even MORE specific. ToNew has a great article on specificity, as does smashing magazine

Finally, understanding specificity, inheritance, and how WordPress enqueues stylesheets is extremely important for authors of plugins that might enqueue multiple stylesheets. Ensuring proper dependencies can alleviate the amount of CSS you need to write – remember that if you declare a dependency and that stylesheet isn’t marked as output for some reason, your style will also not be output.

In conclusion

With all of this in mind, troubleshooting queuing and cascading issues should be much easier for you. Go with confidence and CSS away from your heart’s content!