d575d70fe9
Currently, there are a number of scenarios where `is_block_editor()` (and `WP_Screen::is_block_editor`) would incorrectly indicate block editor support at different points of the loading process. Most notably, checking `is_block_editor` when hooking into the `current_screen` action will always result in `false`, even when the block editor is being loaded. This is because `is_block_editor` is not set to `true` until `edit-form-blocks.php` is included. This change adds logic to `WP_Screen` to ensure the accuracy of `is_block_editor` on block editor pages earlier in the load process. While edit screens will now be accurate 100% of the time from `current_screen` on, there are still a few edge cases where `is_block_editor` could contain an incorrect value when creating a new post. Because a `WP_Post` object is a required parameter for the `replace_editor` filter and `use_block_editor_for_post()` function, `WP_Screen` will fall back to the value returned by `use_block_editor_for_post_type()` for the post being created. To eliminate these edge cases, the `use_block_editor_for_post_type` filter can be used to return the appropriate boolean value to indicate support. Props Chouby, desrosj, aduth, johnbillion. Fixes #46195. git-svn-id: https://develop.svn.wordpress.org/trunk@45224 602fd350-edb4-49c9-b593-d223f7449a82 |
||
---|---|---|
src | ||
tests | ||
tools | ||
.editorconfig | ||
.gitignore | ||
.jshintrc | ||
.npmrc | ||
.nvmrc | ||
.travis.yml | ||
appveyor.yml | ||
composer.json | ||
composer.lock | ||
Gruntfile.js | ||
jsdoc.conf.json | ||
package-lock.json | ||
package.json | ||
phpcs.xml.dist | ||
phpunit.xml.dist | ||
webpack.config.js | ||
wp-cli.yml | ||
wp-config-sample.php | ||
wp-tests-config-sample.php |