test_get_block_editor_settings_theme_json_settings failing

[SirLouen]

In 6.4.5 it passed this test
test_get_block_editor_settings_theme_json_settings
Thereafter, it has been failing until now.

If I comment line 317 in src/wp-includes/block-editor.php

$wp_scripts->registered = $current_wp_scripts->registered;

Tests go through.

This issue came to me because this test was failing in this PR:
​https://github.com/WordPress/wordpress-develop/pull/8509

But I can't see correlation

Then I went into trunk in my dev environment, and I still failing.

But I see other PRs and they are not failing on this specific test.

I need someone else to test this and report back.

[SirLouen]

Doing some extra tests:

Checking this PR:
​https://github.com/WordPress/wordpress-develop/pull/8514
Its passing ALL the unit tests

Environment

• WordPress: 6.8-beta2-59971-src
• PHP: 8.2.28
• Server: nginx/1.27.4
• Database: mysqli (Server: 8.4.4 / Client: mysqlnd 8.2.28)
• Browser: Chrome 134.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.1
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Steps to Reproduce

Setup using the same premises as the ones used in the PR:

> git clone --depth 1 -b editor/update-path-based-urls https://github.com/SainathPoojary/wordpress-develop.git
> npm install
> npm run build:dev
> npm run env:start
> npm run env:install
> npm run test:php -- --filter test_get_block_editor_settings_theme_json_settings

Result:

Warning:       Your XML configuration validates against a deprecated schema.
Suggestion:    Migrate your XML configuration using "--migrate-configuration"!

E                                                                   1 / 1 (100%)

Time: 00:00.209, Memory: 189.00 MB

There was 1 error:

1) Tests_Blocks_Editor::test_get_block_editor_settings_theme_json_settings
Attempt to read property "registered" on null

/var/www/src/wp-includes/block-editor.php:317
/var/www/src/wp-includes/block-editor.php:625
/var/www/tests/phpunit/tests/blocks/editor.php:474

ERRORS!
Tests: 1, Assertions: 0, Errors: 1.

Additional data

I've tried doing a regular npm run test:php with same results to this test in my environment
The equivalent environment in Github is this, for the PR I'm using for the example
​https://github.com/WordPress/wordpress-develop/actions/runs/13882352022/job/38842584755?pr=8514

And this are the results in my computer:

WARNINGS!
Tests: 25486, Assertions: 92395, Warnings: 86, Skipped: 35.

Which happen to be the same results as the PR test

For some reason, I can't understand, my PR is doing different tests:

1. First the number is different: 25491 vs 25486

In the OP branch (patch/63086)

ERRORS!
Tests: 25491, Assertions: 92454, Errors: 44, Failures: 26, Warnings: 81, Skipped: 34.

In OP trunk: Same errors (less tests, beacuse in patch/63086 there are some extra tests)

But now dropping the patch/63086 in the https://github.com/SainathPoojary/wordpress-develop.git cloned repo the results are SIGNIFICANTLY different in terms of errors:
> gh pr checkout 8509

ERRORS!
Tests: 25491, Assertions: 92393, Errors: 1, Failures: 26, Warnings: 86, Skipped: 35.

I also dropped the same tests downloading clean repos from WordPress and even from my own repo and results were identical.

Not even after doing npm run env:reset I could drop the Errors: 44. The only way I found to "reestablish" the thing was downloading the repo and setting it again from scratch.

I'm not sure if all these tests are correlated somehow. I don't feel confident at this point because I can't find a reliable way to "restore" my environment without having to destroy it completely and restore it from a new clone.

Update 1

Got the difference between the Errors: 44 and the Errors: 1 part, and its completely unrelated with the original report.

Someone suggested me some long time ago to add this to the file tools/local-env/php-config.ini because otherwise xdebug did not work with npm run env:start --debug

xdebug.client_port=9003
xdebug.start_with_request=yes
xdebug.discover_client_host=yes

It seems it was covered back in the day with a different perspective 49953 but never progressed. Now its obsolete after the ​upgrade to XDebug 3

The reality is that the file is being tracked in git, so it was kind of weird, but since it worked, I never changed this. After some research according to the latest XDebug 3 docs, it seems that start_with_request is fine but the discover_client_host could be the culprit in all this story. I'm going to do a follow up on this report 49953 and leave this topic closed here.

So now that one of the two mysteries have been solved I can focus on why the test_get_block_editor_settings_theme_json_settings is failing on its own.

The issue comes from a not registered script for this specific unit test test_get_block_editor_settings_theme_json_settings making to fail because of an early error. With this patch, the test is passing.

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

[SirLouen]

Testing instructions are pretty straightforward:
Run the test
npm run test:php -- --filter test_get_block_editor_settings_theme_json_settings

Maybe @desrosj that was the original creator of this test, would like to review this