[wp-trac] [WordPress Trac] #57161: When using a child theme, blocks registered in the parent theme have the wrong asset file path which prevents styles from loading

[WordPress Trac]

#57161: When using a child theme, blocks registered in the parent theme have the
wrong asset file path which prevents styles from loading
---------------------------+-----------------------------
 Reporter:  jmaasonoffice  |      Owner:  (none)
     Type:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Themes         |    Version:  6.1.1
 Severity:  normal         |   Keywords:
  Focuses:                 |
---------------------------+-----------------------------
 I am registering blocks in a theme using `register_block_type()` pointing
 to a block.json. This works fine.

 I then made a child theme and noticed that in the frontend the styles are
 loaded but in the backend all my blocks' styles are missing. This is
 because the URI for the assets includes the absolute file path, e.g.
 `http://localhost/wp-content/plugins/var/www/html/wp-
 content/themes/parent/block/style.css`. It worked in the frontend, because
 WordPress was inlining the styles which made correct use of the absolute
 file path.

 The root cause, as far as I can tell, is that
 [https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/blocks.php#L234 blocks.php] makes the assumption that all blocks
 are registered in the currently active theme. In the case of a child
 theme, this is not necessarily true. Then the check if the path starts
 with the current theme's path is faulty.

 For a bit of context: We want to deliver themes to customers, but keep the
 option of making individual modifications. For that we plan to use child
 themes, for example to add additional blocks.

 For now, we can work around this issue by registering the blocks styles
 separately and passing the registered style handle instead of the file
 path. We can achieve this by hooking into `block_type_metadata` and
 replacing the `$metadata['style']` and `$metadata['editorStyle']` with the
 registered handle.

 However, I believe that this current behavior is confusing and that the
 code in [https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/blocks.php#L234 blocks.php] should probably also check for the
 case that a child theme is active and the blocks are registered in the
 parent theme.

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