Bundled Themes: Pass theme version number to wp_enqueue_style()

[parsmizban]

Hi,

I think there is a bug when WordPress loads style.css file of child theme using version of parent theme, It should load style of child theme using child version,

Example:

Parent version: 4.7.2
Child version: 1.0.0

<link rel='stylesheet' id='parent-style-css'  href='http://localhost/wordpress/wp-content/themes/twentyfifteen/style.css?ver=4.7.2' type='text/css' media='all' />

<link rel='stylesheet' id='twentyfifteen-style-css'  href='http://localhost/wordpress/wp-content/themes/child-theme/style.css?ver=4.7.2' type='text/css' media='all' />

It should be :

<link rel='stylesheet' id='parent-style-css'  href='http://localhost/wordpress/wp-content/themes/twentyfifteen/style.css?ver=4.7.2' type='text/css' media='all' />

<link rel='stylesheet' id='twentyfifteen-style-css'  href='http://localhost/wordpress/wp-content/themes/child-theme/style.css?ver=1.0.0' type='text/css' media='all' />

[SergeyBiryukov]

Hi @parsmizban, welcome to WordPress Trac! Thanks for the ticket.

It looks like you're not passing the version argument to ​wp_enqueue_style(), so the WordPress core version is appended by default.

Could you share the lines of code where you're calling wp_enqueue_style()?

[parsmizban]

Hi @SergeyBiryukov ,
I didn't use wp_enqueue_style() or any other functions to load the child style,
WordPress loads the child style.css automatically

Regards

[pothi]

How did you create the child theme?

By default, WordPress comes bundled with a few default themes, such as Twenty Fifteen, but not child theme/s.

Did you use any plugin? If yes, please post your concern in the relevant plugin support forum. You may know more at ​https://wordpress.org/support/ .

Either way, this WordPress Core Trac is meant for discussing and troubleshooting any issues relevant to WordPress core. Any support requests pertaining to a theme, plugin or any general requests can be posted at ​https://wordpress.org/support/ .

[parsmizban]

Hi @pothi,

This ticket is related to core WordPress codes,
I don't use any plugins for testing this issue,
You can check this issue by creating a simple child theme,
That is not related to the child theme itself
This is how core WordPress loads the style.css of child theme automatically
And it attach wrong version to loaded style.css of child theme
You can create a simple child theme using this guide and check it: ​Child_Themes

[subrataemfluence]

First, ​wp_enqueue_style is not a plugin. It is a WordPress core function used to introduce CSS style sheets to a theme with the ability to pass several values by help of function parameters in order make sure it renders exactly the way we want!

This function is usually written in theme's functions.php file. If no version is specified WordPress will auto assign parent theme's version.

/* Syntax: wp_enqueue_style( string $handle, string $src = '', array $deps = array(), string|bool|null $ver = false, string $media = 'all' ) */
wp_enqueue_style('style', get_stylesheet_uri(), array(), '1.0', 'all');

I could not reproduce the issue when I created a child theme and assign a version number (in my case it is 1.0) to style.css like above. It renders like

<link rel='stylesheet' id='style-css' href='http://local.xyz.com/wp-content/themes/customizr-child/style.css?ver=1.0' type='text/css' media='all' />

[parsmizban]

Hi @subrataemfluence,

Friends please please attention!

When you use a child theme, WordPress loads the child style.css automatically without using any extra code!
if you use ​wp_enqueue_style to include child style.css, It double loads this file

So please check the source exactly before commenting here, you can create a child theme using just 1 style.css file and activate it and check this issue!
And please don't close this ticket again :)

Thank you for your time ! :)

[pothi]

My apologies to close the ticket prematurely.

Can you please post the content of your child theme's style.css file and functions.php file?

If functions.php file is empty, well, you don't need to share it.

Btw, here's the live demo of a site that uses a child theme for TwentyFifteen theme... wp.tinywp.com

The content of my child theme's style.css is...

/*
 * Theme Name: TwentyFifteen Child
 * Template: twentyfifteen
 * Version: 1.0.0
 */

In my case, style.css file of the parent theme is correctly overridden by the child theme, as the parent theme's functions.php contains the following code...

/**
 * Enqueue scripts and styles.
 *
 * @since Twenty Fifteen 1.0
 */
function twentyfifteen_scripts() {
    // Add custom fonts, used in the main stylesheet.
    wp_enqueue_style( 'twentyfifteen-fonts', twentyfifteen_fonts_url(), array(), null );

    // Add Genericons, used in the main stylesheet.
    wp_enqueue_style( 'genericons', get_template_directory_uri() . '/genericons/genericons.css', array(), '3.2' );

    // Load our main stylesheet.
    wp_enqueue_style( 'twentyfifteen-style', get_stylesheet_uri() );

    // Load the Internet Explorer specific stylesheet.
    wp_enqueue_style( 'twentyfifteen-ie', get_template_directory_uri() . '/css/ie.css', array( 'twentyfifteen-style' ), '20141010' );
    wp_style_add_data( 'twentyfifteen-ie', 'conditional', 'lt IE 9' );

    // Load the Internet Explorer 7 specific stylesheet.
    wp_enqueue_style( 'twentyfifteen-ie7', get_template_directory_uri() . '/css/ie7.css', array( 'twentyfifteen-style' ), '20141010' );
    wp_style_add_data( 'twentyfifteen-ie7', 'conditional', 'lt IE 8' );

    wp_enqueue_script( 'twentyfifteen-skip-link-focus-fix', get_template_directory_uri() . '/js/skip-link-focus-fix.js', array(), '20141010', true );

    if ( is_singular() && comments_open() && get_option( 'thread_comments' ) ) {
        wp_enqueue_script( 'comment-reply' );
    }

    if ( is_singular() && wp_attachment_is_image() ) {
        wp_enqueue_script( 'twentyfifteen-keyboard-image-navigation', get_template_directory_uri() . '/js/keyboard-image-navigation.js', array( 'jquery' ), '20141010' );
    }

    wp_enqueue_script( 'twentyfifteen-script', get_template_directory_uri() . '/js/functions.js', array( 'jquery' ), '20150330', true );
    wp_localize_script( 'twentyfifteen-script', 'screenReaderText', array(
        'expand'   => '<span class="screen-reader-text">' . __( 'expand child menu', 'twentyfifteen' ) . '</span>',
        'collapse' => '<span class="screen-reader-text">' . __( 'collapse child menu', 'twentyfifteen' ) . '</span>',
    ) );
}
add_action( 'wp_enqueue_scripts', 'twentyfifteen_scripts' );

So, can you please share your style.css file and functions.php file (if it is not empty)?

[parsmizban]

@pothi و

Thank you for your investigation,
As I see in your source of subdomain, You can find this line:

<link rel='stylesheet' id='twentyfifteen-style-css'  href='http://wp.tinywp.com/wp-content/themes/twentyfifteen-child/style.css?ver=4.7.2' type='text/css' media='all' />

Your child theme version is 1.0.0, And according to my reported issue, It loaded the style.css using version 4.7.2, But it should be 1.0.0

My function.php is empty
My child style.css file is very simple, like your mentioned style

Regards

[pothi]

Thanks for checking my demo installation. In mine, TwentyFifteen didn't create the ID named "parent-style-css". How was it created on your localhost WP install?

[pothi]

You may use ​string location plugin to find the exact string/s, such as "parent-style", as "-css" is added by WordPress core.

[pothi]

If you understand how the child's theme's stylesheet is loaded, that'd help to track down where things went wrong. For example, the ID "twentyfifteen-style-css" was created by the following line...

wp_enqueue_style( 'twentyfifteen-style', get_stylesheet_uri() );

It exists in parent theme. It is simply overridden by child theme. So, naturally, the syntax is clear. The fourth parameter, if not set any value (or null), WP would attach its version number. Direct quote...

(string|bool|null) (Optional) String specifying stylesheet version number, if it has one, which is added to the URL as a query string for cache busting purposes. If version is set to false, a version number is automatically added equal to current installed WordPress version. If set to null, no version is added.
Default value: false

[parsmizban]

I reviewed the code of ​twentyfifteen theme because my child theme is based on twentyfifteen theme...
in file function.php I found this line:

<?php
// Load our main stylesheet.
wp_enqueue_style( 'twentyfifteen-style', get_stylesheet_uri() );

So this will lead to load the style.css using default WordPress version and NOT the theme itself!
I think this part should be fix in the theme twentyfifteen too (May be in other default theme too) ...
First I changed the line to this:

<?php
wp_enqueue_style( 'twentyfifteen-style', get_stylesheet_uri(), array( ), wp_get_theme()->get( 'Version' ) );

Using wp_get_theme()->get( 'Version' ) both child theme and parent theme get correct version when they load

I checked other default WordPress themes (2014,2015,2016,2017) , They all missed the version of theme
So I think this is needed for them because of future update of style.css
It is prefer to the default WordPress version, It should load the version of theme and not WordPress version

[parsmizban]

Core developers please check this ticket and review my posts :)

[parsmizban]

Patch

[ianbelanger]

Refreshed patch for 2012 - 2017 themes

[ianbelanger]

This issue seems to warrant fixing and should not affect backwards compatibility at all, so I have refreshed the patch to apply to trunk and include 2012, 2013, 2014, 2015, 2016, and 2017.

[desrosj]

This is looking good. I am wondering if we should make the versions for the supplemental stylesheets dynamic as well. This would ensure proper cache busting occurs when new themes are released.

For example, TwentySeventeen has twentyseventeen-block-style, twentyseventeen-colors-dark, and several IE stylesheets that have a hard coded version.

We should also open a ticket to explore passing the theme version to wp_enqueue_script() calls.

[ianbelanger]

Patch includes all stylesheets for themes 2010 - 2017

[ianbelanger]

39997.2.diff removes the hard coded version number from all stylesheets included by each theme and makes them dynamic based on the current theme's version number. This should allow for proper cache busting when a theme or child theme version number is changed.

[dswebsme]

Patch 39997.2.diff tested and confirmed. Themes 2010 - 2017 now properly (dynamically) append version info from style.css for enqueued stylesheets.

This fix also addresses the original issue child themes based off of twenty* themes now correctly show the child theme version info instead of the parent theme version.

Ready for commit.

[desrosj]

Thanks, everyone! 39997.diff​ fixes the twentyeleven-theme-options and dark stylesheets in Twenty Eleven to also include the theme version, and corrects the Genericons version in Twenty Thirteen.

[desrosj]

In 45212:

Twenty Thirteen: Correct Genericons stylesheet version number.

In [28693], the Genericons stylesheet was updated to 3.0.3, but the version was incorrectly indicated as 3.03.

See #39997.

[desrosj]

In 45213:

Bundled Themes: Use the theme version when enqueuing theme specific stylesheets.

For many bundled theme related stylesheets, a version is either not specified, or specified as a hardcoded date string when enqueued. This is problematic when a stylesheet is updated and the version number is not (which has happened several times recently). This change ensures that all bundled theme related stylesheets use the theme’s version as the stylesheet version. This ensures cache busting for theme stylesheets every time a theme is updated and guarantees that users receive any new or updated styles included in the update when visiting the site for the first time after an update.

Props parsmizban, ianbelanger, dswebsme.
Fixes #39997.

[obenland]

Based on ​the function reference, [45213] seems backwards incompatible for Twenty Ten and Twenty Eleven, as they were introduced before wp_get_theme() was.

More of an edge case, but worth considering: Going from a date-based cache bust to a version-based one will make testing themes in trunk harder or we'll need alpha theme versions.

Maybe it would be sufficient to add a (date-based) version to enqueuing calls that don't specifically define one and leave the rest be?

[dedidata]

@desrosj,

Thank you, Could you please propose my new account : dedidata
Because my old account : parsmizban is disabled in Slack, So I use my new account
I am currently GTE of Persian language

Regards

[desrosj]

Replying to obenland:

Based on ​the function reference, [45213] seems backwards incompatible for Twenty Ten and Twenty Eleven, as they were introduced before wp_get_theme() was.

@obenland Thanks for catching this.

More of an edge case, but worth considering: Going from a date-based cache bust to a version-based one will make testing themes in trunk harder or we'll need alpha theme versions.

Counter argument is that this problem exists in trunk today (just with hard coded values instead of versions) because stylesheet versions are often not bumped when updated.

I think reverting and auditing the last updated dates for each stylesheet would be fine. Only exception being Twenty Nineteen, which has used wp_get_theme()->get( 'Version' ) from the start.

[desrosj]

In 45218:

Bundled Themes: Reverts [45213].

Reverting to address backward compatibility concerns in Twenty Eleven and Twenty Ten.

See #39997.

[ianbelanger]

Originally this ticket only addressed 2012 - 2017 themes, maybe we should create a patch for those and address 2010 and 2011 in their own ticket? @desrosj I can create a patch quickly if this works

[desrosj]

I audited the stylesheet last edit dates and the version specified in the wp_enqueue_style() call. Let's leave Twenty Nineteen alone (that was already calling wp_get_theme()->get( 'Version' ), and make sure the dates are correct (and actually present) for each stylesheet. Results (dates in YYYY-MM-DD):

	Last Modified	Current Specified Version
Twenty Ten
blocks.css	2018-12-18	20181018*
editor-blocks.css	2018-12-18	none
style.css	2019-02-07	none
Twenty Eleven
blocks.css	2019-01-02	20181230*
editor-blocks.css	2019-01-02	20181230*
style.css	2019-04-04	none
/inc/theme-options.css	2011-06-02	2011-04-28*
/colors/dark.css	2019-04-04	null
Twenty Twelve
style.css	2019-04-06	none
/css/blocks.css	2019-04-06	20181230*
/css/ie.css	2015-02-14	20121010*
/css/editor-blocks.css	2019-04-06	20181230*
Twenty Thirteen
style.css	2019-02-07	2013-07-18*
/css/blocks.css	2019-01-02	2018-12-30*
/css/ie.css	2015-02-14	2013-07-18*
/css/editor-blocks.css	2019-01-02	2018-12-30*
Twenty Fourteen
style.css	2019-02-07	none
/css/blocks.css	2019-01-02	20181230*
/css/ie/css	2014-07-01	20131205*
/css/editor-blocks.css	2019-01-02	20181230*
Twenty Fifteen
style.css	2019-04-02	none
/css/blocks.css	2019-01-02	20181230*
/css/ie.css	2017-09-16	20141010*
/css/ie7.css	2014-12-10	20141010*
css/edtior-blocks.css	2019-01-02	20181230*
Twenty Sixteen
style.css	2019-02-07	none
/css/blocks.css	2019-01-02	20181230*
/css/ie8.css	2017-05-30	20160816*
/css/ie7.css	2017-05-30	20160816*
/css/editor-blocks.css	2019-01-02	20181230*
Twenty Seventeen
style.css	2019-04-08	none
/assets/css/blocks.css	2019-01-05	1.1
/assets/css/colors-dark.css	2019-04-08	1.0
/assets/css/ie9.css	2016-12-02	1.0
/assets/css/ie8.css	2016-12-02	1.0
/assets/css/editor-blocks.css	2019-03-28	1.1

[dswebsme]

@desrosj Is your audit suggesting that we should continue using the hardcoded (corrected) dates instead of wp_get_theme()->get( 'Version' ) as proposed by @ianbelanger?

I understand we're leaving twentynineteen as is and that twentyten and twentyeleven can't use wp_get_theme() due to backwards compatibility. I'm just unclear on the proposed direction for 2012-2017 themes.

[desrosj]

Replying to dswebsme:

Is your audit suggesting that we should continue using the hardcoded (corrected) dates instead

Correct! This would ensure maximum backward compatibility, which is a goal of the bundled themes. Even though Twenty Twelve and newer were released after wp_get_theme() was introduced, it is possible that a site running an older version of WordPress could install a newer default theme. Since Twenty Nineteen was already introduced using wp_get_theme(), and specifically designed to showcase the block editor, it should be OK to leave that one as is.

[dswebsme]

@desrosj Understood. Agreed that if we are not using wp_get_theme() that we should at least correct the release dates as you mentioned.

I don't believe this change will address the original issue reported by @parsmizban though. Child themes based off of most twenty* parents will still default to the WP version OR the parent theme version.

Of course the child theme can bypass this by doing their own enqueues. I'm open to that if it means maximizing backwards compatibility. Just want to be sure it's something we consider before our next patch.

[obenland]

Replying to dswebsme:

I don't believe this change will address the original issue reported by @parsmizban though. Child themes based off of most twenty* parents will still default to the WP version OR the parent theme version.

I'm not sure parent themes should have to worry about properly versioning child theme's stylesheets. If versioning is a concern for a child theme, I think it should enqueue its stylesheet itself and pass that version.

[dswebsme]

@obenland Completely agree.

@desrosj @pothi - Given we aren't fixing the original issue but we do want to update the child themes to the corrected dates it's my opinion this ticket should be closed and a new ticket created to reflect the child theme version updates.

I'm still new here so I'd like confirmation that's the preferred approach before I take further action.

[desrosj]

When a style (or script) is enqueued and a version is not passed, the version will always default to the current version of WordPress. The only exception is if null is passed as the version, then no ver argument will be added to the resource URL.

The default themes do not pass a version to its wp_enqueue_style() call, so the site's version of WordPress is used.

I agree with @obenland that if a specific version is important, the child theme should enqueue its own stylesheet.

Based on the audit above, no default style.css files actually have a version defined when enqueuing. This means that if the theme is updated and WordPress is not, the cache will not be busted. @obenland can you see any issues with adding a version to these?

I'm inclined to close this out as the original issue is working as expected and open a new ticket to ensure stylesheet versions are accurate.

[obenland]

Replying to desrosj:

@obenland can you see any issues with adding a version to these?

Not really. It'd be interesting to find out what prompted the decision to omit a cache buster, if someone feels inclined to track that down. But adding a version shouldn't break things.

[ianbelanger]

Here's one issue with requiring child themes to enqueue there own stylesheets. By default, when using a child theme, the style.css is loaded from the child theme automatically by core, without having to enqueue it. When you do enqueue it, you end up loading your child theme style.css twice. This point was made by @parsmizban 2 years ago. This is why I pursued a fix for this.

When you use a child theme, WordPress loads the child style.css automatically without using any extra code!
if you use wp_enqueue_style to include child style.css, It double loads this file

I personally think that we need to do something besides hardcoding versions, or if that is the chosen route, maybe we need to look at how child theme style.css is automatically enqueued.

[ianbelanger]

When enqueued child theme stylesheet is loaded twice

[obenland]

Replying to ianbelanger:

By default, when using a child theme, the style.css is loaded from the child theme automatically by core

It's not Core that does it, it's the parent theme being child-theme aware and enqueuing get_stylesheet_uri() rather than using get_template_directory_uri() with a path to their stylesheet. Consider it a service to make it as easy as possible to make small changes via a child theme.

When you do enqueue it, you end up loading your child theme style.css twice. This point was made by @parsmizban 2 years ago. This is why I pursued a fix for this.

Correct, you'll want to dequeue the parent's stylesheet in that case.

[ianbelanger]

Thanks for clarifying @obenland. I see it now and agree with @desrosj that we should close this ticket in favor of a new ticket that covers the Bundled Theme versions.

[dswebsme]

Opened #46979 and #46981 to address the above mentioned items.

[desrosj]

Thanks everyone!