Make WordPress Core

Opened 5 months ago

Closed 4 months ago

#60411 closed defect (bug) (fixed)

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

Reported by: dennysdionigi's profile dennysdionigi Owned by: swissspidy's profile swissspidy
Milestone: 6.5 Priority: normal
Severity: normal Version: 6.4.3
Component: Themes Keywords:
Focuses: administration, template Cc:

Description

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

Attachments (1)

patch.diff (1.1 KB) - added by scruffian 4 months ago.
https://github.com/WordPress/wordpress-develop/pull/6118

Download all attachments as: .zip

Change History (27)

#1 @jrf
5 months ago

  • Focuses coding-standards php-compatibility removed
  • Severity changed from blocker to normal

#2 @swissspidy
4 months ago

  • Keywords needs-testing added

Is this happening only on 6.5 or already on 6.4?

#3 @dennysdionigi
4 months ago

Also on 6.4.

(And also on daily 6.5-alpha-57555)

#4 @nlpro
4 months ago

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

#5 @nlpro
4 months ago

Seems like ticket #54272 answers my question.

Last edited 4 months ago by SergeyBiryukov (previous) (diff)

#6 @poena
4 months ago

  • Milestone changed from Awaiting Review to 6.5

#7 @poena
4 months ago

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

#8 @poena
4 months ago

  • Focuses multisite removed

#9 @poena
4 months ago

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

#10 @swissspidy
4 months ago

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

#11 @scruffian
4 months ago

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.

#12 @scruffian
4 months ago

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 ticket was mentioned in PR #6118 on WordPress/wordpress-develop by @scruffian.


4 months ago
#13

  • Keywords has-patch added; needs-patch removed

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

#15 @youknowriad
4 months ago

@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.

@swissspidy commented on PR #6118:


4 months ago
#16

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

#17 @swissspidy
4 months ago

@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.

#18 @huzaifaalmesbah
4 months ago

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 ✅
https://i.ibb.co/fdRdcZ5/Screenshot-2024-02-16-at-9-09-40-AM.png https://i.ibb.co/g94F4pc/Screenshot-2024-02-16-at-9-10-04-AM.png

#19 @shailu25
4 months ago

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

Last edited 4 months ago by shailu25 (previous) (diff)

bgardner commented on PR #6118:


4 months ago
#20

Let's get this shipped in Beta 2!

This ticket was mentioned in Slack in #core-test by costdev. View the logs.


4 months ago

#22 @swissspidy
4 months ago

  • Owner set to swissspidy
  • Resolution set to fixed
  • Status changed from new to closed

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.

@swissspidy commented on PR #6118:


4 months ago
#23

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

#24 @azaozz
4 months ago

  • Keywords 2nd-opinion added; has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

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...

#25 @swissspidy
4 months ago

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.

#26 @swissspidy
4 months ago

  • Keywords needs-testing 2nd-opinion removed
  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.