Parent theme wrongly missing (till 6.5-alpha-57505)

[dennysdionigi]

The thread has been closed, but the issue is still there and still needs a fix.

There is a bug in latest WordPress FSE Core Updates and/or any FSE theme.
The following is the error: The parent theme is missing. Please install the "XXX" parent theme. when trying to set up the most basic of Child Themes.

I also believe this could be related to Multisite, or to the way the core searches for any php file related to parent theme (which blocks based themes have not, or at least... not mandatory).

The double problem is that: even both sibling theme exist, parent and child, and even if folder names and directories are the required and right ones, this alert should not appear.

This error, obviously brings to delete the child theme, and lead to, maybe, future bigger issues, missing fields, blocks, metabox and so on.

Step-by-step reproduction instructions

Steps to Reproduce

Create a child theme
Create a new directory: wp-content/themes/twentytwentyfour-child
Create a child theme style.css file, containing Theme Name: Twenty Twenty-Four Child and Template: twentytwentyfour (Screenshot)
Visit WordPress Admin > Appearance > Themes (Screenshot)
Activate the Twenty Twenty-Four Child (Screenshot)
(Screenshot of Directory Structure)

Expected Behavior

Visiting the site with the active child theme displays the default Twenty Twenty-Four home page with all styles loaded correctly.

Actual Behavior

At first, there is a success message "New theme activated. Visit site"
Reloading the page results in the following error message: "Error: The parent theme is missing. Please install the "twentytwentyfour" parent theme." (Screenshot)
Visiting the site results in a blank white screen where the .wp-site-blocks element is empty.

Potential patch

I added an empty index.php inside parent child theme

Other Notes

This is a fresh, standard WordPress installation (v6.5-alpha-57505)
There are no active plugins on the site.
There are no special directory changes or customizations.

As mentioned before, this is a Multisite install, even if there's no actual secondary website.
I tested on a non-Multisite instance, and randomly I still have the issue.

I would assume patching WordPress would be more difficult than just dropping a blank index.php file into the theme (and it doesn't appear to have any affect on anything), so maybe as a temporary solution, index.php could be added to block themes?

Or skip the requirement on an index.php at all.

Environment info
Wordpress 6.5-alpha-57505

[swissspidy]

Is this happening only on 6.5 or already on 6.4?

[dennysdionigi]

Also on 6.4.

(And also on daily 6.5-alpha-57555)

[nlpro]

Hmmm, why is there no index.php file in 2023 and 2024 themes?

[nlpro]

Seems like ticket #54272 answers my question.

[poena]

Also reported on ​https://github.com/WordPress/gutenberg/issues/58549

While I was not able to reproduce it two weeks ago, I can reproduce it today on 6.5-beta1-57630
-It doesn't make a difference if the child theme is a block theme or not
-It doesn't make a difference if it is multisite

[poena]

This is the first commit that I can find, where the parent theme is missing:
​https://github.com/WordPress/wordpress-develop/commit/03cb3e30f20b1cdff0c4b0fb3bde2bcd3c4a1c30

If I change this line:
​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/class-wp-script-modules.php#L177
$position = wp_is_block_theme() ? 'wp_head' : 'wp_footer';

To not use wp_is_block_theme(), then the child theme activation works again.

But I don't understand why and I don't think I can troubleshoot it further, pinging @youknowriad

[swissspidy]

But if this is already happening on WP 5.4, it can‘t be because of that commit. It might just be getting triggered earlier

[scruffian]

I had a look into this. It seems that the problem is that when we call wp_is_block_theme in the script loader, we don't have an accurate value in $wp_theme_directories so it can't find the parent theme yet. The problem doesn't happen when the theme isn't active. I think the solution is probably to set up $wp_theme_directories earlier, or to use a different way of checking the condition in the wp-script-modules file.

[scruffian]

This is the first commit that I can find, where the parent theme is missing:

​https://github.com/WordPress/wordpress-develop/commit/03cb3e30f20b1cdff0c4b0fb3bde2bcd3c4a1c30

This is now loading WP_Script_Modules earlier than it used to, which means the wp_is_block_theme check happens earlier.

This PR registers the default theme directory root earlier in wp-settings. Since ​https://github.com/WordPress/wordpress-develop/commit/03cb3e30f20b1cdff0c4b0fb3bde2bcd3c4a1c30 we need to move this earlier in the load so that when `wp_script_modules()->add_hooks() runs it is able to determine what the parent theme is.

Fixes ​https://github.com/WordPress/gutenberg/issues/58549

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

[scruffian]

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

[scruffian]

I have a fix for this here: ​https://github.com/WordPress/wordpress-develop/pull/6118

[youknowriad]

@swissspidy It seems this is now more visible in 6.5 with the modules addition. I think we should consider fixing it for 6.5.

We could probably add some e2e test for this to ensure a child themes work as expected.

[swissspidy]

@scruffian Thanks for the PR! Note that a separate patch file is not necessary. A PR alone is fine.

@youknowriad Given that the module addition made things work, sure, there is a regression to address. But if this also happens on 6.4 it means there is more going on, and ​https://github.com/WordPress/wordpress-develop/pull/6118 alone might not cut it. Either way, testing will confirm.

[huzaifaalmesbah]

Test Report

Description

I can't able to reproduce it on 6.4.3. I can reproduce on 6.5-beta1-57631 and after apply patch resolved this issue.

Patch tested: ​PR 6118

Environment

• WordPress: 6.5-beta1-57631
• PHP: 8.3.2
• Server: nginx/1.25.3
• Database: mysqli (Server: 11.2.2-MariaDB / Client: mysqlnd 8.3.2)
• Browser: Chrome 121.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Four Chlid
• MU Plugins: None activated
• Plugins:
  • Query Monitor 3.15.0
  • Test Reports 1.1.0

Actual Results

Issue resolved with patch ✅

Screenshots

Before Apply Patch	After Apply Patch ✅

[shailu25]

Test Report

Description:

• I can reproduce this issue in 6.5-beta1.

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

Environment:

OS: Windows
Web Server: Nginx
PHP: 8.1.23
WordPress: 6.5-beta1
Browser: Chrome
Theme: Twenty Twenty Four
Active Plugins: None

Actual Results:

• Parent theme missing Issue Resolved With Patch.✅

Screenshots:

Before Patch: ​https://prnt.sc/roDR6zosTcMz
After Patch: ​https://prnt.sc/0E0IxhbsGK8I

Let's get this shipped in Beta 2!

[swissspidy]

In 57661:

Script Loader: Add hooks for script modules and interactivity API only on after_setup_theme.

Ensures that wp_is_block_theme() is not called too early before the themes are fully setup.
This addresses an issue where a parent theme was mistakenly marked as being missing.

Props scruffian, youknowriad, swissspidy, poena, dennysdionigi, bgardner, westonruter.
Fixes #60411.

Went with a simplified alternative version as suggested by @westonruter. Committed in https://core.trac.wordpress.org/changeset/57661

[azaozz]

Just wondering... Why are these hooks in wp-settings.php and not in default-filters.php? Is there a reason why these hooks cannot be in the same place where all (most?) other default hooks are? As far as I know it is considered a bad practice to have hooks all over the place for no apparent reason...

[swissspidy]

Answered this on the PR already, but there is an apparent reason:

default-filters.php is loaded before wp_script_modules() and wp_interactivity() are loaded later in wp-settings.php, so the functions don‘t exist yet. So doing e.g. add_action( 'after_setup_theme', array( wp_script_modules(), 'add_hooks' ) ); in wp-settings.php doesn‘t work (fatal error).

FWIW there‘s plenty of precedence for adding hoojs in wp-settings.php, see for example the wp_textdomain_registry initialization just a few lines below.

There might be better ways to solve this, but that is probably best discussed in its own dedicated ticket.

[swissspidy]

Closing again as the issue was fixed. For improvements to the Modules API itself I recommend opening a new ticket if needed.