This avoids the performance overhead of the function call every time `dirname( __FILE__ )` was used instead of `__DIR__`.
This commit also includes:
* Removing unnecessary parentheses from `include`/`require` statements. These are language constructs, not function calls.
* Replacing `include` statements for several files with `require_once`, for consistency:
* `wp-admin/admin-header.php`
* `wp-admin/admin-footer.php`
* `wp-includes/version.php`
Props ayeshrajans, desrosj, valentinbora, jrf, joostdevalk, netweb.
Fixes#48082.
Built from https://develop.svn.wordpress.org/trunk@47198
git-svn-id: http://core.svn.wordpress.org/trunk@46998 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@45224
git-svn-id: http://core.svn.wordpress.org/trunk@45033 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While intended as a playful error message, `Cheatin’ uh?` can be interpreted as insulting or accusatory in an already stressful situation. This replaces Cheatin’ with more meaningful error messages, depending on the error that occurs.
Props ElectricFeet, EricMeyer, karmatosed, dd32, BandonRandon, melchoyce for language; dmsnell for original patch; peterwilsoncc.
Fixes#38332.
Built from https://develop.svn.wordpress.org/trunk@42648
git-svn-id: http://core.svn.wordpress.org/trunk@42477 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The new format looks like "Sorry, you are not allowed to <action>.". This provides a consistent experience for all error messages related to missing permissions. It also reduces the number of similar strings and allows translators to provide a consistent style in their language.
Props ramiy, Presskopp.
Fixes#34521.
Built from https://develop.svn.wordpress.org/trunk@37914
git-svn-id: http://core.svn.wordpress.org/trunk@37855 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In get_post_type_capabilities(), make sure create_posts reflects customizations to the edit_posts capability when create_posts is not specifically set.
git-svn-id: http://core.svn.wordpress.org/trunk@22291 1a063a9b-81f0-0310-95a4-ce76da25c4cd