Block type path normalization is inconsistent (e.g. for Windows)

[flixos90]

The various block type registration functions heavily rely on wp_normalize_path() to ensure consistent path strings (e.g. replace \\ with /) on OSs like Windows. However, in some places such function calls are missing, or code is performing string operations to trim / slashes on a path before it's been sanitized with wp_normalize_path().

This was initially raised by @gziolo in ​https://github.com/WordPress/wordpress-develop/pull/8129#pullrequestreview-2642709880.

We should review those code paths and fix those problems (e.g. register_block_type_from_metadata() and related functions, WP_Block_Metadata_Registry and related functions).

• This PR aims to apply wp_normalize_path() correctly throughout block type registration.
• The accompanying tests verify the fixes.
• For WP_Block_Metadata_Registry, the approach taken is that all public methods have their inputs normalized, while the private methods expect already normalized paths (which has been included in the documentation and should be fine since those methods are private to the class).

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

[flixos90]

@gziolo @joemcgill Would be great to get your feedback on the PR. In the PR description, I point to GH workflows that show the test failures and how the new production code fixes them.

I initially milestoned this for 6.9 (since it's been around as an unreported bug for a while), but since it relates to recently landed enhancements, if you think this is close we could reconsider for 6.8. Let me know what you think.

@gziolo

Out of curiosity, do you know why in the get_block_asset_url there is realpath used in a few places, example:

​https://github.com/WordPress/wordpress-develop/blob/b45e379d214240be1c572db0b1078f5d39b7ea71/src/wp-includes/blocks.php#L95-L99

Based on git blame, you may be the best person to answer this 😂
See ​https://github.com/WordPress/wordpress-develop/commit/573581f43f63f12cc37620172432cf93745f568c and https://core.trac.wordpress.org/ticket/55311

cc @audrasjb

Based on that ticket, that same bug would currently still apply to register_block_type_from_metadata() and WP_Block_Metadata_Registry. Do we need to use realpath() on those base paths for those functions too (e.g. ABSPATH . WPINC, WP_CONTENT_DIR, WPMU_PLUGIN_DIR, etc.)?

Based on git blame, you may be the best person to answer this 😂
See ​https://github.com/WordPress/wordpress-develop/commit/573581f43f63f12cc37620172432cf93745f568c and https://core.trac.wordpress.org/ticket/55311

Intriguing discovery 🙈😃

It looks like this particular issue existed when using symlinks:

For us, we are running WP inside docker, and our WP core files exist at /wordpress-versions/5.9/ in the container, but the web root is at /httpdocs,

In addition, there were mentions in https://core.trac.wordpress.org/ticket/62140 of prior limitations when using symlinks. However, this was likely addressed in https://core.trac.wordpress.org/changeset/59730.

It looks like this particular issue existed when using symlinks:

The thing is I'm not sure whether that problem is relevant here or not. Of course, we could just go the safe route and include realpath() calls everywhere, since I don't see any harm in adding them (except that, if they are unnecessary, we add code clutter; but there would not be any notable adverse effects on the actual functionality or performance).

Should we maybe just add them to be safe? Or should we commit this as is and see if any other bug reports come up in the future?

Should we maybe just add them to be safe? Or should we commit this as is and see if any other bug reports come up in the future?

Let's proceed as is and collect more details before adding additional calls.

[flixos90]

As this is for a bug with a low-risk fix ready to commit, I'm going to include this in 6.8, also as it relates to #62267, which is being shipped in 6.8.

[flixos90]

In 59938:

Editor: Fix block type and block metadata collection registration issues on Windows due to lack of path normalization.

Props flixos90, gziolo, joemcgill.
Fixes #63027.