Style and JS URLs for some blocks are broken when using WP outside of the current prefix

[pgpagely]

Both CSS and JS URLs are totally broken for some of the newer blocks (the most obvious one being the navigation block in the 2022 theme) when WP core is outside of the current directory in a different prefix.

The issue happens because of the use of realpath() when trying to detect these paths which results in $is_core_block being false and then generating a weird URL because of that.

The simplest reproduction case is as follows:

• Install WP 5.9.1
• Execute mv wp-includes ../wp-includes-test
• Execute ln -s ../wp-includes-test wp-includes
• The navigation styles/JS will now be broken on the 2022 theme

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, we have the use the following to make things work:

add_filter("block_type_metadata", function ($meta) {
    if (!empty($meta["file"])) {
        $meta["file"] = preg_replace("#/wordpress-versions/[0-9.]+/#", ABSPATH, $meta["file"]);
    }
    return $meta;
});

If we don't do this then an example URI that is generated for one of the styles is this:

/wp-content/plugins/wordpress-versions/5.9/wp-includes/blocks/navigation/view.min.js?ver=3776ea67846b3bb10fe8f7cdd486b0ba

[pgpagely]

An additional finding is that if the gutenberg plugin is enabled then the following hack is needed so that the view.min.js URL is not broken (with gutenberg disabled only the hack in the original message is needed):

add_filter("script_loader_src", function ($src) {
    return preg_replace("#/wp-includes/wordpress-versions/[0-9.]+/#", "/", $src);
});

[Mamaduka]

I was able to reproduce the issue.

Based on my quick tests, the issue is fixed if I update the following code to use realpath.

$wpinc_path_norm = wp_normalize_path( realpath( ABSPATH . WPINC ) );

Cc. @aristath and @gziolo, since you're more familiar with this part of the codebase.

[pgpagely]

I can confirm this looks like it fixes the issue on our side when applied like this as well. It would be great to get this out in the next maintenance release if it is passing tests because right now it is a breaking change as far as I can tell.

[gziolo]

@Mamaduka, it looks like there are 3 places where we should wrap filepaths with realpath.

Let's test the patch attached and plan to land it soon.

…rectory

Trac ticket: [](https://core.trac.wordpress.org/ticket/55311)

…rectory

Trac ticket: [](https://core.trac.wordpress.org/ticket/55311)

Committed with https://core.trac.wordpress.org/changeset/52939.

[mikeschroder]

Just tested and can verify this improves things when applied to the 5.9 branch.

Do you think it'd be a good candidate for backport for the 5.9.3 release?

[SergeyBiryukov]

Looks like this was committed in [52939], though the commit is not linked here, probably due to a Trac glitch.

Moving for 5.9.3 consideration, per comment:12.

[audrasjb]

Alrighty, I'm going to backport this one to branch 5.9 now.

[audrasjb]

In 53019:

Editor: Fix broken asset URLs when using WP outside of the regular directory

Both CSS and JS URLs were totally broken for some of the newer blocks (e.g. the navigation block in the 2022 theme) when WP core is outside of the current directory using a different prefix.

Props gziolo, SergeyBiryukov, pgpagely, Mamaduka.
Merges [52939] to the 5.9 branch.
Fixes #55311.