| 1 | | I'm involved in a project that is converting sites to use the Gutenberg editor. In several cases, we need to check at `init` if a particular post type is Gutenberg-enabled so that we can disable classic metaboxes and other functionality that we've re-implemented in Gutenberg components, but that is also still in use on non-Gutenberg post types. It's not possible to wait until a later action because these checks often must interact with plugins that we ourselves do not maintain, and which perform their setup at the `init` action. Ideally, `use_block_editor_for_post()` and `use_block_editor_for_post_type()` would be available at that point, which would be possible by moving them to `wp-includes`. Neither function depends on other functions that are available only in `wp-admin` (other than `use_block_editor_for_post()` relying on `use_block_editor_for_post_type()` |
| | 1 | I'm involved in a project that is converting sites to use the Gutenberg editor. In several cases, we need to check at `init` if a particular post type is Gutenberg-enabled so that we can disable classic metaboxes and other functionality that we've re-implemented in Gutenberg components, but that is also still in use on non-Gutenberg post types. It's not possible to wait until a later action because these checks often must interact with plugins that we ourselves do not maintain, and which perform their setup at the `init` action. Ideally, `use_block_editor_for_post()` and `use_block_editor_for_post_type()` would be available at that point, which would be possible by moving them to `wp-includes`. Neither function depends on other functions that are available only in `wp-admin` (other than `use_block_editor_for_post()` relying on `use_block_editor_for_post_type()` and an admin-referrer check that's gated by a query variable), so moving them to `wp-includes` seems both feasible and beneficial. |