[wp-trac] [WordPress Trac] #60352: Fix the architectural design of `/wp-includes/blocks/index.php`

WordPress Trac noreply at wordpress.org
Fri Jan 26 00:29:55 UTC 2024


#60352: Fix the architectural design of `/wp-includes/blocks/index.php`
--------------------------+---------------------
 Reporter:  azaozz        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  6.5
Component:  General       |     Version:  5.5
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by azaozz):

 I'm unsure if `/wp-includes/blocks/index.php` or any of the other files in
 `/wp-includes/blocks/` were meant to be accessible by the web server and
 be loaded directly in the browser. Seems no, but these seem written in a
 way that would suggests this? As far as I see these files should only be
 included on REST requests, but that need confirmation.

 There are other design inconsistencies in that file:
 - It doesn't seem to make sense to do `define( 'BLOCKS_PATH', ABSPATH .
 WPINC . '/blocks/' );` there. It throws errors when `ABSPATH` or `WPINC`
 are not defined. Also most constants in WP are defined in `default-
 constants.php`, don't see a reason why this one is not defined there.

 - Despite that `BLOCKS_PATH` is defined when `require-dynamic-blocks.php`
 is loaded, the constant is not used in the latter:
 https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 includes/blocks/require-dynamic-blocks.php. Doesn't seem to make sense to
 define it and not use it?

 - Ideally there will be no PHP code that runs in the global scope in any
 of the files in `/wp-includes`. This is true for nearly all of them,
 except for files in `/wp-includes/blocks`. Thinking these files need to be
 factored to follow the basic design principles of the rest of WP.
   - If they must be "entry points" they should check if WP has been
 bootstrapped and bootstrap it if not.
   - If they were intended only for use in other files, or only for use in
 the REST API, the loose/global code in them (including calls to
 `add_action()`, `add_filter()`, etc.) should be wrapped in conditionals
 ensuring these run only when appropriate.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60352#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list