0

I have this piece of code that registers a CSS in a child theme and when visiting the front-end my_css is actually included. Why is that ? I thought that registering meant registering for later use to allow - among other things - conditional enqueuing of stylesheets/scripts. This shouldn't be working without enqueuing my_css at some point, right ?

function register_my_styles()
{
    wp_register_style('parent_theme', get_template_directory_uri() . '/style.css', '', null, 'all');
    wp_register_style('my_css', get_stylesheet_directory_uri() . '/src/css/my_css', array('parent_theme'), null, 'all');
}

add_action('wp_loaded', 'register_my_styles');

Commenting out wp_register_style('my_css at least works :] but the way it behaves prevents me from using conditional enqueuing since my_css is rendered on the front-end by just using wp_register_style.

Now the funky part is: I am using ParentTheme 4.10.4 as a parent theme. When I downgrade for each version all the way to 4.0.1 then wp_register_style works normally and doesn't output the CSS line on the frond-end.

Which would be fine but enqueuing also doesn't work:

function register_my_styles()
{
    wp_register_style('parent_theme', get_template_directory_uri() . '/style.css', '', null, 'all');
    wp_register_style('my_css', get_stylesheet_directory_uri() . '/src/css/my_css', array('parent_theme'), null, 'all');
}

function enqueue_my_styles()
{
    wp_enqueue_style('parent_theme');
    wp_enqueue_style('my_css');
}

add_action('wp_loaded', 'register_my_styles');
add_action('wp_enqueue_style', 'enqueue_my_styles');

What am I missing and misunderstanding here ?

EDIT:

Fixing add_action('wp_enqueue_style', 'enqueue_my_styles'); with add_action('wp_enqueue_scripts', 'enqueue_my_styles'); fixed the problem for every version of ParentTheme < 4.10.x. and the rest of functions.php, with conditional enqueuing of styles now work as expected.

So I am inclined to believe there's a problem on the parent theme's side (Divi).

Things were apparently working in some specific conditions for a while despite wp_enqueue_style not working and that's why it escaped me for some time.

5
  • "This shouldn't be working without enqueuing my_css at some point, right ?" - yes, if there are no stylesheets on the page where their dependencies include the "my_css". And actually, there's no hook named "wp_enqueue_style" and instead, you should use wp_enqueue_scripts - for enqueuing JS and CSS files.
    – Sally CJ
    Sep 2, 2021 at 23:50
  • What is ParentTheme? Do you have a link? If you've narrowed it down to specific versions what changed in those versions? Did you ask ParentTheme support? 3rd party theme dev support is off-topic here. This abnormal behaviour is very likely caused by the parent theme based on what you've said in your question. Sally is right though, these are the incorrect hooks for enqueing scripts and styles
    – Tom J Nowell
    Sep 3, 2021 at 1:34
  • @TomJNowell: Parent Theme is Divi. Even though it's obviously doing something different from one version to another I think the problem is on my side. Haven't yet pinpointed the difference. Sep 3, 2021 at 6:36
  • @SallyCJ: Thanks, I have to understand how the default work for wp_register_style. I changed wp_enqueue_style to wp_enqueue_scripts but it's not enough to solve the problem. What works is using a function that do both registering styles and enqueuing styles and put it in wp_enqueue_scripts hook. Sep 3, 2021 at 6:45
  • 1
    I downgraded the parent theme (Divi) to 4.9.x serie and the original code, with registering and enqueuing in different (and correct) hooks now work as intended. I'll asking for third party support now that I am confident the change was introduced in 4.10.x serie. Sep 3, 2021 at 7:31

1 Answer 1

0

Old post but this issue still exists and here is the reason why and how to resolve it.

Divi has two functions responsible for this issue.

et_requeue_child_theme_styles() and et_core_replace_enqueued_style()

et_requeue_child_theme_styles() fetches a list of all registered styles in child theme directories et_core_replace_enqueued_style() deregisters, dequeues and then enqueues these styles itself.

The 'logic' behind this is to ensure that all Divi Theme styles are loaded before any Child Theme styles are loaded. It's pretty poor coding if you ask me because it doesn't consider if they've been enqueued or not. It's a very blunt approach.

Divi also implements this with a very very high priority so it's unlikely that most users would happen to simply try enqueueing their styles with a higher priority.

Here's Divi's enqueue action: add_action( 'wp_enqueue_scripts', 'et_requeue_child_theme_styles', 99999999 );

So to work around it you need to enqueue your styles with a priority higher than 99999999. Thats pretty excessive...

eg:

/**
 * Enqueue scripts and styles for services post type
 *
 * @return void
 */
function dsl_services_enqueue_scripts() {

    wp_register_style( 'services-css', get_stylesheet_directory_uri() . '/css/services-styles.css', array(), '1.00', 'all' );
    if ( is_single()  && 'service' == get_post_type() ) {
        wp_enqueue_style('services-css');
    } 
}
add_action( 'wp_enqueue_scripts', 'dsl_services_enqueue_scripts', 999999999 );

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.