[wp-trac] [WordPress Trac] #56859: Blocks: register_block_script_handle() does not account for symlinks

[WordPress Trac]

#56859: Blocks: register_block_script_handle() does not account for symlinks
--------------------------+-----------------------------
 Reporter:  cr0ybot       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:  6.0.3
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 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?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56859>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform