WordPress.org

Make WordPress Core

Opened 4 weeks ago

Closed 4 weeks ago

Last modified 3 weeks ago

#54401 closed defect (bug) (fixed)

Fix fatal error in /wp-admin/load-styles.php

Reported by: Mamaduka Owned by: desrosj
Milestone: 5.9 Priority: highest omg bbq
Severity: normal Version: trunk
Component: Themes Keywords: has-patch commit
Focuses: Cc:

Description

The assets in the dashboard aren't loading correctly when SCRIPT_DEBUG is set to false. A fatal error causes it in /wp-admin/load-styles.php.

How to reproduce

  • Enable debugging in load-styles.php file by settings error_reporting( -1 );
  • In WP directroy run php wp-admin/load-styles.php
  • Observe that console displayes following error
Fatal error: Uncaught Error: Call to undefined function get_theme_file_path() in ~/Projects/gutenberg/wp-includes/class-wp-theme-json-resolver.php:366

The problem is that get_theme_file_path and related functions introduced in WP 4.7 are located in link-template.php instead of theme.php. The former file isn't included in load-styles.php.

Let's move get_theme_file_path and similar functions into the theme.php file.

Change History (27)

This ticket was mentioned in Slack in #core-editor by mamaduka. View the logs.


4 weeks ago

#2 @audrasjb
4 weeks ago

  • Milestone changed from Awaiting Review to 5.9

Worth noting that only define('CONCATENATE_SCRIPTS', false); fixes the issue on my side.

Concerning the issue, we could either relocate get_theme_file_path and related functions into theme.php, or include link-template.php in load-styles.php. I'm testing both hypothesis right now.

Last edited 4 weeks ago by audrasjb (previous) (diff)

#3 @audrasjb
4 weeks ago

#54402 was marked as a duplicate.

This ticket was mentioned in PR #1846 on WordPress/wordpress-develop by Mamaduka.


4 weeks ago

  • Keywords has-patch has-unit-tests added

Fixes fatal error in /wp-admin/load-styles.php by relocating get_theme_file_path and related functions. PR also moves tests for these functions into the theme directory.

/cc @@audrasjb

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

#5 @prbot
4 weeks ago

Mamaduka commented on PR #1846:

I'm not sure why relocating the tests will cause them to fail.

#6 @Mamaduka
4 weeks ago

@audrasjb, I tried including link-template.php in load-styles.php, but this caused a different error:

Fatal error: Cannot redeclare home_url() (previously declared in ~/Projects/trunk/src/wp-admin/includes/noop.php:84) in ~/Projects/trunk/src/wp-includes/link-template.php on line 3279

I think relocating the functions is the best option for now.

#7 @desrosj
4 weeks ago

  • Priority changed from normal to highest omg bbq

I'm changing this to the highest priority because the admin is completely broken.

For reference, the changeset that introduced this issue is [52049].

I've only just started investigating, but I currently do not yet support moving these functions.

It looks like [52049] changes from using self::get_file_path_from_theme() to get_theme_file_path(). But it seems that there are plenty of other calls throughout the file to self::get_file_path_from_theme().

I'd like to understand why this method can no longer be used, and why functions like get_template_directory(), which are included in theme.php already (and `get_theme_file_path() uses anyway), are not able to be used here.

#8 @desrosj
4 weeks ago

Relocating these functions could have some very bad ripple affects. The most obvious one is any plugin or theme currently including link-template.php in order to use these functions will break. There are going to be other less obvious consequences as well.

#10 @desrosj
4 weeks ago

Is there any reason why my PR above would not fix the issue?

It does not take into account parent/child themes, but I don't know if I'm missing something.

If a child theme does not have a theme.json file, it will be false, and if it does and the parent does not, it will be true. I think that would be OK though?

#11 follow-up: @mukesh27
4 weeks ago

I just test PR and it working fine.

The PR is not fully passed all the tests.

#12 in reply to: ↑ 11 @desrosj
4 weeks ago

Replying to mukesh27:

I just test PR and it working fine.

Can you clarify which PR you tested? Pretty sure that you mean the one I created, but there are two here. So just want to be clear.

Also, how did you test? Knowing the steps taken to test is really important to know which scenarios have been verified.

The PR is not fully passed all the tests.

Just merged the latest from trunk into my PR and pushed again. The test failures were unrelated.

#13 @desrosj
4 weeks ago

I've found the original PR that made this change in the Gutenberg repo.

I see some discussion about removing get_theme_file_path(), but no reasoning why it was added to theme_has_support().

#14 @hellofromTonya
4 weeks ago

Test Report

Env:

  • localhost: wp-env
  • OS: macOS Big Sur
  • Browser: Chrome and Firefox
  • WordPress: trunk
  • Patch: PR 1847

Results:

  • Before patch => Able to reproduce fatal error
  • Apply patch => resolves the fatal error

@desrosj Your PR works ✅

#15 @jorbin
4 weeks ago

  • Keywords commit added

https://github.com/WordPress/wordpress-develop/pull/1847/files looks good to me and feels like a much better solution than moving functions around. Thank you @desrosj for digging in and finding the changeset that broke things.

#16 @desrosj
4 weeks ago

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

In 52077:

Themes: Avoid fatal error loading admin styles when SCRIPT_DEBUG is false.

This removes the use of get_theme_file_path() within WP_Theme_JSON_Resolver in favor of the similar get_file_path_from_theme() method.

The former is found within wp-includes/link-template.php, which is not currently loaded when load-styles.php attempts to load the necessary styles. self::get_file_path_from_theme() was used previously, but this was changed in [52049].

Props Mamaduka, audrasjb, hellofromTonya, jorbin, desrosj.
Fixes #54401. See #54336.

#17 @desrosj
4 weeks ago

I've rebuilt the nightly build after [52077]. If everyone could just double confirm there are no issues with the fix, that would be great!

#18 @desrosj
4 weeks ago

Also, I just realized that I omitted @mukesh27 in the changeset. Apologies, that was not intentional!

#19 @mukesh27
4 weeks ago

@desrosj Ok.

#20 @desrosj
4 weeks ago

I've also created GB-36359 as a follow up.

#22 @pbiron
4 weeks ago

FYI: can confirm that I was seeing the problem when running last night's nightly (5.9-alpha-52070) but all is working fine with the rebuilt nightly @desrosj just did (5.9-alpha-52077).

Thank you!

#23 @iandunn
4 weeks ago

  • Keywords has-unit-tests removed

Removing has-unit-tests since the bot mistakenly added it.

Is there a practical way to add some?

This ticket was mentioned in PR #1867 on WordPress/wordpress-develop by Mamaduka.


4 weeks ago

The current method was only checking the stylesheet directory for the theme.json existence. PR updates logic to check both parent and child themes.

/cc @desrosj @hellofromtonya

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

#25 @desrosj
3 weeks ago

In 52181:

Themes: Check both parent and child themes for a theme.json file.

This updates WP_Theme_JSON_Resolver::theme_has_support() to properly check for a theme.json file in both parent and child themes when determining whether a theme supports block templates.

Follow up to [52077].

Props Mamaduka.
Fixes #54401.

#27 @prbot
3 weeks ago

Mamaduka commented on PR #1867:

Thanks, @desrosj. I will try to follow up with unit tests as soon as possible.

Note: See TracTickets for help on using tickets.