[wp-trac] [WordPress Trac] #60025: Changeset 57156 breaks themes that relied on update_option( 'stylesheet', '...' )

WordPress Trac noreply at wordpress.org
Mon Dec 11 23:18:00 UTC 2023


#60025: Changeset 57156 breaks themes that relied on update_option( 'stylesheet',
'...' )
--------------------------+------------------------------
 Reporter:  blindmikey    |       Owner:  joemcgill
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Themes        |     Version:  6.4.2
 Severity:  critical      |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+------------------------------

Comment (by CodeGeek):

 We also have a theme that is based on Roots' Sage base theme version 9 and
 have also experienced the same issues as reported in this ticket.

 What seems to have fixed the issue for us is adding the following filter
 to our functions.php:

 {{{#!php
 <?php
 add_filter('stylesheet_directory', function ($tdir, $temp, $root) {
     if (!str_contains($tdir, 'templates')) {
         $tdir .= "/templates";
     }
    return $tdir;
 }, 10, 3);
 }}}


 Then we had to update the lib/setup.php mix() function to change $rootPath
 from get_stylesheet_directory() to get_template_directory():

 {{{#!php
 <?php
 function mix($path)
 {
     static $manifest;

     //$rootPath = get_stylesheet_directory();
     $rootPath = get_template_directory();
     $publicFolder = "/dist";
 ...
 }}}

 As best as we can figure, what appears to be happening is that there is a
 function is_child_theme() in wp-includes/theme.php which has changed. It
 had been dependent upon two global constants (STYLESHEETDIR and
 TEMPLATEDIR), but now it is using the functions get_template_directory()
 and get_stylesheet_directory().

 In the past the two global constants were being set by calling the same
 functions, but likely before the theme was loaded or initialized. In WP
 6.3 and earlier, the is_child_theme() function call returned false. Now
 that function call is returning true.

 **''So WP is considering the Roots Sage theme to be a child theme now.''
 **
 With a child theme, the stylesheet directory should be the folder
 containing the child theme (which in our case is the templates folder)
 whereas the template directory should be the parent theme (in our case is
 our theme folder).

 So the code above adjusts the stylesheet_directory filter so it returns
 the templates folder while the mix function uses the parent directory for
 the rootPath, which is where it looks for all of the other theme files.

 This fixed all of our issues except that now that the templates folder is
 considered a child theme, our theme fails the validate_current_theme check
 in wp-includes/theme.php(line 878), because the "child theme" doesn't have
 the expected style.css file. This check is run whenever an admin user
 visits the appearance->themes dashboard in the backend of wordpress. The
 failure automatically triggers the theme to be switched to a default
 (twentytwentyfour). To prevent this check, we have also added the
 following into our functions.php:

 {{{#!php
 <?php
 add_filter('validate_current_theme', function($val) { return false;});
 }}}

 I don't think that the Roots theme should be considered a child theme. But
 the way the WP code is now working, it is. If the WP authors choose to
 roll that check back, I don't think that these suggested code changes will
 cause anything to break, but there could be other factors at play here due
 to the extensiveness of the recent WP changes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60025#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list