Parent theme incorrectly not getting resolved in WordPress 6.8-beta1

[fabiankaegy]

I just installed 6.8-beta1 on a site that is using a child theme and noticed that it's parent theme is no longer getting resolved. The themes both still appears in the themes listing but the child theme shows that it is broken because the parent theme is missing.

Downgrading to 6.7.2 resolves the issue again.

I was able to reproduce it with the most bare child theme possible off of a core theme.

[fabiankaegy]

Most basic version of a child theme with which I am able to reproduce the issue

This reverts https://core.trac.wordpress.org/changeset/59885 (83b9080).

Trac ticket: https://core.trac.wordpress.org/ticket/63062

[joemcgill]

Using git-bisect, it looks like this regression was introduced in [59885]. I'm guessing that calling wp_is_block_theme() this early is likely polluting the cache prior to themes being set up.

I've created a PR that reverts that commit for testing, but we should find a way to fix this without fully reverting the commit that fixed #61811.

[joemcgill]

Updated the PR with a small fix. Hoping to get some tests added and consider whether we want to address the root cause rather than just this bug. I've left more details in the PR.

[jeffr0]

Thank you for reporting this issue @fabiankaegy I too encountered this today after installing 6.8 Beta 1 while using a Child theme.

[krupajnanda]

Test Report

Description

I verified the PR with Playground and shared child theme zip and looks like it is working as expected now.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8466

Environment

• WordPress: 6.8-beta1-20250305.214555
• PHP: 7.4.31-dev
• Server: PHP.wasm
• Database: WP_SQLite_Translator (Server: 5.5 / Client: 3.40.1)
• Browser: Chrome 133.0.0.0
• OS: macOS
• Theme: Minimal Child Theme 1.0.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

Supplemental Artifacts

Add as Attachment

[riddhidave]

Ticket Reference: Issue with Parent Theme Resolution in WordPress 6.8-beta1

Before the patch screenshot
​https://tinyurl.com/2c5dduqp
After Patch screenshot
​https://tinyurl.com/24wu4q2q

Issue Summary: installing WordPress 6.8-beta1 on a site using a child theme, it was observed that the parent theme was no longer being resolved. The child theme appeared broken in the themes listing, displaying the error:

Error: The parent theme is missing. Please install the "twentytwentyfive" parent theme.

However, downgrading to WordPress 6.7.2 resolved the issue, restoring the child theme’s functionality.

Steps to Reproduce (Before Patch):

Install WordPress 6.8-beta1.

Set up a child theme that depends on a core theme (e.g., twentytwentyfive).

Navigate to the WordPress admin panel under Appearance > Themes.

Observe that the child theme is marked as broken with the above-mentioned error.

Expected Behavior (Before Patch):

The child theme should correctly recognize its parent theme and function normally.

Actual Behavior (Before Patch):

The parent theme was not being detected.

The child theme was marked as broken and unusable.

Testing After Applying the Patch:

Updated WordPress to the patched version.

Retested with the same child theme setup.

Observed that the child theme now correctly recognizes its parent theme.

Verified that the error message no longer appears and the child theme is fully functional.

Results (After Patch):

The issue is successfully resolved.

The child theme correctly inherits from the parent theme as expected.

No error messages were displayed.

Conclusion:
The applied patch effectively fixes the parent theme resolution issue introduced in WordPress 6.8-beta1. After testing, the child theme is now working properly without any errors.

[ugyensupport]

Parent theme incorrectly not getting resolved in WordPress 6.8-beta1

Description

I just installed 6.8-beta1 on a site that is using a child theme and noticed that it's parent theme is no longer getting resolved. The themes both still appears in the themes listing but the child theme shows that it is broken because the parent theme is missing.

Downgrading to 6.7.2 resolves the issue again.
According to @fabiankaegy, able to reproduce it with the most bare child theme possible off of a core theme.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8466

Environment

• WordPress: 6.8-beta1-59940
• PHP: 8.4.1
• Server: Apache/2.4.62 (Unix) mod_wsgi/5.0.1 Python/3.12 mod_fastcgi/mod_fastcgi-SNAP-0910052141 OpenSSL/1.1.1w
• Database: WP_SQLite_DB\PDOEngine (Server: 3.47.0 / Client: 3.47.0)
• Browser: Chrome 133.0.0.0
• OS: macOS
• Theme: Minimal Child Theme 1.0.2
• MU Plugins: None activated
• Plugins:
  • Child Theme Configurator 2.6.6
  • Test Reports 1.2.0
  • WP File Manager 8.0.1

Actual Results

1. ✅ Issue resolved with patch.

Supplemental Artifacts

Before: ​https://limewire.com/?referrer=pq7i8xx7p2

After: ​https://limewire.com/?referrer=pq7i8xx7p2

[navi161]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8466

Environment

• OS: macOS 14.6.1
• Web Server: PHP.wasm
• PHP: 7.4.31-dev
• WordPress: 6.8-beta1-20250305.214555
• Browser: Chrome Version 133.0.6943.142
• Theme: Minimal Child Theme Version 1.0.2

Actual Results

• ✅ Issue resolved with patch.

Reference Screens Attached.

[manojmaharrshi]

Test Report

Description

This report validates whether the indicated patch for the child theme.

Patch tested: ​https://patch-diff.githubusercontent.com/raw/WordPress/wordpress-develop/pull/8466.diff

Environment

• WordPress: 6.8-beta1-59933-src
• PHP: 8.2.27
• Server: nginx/1.27.4
• Database: mysqli (Server: 8.4.4 / Client: mysqlnd 8.2.27)
• Browser: Chrome 133.0.0.0
• OS: macOS
• Theme: Minimal Child Theme 1.0.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

[manojmaharrshi]

Before Patch Snapshot

[manojmaharrshi]

After Patch Snapshot

[Ankit K Gupta]

Tested Additional Use Cases Apart from the Above-Listed Test Reports

• Since the issue was related to a Block-based theme, verified the fixes with a Non-Block-based theme like Storefront to check regression. Everything worked as expected ✅
• Verified behavior when the parent theme is not installed (or deleted) while the child theme is still present. A message correctly appeared: _"The active theme is broken. Reverting to the default theme."_ ✅
• Before the fix: The WP-CLI command (wp theme list) did not show the child theme in the theme list. After the fix: Verified that the child theme is now correctly listed. (Screenshots attached) ✅
• Tested via created Block-based (Twenty Twenty-Five) Child theme and Non-Block-based (Storefront) child themes to ensure compatibility. ✅
• Backward Compatibility: Reverted back to WordPress 6.7.2 after using the fix-specific branch. No issues appeared. ✅
• Attached child theme zip for TT5 and Storefront for further testing. ℹ
• No related console error or PHP errors observed while testing above use cases. ✅
• Full Site Editing works when Child theme is installed and active ✅

Before Fix: ​https://prnt.sc/W8P0mfiMiGZ9
After Fix: ​https://prnt.sc/2VlTiXuessjY

[Ankit K Gupta]

TT5 Child theme

[narenin]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested:

​https://github.com/WordPress/wordpress-develop/pull/8466

Environment

OS: macOS 14.6.1
Web Server: PHP.wasm
PHP: 7.4.31-dev
WordPress: 6.8-beta1-20250305.214555
Browser: Chrome Version 133.0.6943.142
Theme: Minimal Child Theme Version 1.0.2

Actual Results

✅ Issue resolved with patch.

[narenin]

Before applying patch

[narenin]

After applying patch

I tested this PR and it seems to fix the issue.

Before applying the PR:
​before-applying-the-PR.webm

After applying the PR:
​after-applying-the-PR.webm

I tested this PR and it seems to fix the issue.

Before applying the PR:
​before-applying-the-PR.webm

After applying the PR:
​after-applying-the-PR.webm

[audrasjb]

👆 Note: the above comment (17) is not related to this ticket/PR.

[pooja1210]

Hi,

Test Report:

Verified the fix on the attached theme with the patch, and it is working fine. Able to activate the theme successfully.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8466

Environment
WordPress: 6.8-beta1-2025030
OS: macOS
Theme: Minimal Child Theme

Actual Result: The fix is working properly, and the theme can be activated.

Screenshots:
Before fix: ​https://prnt.sc/__bk9MWO1xx2
After fix: ​https://prnt.sc/VR7Uj-ODliIo

Thanks

[shailu25]

Test Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/8466

Environment:
WordPress - 6.8-beta1
OS - Windows
Browser - Firefox
Theme: Minimal Child Theme
PHP - 8.2.12
Active Plugin: None

Actual Results:

• Issue Resolved With Patch.✅

Screenshots:

• Added Attachment

[shailu25]

Before Patch.

[shailu25]

After Patch.

I've updated the logic here to move setting post type support to a standalone callback, as suggested in ​this comment. @peterwilsoncc any chance you can take another look at this before beta 2?

[joemcgill]

In 59968:

Themes: Fix resolution of parent themes.

This fixes an issue introduced in [59885] whereby calling WP_Theme:is_block_theme() before themes are set up resulted in the parent theme to not be resolved. To address this, post support for editor default-mode has been moved to a standalone callback, wp_set_editor_default_mode(), which is called on the after_setup_theme hook. In addition, if WP_Theme::is_block_theme is called too early, a _doing_it_wrong() error will now be thrown.

Props fabiankaegy, joemcgill, peterwilsoncc, jorbin, krupajnanda, riddhidave, ugyensupport, navi161, manojmaharrshi, Ankit K Gupta, narenin, shailu25, pooja1210.
Fixes #63062.

https://core.trac.wordpress.org/changeset/59968

[wildworks]

Due to the influence of the _doing_it_wrong, it seems that the customizer displays a warning. See https://core.trac.wordpress.org/ticket/63086

[wildworks]

In addition, if WP_Theme::is_block_theme is called too early, a _doing_it_wrong() error will now be thrown.

​This early return might cause problems if you have a theme or plugin that is calling WP_Theme::is_block_theme too early.

For example, if the following plugin is enabled:

<?php
/**
 * Plugin Name: Block Theme Test
 */

wp_is_block_theme();

At this time, the site editor appears to display a black screen.

[wildworks]

Another example: In some cases, the submenu in the Appearance menu may change from Editor to Design, making the site editor itself inaccessible.

See ​https://github.com/WordPress/gutenberg/pull/69542

[gigitux]

Thanks, @wildworks, for the initial exploration. As mentioned in [63086], this change causes regressions in plugins relying on wp_is_block_theme(), such as WooCommerce.

Based on the discussion, this change seems necessary because wp_is_block_theme() may return an incorrect value due to inaccurate parent theme resolution before after_setup_theme. A potential solution could be addressing the parent theme resolution issue.

After some investigation (cc @nerrad), we found:

• wp_is_block_theme() calls wp_get_theme() to retrieve the theme and invokes the is_block_theme() method.
• wp_get_theme() instantiates WP_Theme, which sets a cache on the first run. If executed before after_setup_theme, ​the theme's functions.php will not have been processed, resulting in an incorrect cache.

A possible solution could be to only set the cache on WP_Theme if instantiated after after_setup_theme; otherwise, avoid caching.

It is essential to take careful consideration of performance implications.

[dinhtungdu]

Digging deeper into the Core to understand the issue, I found that:

• wp_is_block_theme doesn't need to be called after after_theme_setup, it just needs to be called after ​theme directories registration.
• The initial issue with the child theme is caused by calling that function after ​creating post types, which is before the theme directories registration.
• Moving that logic to after_theme_setup, as we did in this ticket, is enough to solve the issue.
• Plugins can never break the theme resolution because they are loaded ​after theme directories registration.

So the warning and early return don't protect us from anything and should be removed.

This PR partially reverts https://core.trac.wordpress.org/changeset/59968 by removing the warning and early return in WP_Theme::is_block_theme(), which causes issues if active plugins call wp_is_block_theme() early. It's safe for plugins to call wp_is_block_theme() anytime so the early return and warning should be removed.

Trac ticket: https://core.trac.wordpress.org/ticket/63062

[afragen]

FWIW is_block_theme() is called in the constructor for WP_Theme and this error and early return is causing loads of issues in plugins because of that.

Absolutely agree. This is filling up my logs and not sure it's even effecting function.

[joemcgill]

Hi all, I appreciate everyone's testing and feedback so far! #63086 is tracking the _doing_it_wrong() placement. Let's consolidate further conversation over there to try to keep things in one place.

Closing in favor of #8526

[joemcgill]

In 60037:

Themes: Improve error notice when wp_is_block_theme() is called too early.

This is a follow-up to [59968] which improves error handling for when wp_is_block_theme() is called too early. Initially, _doing_it_wrong() was called in WP_Theme::is_block_theme() was called prior to themes being set up, in order to avoid the bug reported in #63062, where doing so would cause parent themes to not be resolved. After further investigation, the issue is only caused by calling wp_is_block_theme() before the root theme directory has been registered (e.g., when called on the muplugins_loaded hook).

Moving This error message to wp_is_block_theme() when $GLOBALS['wp_theme_directories'] is empty avoids unnecessary error messages.

Props wildworks, sukhendu2002, SirLouen, dinhtungdu, narenin, joemcgill, peterwilsoncc, afragen.
Fixes #63086. See #63062.