I'm using the well-written Oenology theme by Chip Bennett as the Parent to my own Child theme.

In my development process, I've discovered that there are some challenges for people writing Child themes when it comes to controlling styles.

I've just discovered that my main style.css file gets loaded before every other stylesheet link or statement in <head>, and this explains why I was having trouble overriding some of the Parent styles.

further study of the problem shows that various Parent stylesheets and styles can be queued in the <head> in three places; add_action('wp_print_styles', , add_action('wp_enqueue_scripts', , and then add_action('wp_head', .

to keep things simple, I'm planning to create two stylesheets. the first main 'style.css' sheet would only include the @import url() command, needed to load Oenology's main stylesheet.

the second stylesheet would contain my Child rules. to make sure that it's loaded after all of the other rules, I'd queue it using add_action( 'wp_head', .

does this sound reasonable? or is there a better (more correct) way to do it?

btw, does anyone know what '/parent-theme/style.css?MRPreviewRefresh=723' means?


wp_enqueue_style() doesn't appear to work in wp_head().


3 Answers 3


Just FYI, this question probably borders on too localized, as it is specific to the Oenology Theme.

That said, here's where I think you're having a problem: Oenology enqueues two style sheets:

  1. style.css, directly in the document head (thus before wp_head() is fired)

  2. {varietal}.css, at wp_enqueue_scripts, with priority 11, in functions/dynamic-css.php:

      * Enqueue Varietal Stylesheet
     function oenology_enqueue_varietal_style() {
         // define varietal stylesheet
         global $oenology_options;
         $oenology_options = oenology_get_options();
         $varietal_handle = 'oenology_' . $oenology_options['varietal'] . '_stylesheet';
         $varietal_stylesheet = get_template_directory_uri() . '/varietals/' . $oenology_options['varietal'] . '.css';
         wp_enqueue_style( $varietal_handle, $varietal_stylesheet );
     // Enqueue Varietal Stylesheet at wp_print_styles
     add_action('wp_enqueue_scripts', 'oenology_enqueue_varietal_style', 11 );

The varietal stylesheet, which applies the "skin", enqueues at priority 11, to ensure that the base stylesheet, style.css, loads first, and the varietal stylesheet loads second, in order to cause the correct cascade.

So, if you need to override the varietal stylesheet, simply enqueue your second stylesheet after the varietal stylesheet; i.e. with a priority of at least 12 or greater.


To provide a more-general answer, to the more-general question:

In order to override a Parent Theme stylesheet enqueue, you need to know two things:

  1. The action hook at which the stylesheet is enqueued
  2. The priority at which the callback is added to the hook

Enqueue functions (wp_enqueue_script()/wp_enqueue_style()) can be properly executed anywhere between the init hook and the wp_print_scripts/wp_print_styles hooks. (The semantically correct hook at which to execute wp_enqueue_*() functions is currently wp_enqueue_scripts.) This list includes the following actions (among others; these are just the usual suspects):

  • init
  • wp_head
  • wp_enqueue_scripts
  • wp_print_scripts/wp_print_styles

(Note that wp_enqueue_scripts, wp_print_styles, and wp_print_scripts all fire inside of wp_head, at a specific priority.

So, in order to override a Parent-Theme stylesheet, you need to do one of the following:

  • De-enqueue the Parent-Theme stylesheet, via wp_dequeue_style( $handle )

  • Remove the Parent Theme callback that enqueues the style, via remove_action( $hook, $callback )

  • Use the CSS cascade to override the Parent-Theme stylesheet, by hooking your Child-Theme stylesheet wp_enqueue_style() call into the same hook with a lower priority or into a later hook.

    For this last option, if the Parent Theme uses:

    add_action( 'wp_enqueue_scripts', 'parent_theme_enqueue_style', $priority );

    ...then the Child Theme would use:

    add_action( 'wp_enqueue_scripts', 'child_theme_enqueue_style', {$priority + 1} );
  • thank you Chip. I can indeed use wp_enqueue_scripts and a high ordinal to get my Child stylesheet to load last. there are however still 3 different style statements after my Child stylesheet statement. 2 of them are output by WP itself!!!, and 1 is output by Oenology via wp's add_custom_image_header() function.
    – Gregory
    Commented May 10, 2012 at 2:38
  • the body.custom-background style statement is output by WP itself, but it appears that I can specify a custom background color by defining 'BACKGROUND_COLOR'. strange that a basic css rule would need to be set via a custom WP constant.
    – Gregory
    Commented May 10, 2012 at 2:47
  • 1
    last comment Chip. this question is not too localised. many themes would use all of the available hooks to enqueue or print styles, and Child theme developers need to know how to override those styles without necessarily disabling them. cheers.
    – Gregory
    Commented May 10, 2012 at 2:49
  • The problem I see with this is that the child_theme_enqueue_style will load the child style with a higher priority, further down the wp_head BUT it will duplicate the child stylesheet - Wordpress will autmatically load the child stylesheet at its normal priority and then, load it again, further down with the new priority. While it achieves the result of overriding all the other stylesheets, it creates a duplicate stylesheet in the page. Commented Nov 10, 2015 at 1:56

the only way to guarantee that my styles had final say in the cascade was to include them at the end of <head> via the wp_head hook. wp_enqueue doesn't work within wp_head so I had to echo the link directly:

function gregory_enqueue_stylesheets() {
    $base = get_stylesheet_directory_uri();
    echo '<link rel="stylesheet" href="'.$base.'/style-gregory.css" type="text/css" media="all">';
add_action( 'wp_head', 'gregory_enqueue_stylesheets', 18 );

finally, I can set my styles with relative ease, and without using high levels of specificity, or the !important rule which should only be used as a last resort.

WP needs a better style enqueuing system. every style, whether a file link or an inline style, should be passed through the same hook allowing the Priority to determine their order. optionally for debugging purposes, it would be useful if the hook also output the Priority values of each style perhaps in commented form.


I have been able to retain control of the styles in my Child theme while maintaining the original cascade of the Parent theme (which uses a main stylesheet, a sub-stylesheet, and a few style statements) by splitting my stylesheet into two as explained in the question. I am no longer using the wp_head() hook, instead using the proper and standard wp_enqueue_scripts() hook with a high ordinal to ensure that my stylesheet gets loaded last.

my Child theme's default stylesheet:

Theme Name: Oenology-Gregory
Template: oenology
Version: 20120506-0026

@import url("/wp-content/themes/oenology/style.css");

the function to enqueue my main stylesheet:

function gregory_enqueue_stylesheets() {
    $base = get_stylesheet_directory_uri();
    wp_enqueue_style( 'style-gregory', $base.'/style-gregory.css' );
add_action( 'wp_enqueue_scripts', 'gregory_enqueue_stylesheets', 18 );

there are however a few WP-generated style statements (i.e., not the parent theme) that are stated after my stylesheet, and I'll have to look at using either high specificity css rules to override the rules that concern me, or look for hooks to disable them, in particular the body.custom-background rule.

thank you all for your comments.



You should always use wp_enqueue_style() to load your stylesheet and that functions should be hooked to the wp_enqueue_scripts hook with runs in the head. I suspect that you weren't hooking it there, hence your problem. (As of WP 3.3, if wp_enqueue_style() is hooked to anything else, it throws a Notice with WP_Debug turned on).

  • @Chip's answer is better than mine and he's arguably more-qualified to discuss the Oenology theme ;) Is this a case where I should delete my answer even though it's right-ish?
    – mrwweb
    Commented May 9, 2012 at 16:45
  • No, I would leave your answer. It is correct, and addresses a specific part of the question. Commented May 9, 2012 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.