Opened 2 years ago
Last modified 2 years ago
#56859 new defect (bug)
Blocks: register_block_script_handle() does not account for symlinks
Reported by: | cr0ybot | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 6.0.3 |
Component: | Editor | Keywords: | |
Focuses: | Cc: |
Description
I love the fix added by #55513 and #54647 to detect if a block is being registered from a theme and to alter the enqueued URI appropriately. However, the way that a theme block is detected does not take symlinks into account. I have all of my custom themes/plugins in one location in my file system, and I symlink the folders I'm working on into a local WP install. I imagine there are other scenarios where a symlink might be used for theme folders as well.
The output of wp_normalize_path( get_theme_file_path() )
is the location of my local WP install:
/Users/coryhughart/Dev/web/local/website/app/public/wp-content/themes/website-theme
The output of wp_normalize_path( realpath( dirname( $metadata['file'] ) . '/' . $script_path ) )
is the original path to the theme outside of the WP install:
/Users/coryhughart/Dev/Blackbird/Client/website.com/website-theme/dist/blocks/hero/script.js
Obviously symlink resolution is part of what realpath
does. Is there a similar function/solution that could expand the path without resolving symlinks? Or is symlinking outside the scope of what is expected in a WordPress environment?
Prior to the update that allows block registration in themes, I had been filtering
plugins_url
but also checking for symlinks withis_link()
andreadlink()
. This doesn't really solve for expanding the path though.Here's that filter for reference. It's a bit of a blunt instrument, but it works.