[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