register_core_block_style_handles() does not enqueue styles on Windows OS

[wildworks]

Originally reported in the Gutenberg repository: ​https://github.com/WordPress/gutenberg/issues/52199

This problem only occurs when WordPress itself is running on the Windows host OS; when the WordPress repository is running via npm script, WordPress is running on Docker (on Ubuntu), so this problem should not be reproducible. Running the built source or a released package (such as the Beta3 version) in a local environment on a Windows OS would reproduce this problem.

This function uses the glob function to locate CSS files under wp-includes/blocks. In this case, $files variable has the following value on Windows OS:

array(
  // ... 
  "D:\_local\test\wp6.3\app\public\wp-includes\blocks/archives/editor.min.css"
  "D:\_local\test\wp6.3\app\public\wp-includes\blocks/archives/style.min.css"
  // ... 
);

Note the mix of forward slash and backslash as path separators.

On the other hand, the $path in $register_style function has the following value:

"D:\_local\test\wp6.3\app\public/wp-includes/blocks/archives/editor.min.css"

"D:\_local\test\wp6.3\app\public/wp-includes/blocks/archives/style.min.css"

Comparing with the value that the $files array has, you can see that some path separators are different. As a result, the check by in_array( $path, $files, true ) will be false and the style will not be enqueued.

We probably need to unify the path separator characters in some way, as I expect this problem to occur on all Windows OS.

[costdev]

Hi @wildworks, thanks for opening this ticket!

• As this function was introduced during the 6.3 cycle in [56044], milestoning for 6.3 for visibility and setting the Version property to trunk.
• Adding needs-testing so this can be reproduced by a member of the Test team. Testing instructions can be found ​here.
• Note to testers: You may need to change ​this line to $files = false; // Just for testing..
• Pinging @spacedmonkey who worked on this one. Looks like wp_normalize_path() is needed here.

[wildworks]

patch_58711.diff

[wildworks]

I have created a patch to resolve this issue. (This is my first time creating a diff patch file, so sorry if I'm wrong) At least in my environment, this patch seems to fix the problem.

[costdev]

Updated patch_58711.diff without array_map().

[costdev]

Myself and @wildworks discussed the issue and did some additional testing.

I've submitted an updated patch 58711-without-array_map.diff which uses wp_normalize_path() on the path passed to glob(), rather than running array_map() on the result.

[kafleg]

This patch worked for me.
​https://wordpress.slack.com/archives/C02RQBWTW/p1688525369575679

[kafleg]

Test Report

This patch worked for me.

Patch tested: https://core.trac.wordpress.org/attachment/ticket/58711/58711-without-array_map.diff

Environment

• OS: Windows 11
• Web Server: Laragon Local Server
• PHP: 8.1.2
• WordPress: 6.3-Beta-3
• Browser: Edge and Chrome
• Theme: Twenty Twenty Three
• Active Plugins:
  • None

Actual Results

• ✅ Issue resolved with patch.

[costdev]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: https://core.trac.wordpress.org/raw-attachment/ticket/58711/58711-without-array_map.diff

Steps to Reproduce or Test

1. In a Windows environment, ensure that the Navigation block is in the template.
2. Create a post with some blocks.
3. 🐞 View the post on the frontend.
4. Apply the patch.
5. Change ​this line to $files = false; // Just for testing.
6. Refresh the post on the frontend.

Expected Results

When reproducing a bug:

• ❌ The Navigation block and others have incorrect styling.

When testing a patch to validate it works as expected:

• ✅ The Navigation block and others have the correct styling.

Environment

• WordPress: 6.3-beta3
• OS: Windows
• PHP: 8.1.9
• Server: nginx/1.16.0 (using Local)
• Database: mysqli (Server: 8.0.16 / Client: mysqlnd 8.1.9)
• Browser: Chrome 114.0.0.0 (Windows 10/11)
• Theme: Twenty Twenty-Three 1.1
• MU-Plugins: None activated
• Plugins: WordPress Beta Tester 3.5.0

Actual Results

When reproducing a bug/defect:

• ❌ The Navigation block and others had incorrect styling.

When testing the bugfix patch:

• ✅ The Navigation block and others have the correct styling.

[wildworks]

Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: https://core.trac.wordpress.org/attachment/ticket/58711/58711-without-array_map.diff

Environment

• OS: Windows 11
• Web Server: Nginx
• PHP: 8.1.9
• WordPress: WordPress 6.3-beta3
• Browser: Chrome 114.0.5735.199, Firefox 115.0
• Theme: Twenty Twenty Two, Twenty Twenty Three
• Active Plugins: WordPress Beta Tester 3.5.0

Actual Results

• ✅ Issue resolved with patch.

[costdev]

With three testers reporting that 58711-without-array_map.diff resolves this Windows-only issue in their environments, I'm removing needs-testing and adding this for commit consideration.

[mukesh27]

@costdev could you open PR so we can check performance number?

Previously, this function did not normalize paths before using glob() or registering styles. This led to a mixture of forward-slashes and back-slashes in Windows environments.

This change uses wp_normalize_path() to ensure Windows compatibility.

[costdev]

@mukesh27 See ​PR 4792.

[audrasjb]

In 56136:

Editor: Normalize paths in register_core_block_style_handles().

Previously, this function did not normalize paths before using glob() or registering styles. This led to a mixture of forward-slashes and back-slashes in
Windows environments.

This change uses wp_normalize_path() to ensure Windows compatibility.

Props wildworks, costdev, kafleg, mukesh27.
Fixes #58711.

[spacedmonkey]

@audrasjb Similar code has existed in core for a while. See ​https://github.com/WordPress/wordpress-develop/commit/f034bc832eb091079e4130f6a206b4f496766796. Does this change need to be backported?

[audrasjb]

Replying to spacedmonkey:

@audrasjb Similar code has existed in core for a while. See ​https://github.com/WordPress/wordpress-develop/commit/f034bc832eb091079e4130f6a206b4f496766796. Does this change need to be backported?

Need to be backported to what? Gutenberg? Sorry but could you please clarify?

Fixed in https://core.trac.wordpress.org/changeset/56136