Why does using wp_register_style without wp_enqueue load and print CSS tags in the front-end?

Question

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.

Answer 1

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