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
Old browsers didn't support the HTML placeholder attribute. For a number of years, `<label>` elements have been used in a few places in WordPress to emulate placeholders. It's time to improve semantics and interaction, use real placeholders when possible, and clean up some JavaScript.
- Quick Draft widget: it now uses visible `<label>` elements and a real `placeholder` attribute
- removes the related JavaScript
- Post title:
- keeps the "prompt" label for backwards compatibility
- improves the JavaScript to make the "prompt" label stay visible on focus and disappear when typing, like real placeholder do
- changes the post "prompt" text from "Enter title here" to "Add title" for consistency with the Block Editor
- cleans-up some CSS
Props Cheffheid, afercia.
Fixes#42390.
Built from https://develop.svn.wordpress.org/trunk@44896
git-svn-id: http://core.svn.wordpress.org/trunk@44727 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The block editor needs to duplicate the classic meta box behaviour, so it can extract the registered meta boxes, and import them into the block editor.
To match the classic editor behaviour as closely as possible, this moves the relevant code from the classic editor, into a new function, so it can be called by both.
Merges [43837] from the 5.0 branch to trunk.
Props pento, peterwilsoncc.
Fixes#45172.
Built from https://develop.svn.wordpress.org/trunk@44214
git-svn-id: http://core.svn.wordpress.org/trunk@44044 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When meta boxes are registered, they can use the `__back_compat_meta_box` and `__block_editor_compatible_meta_box` flags, to show whether this registration just exists for if the classic editor is loaded, and whether this meta box is compatible with the block editor.
When a meta box marks itself as incompatible with the block editor, and `WP_DEBUG` is enabled, a warning will show inside that meta box in the classic editor.
As all core meta boxes have been recreated in the block editor, they can be marked with the `__back_compat_meta_box` flag.
Merges [43779] from the 5.0 branch to trunk.
See #45112.
Built from https://develop.svn.wordpress.org/trunk@44132
git-svn-id: http://core.svn.wordpress.org/trunk@43962 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
Built from https://develop.svn.wordpress.org/trunk@43571
git-svn-id: http://core.svn.wordpress.org/trunk@43400 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The WPCS `WordPress.WhiteSpace.PrecisionAlignment` rule throws warnings for a bunch of code that will likely cause issues for `wpcbf`. Fixing these manually beforehand gives us better auto-fixed results later.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42228
git-svn-id: http://core.svn.wordpress.org/trunk@42057 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This pattern occurs a handful of times across the codebase:
`<div class="foo<?php if ( $bar ) { echo ' baz'; } ?>">`
Unfortunately, it doesn't really play nicely with `phpcbf`, so all instances need to be removed in preperation for auto code formatting.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42217
git-svn-id: http://core.svn.wordpress.org/trunk@42046 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Fix keeping text selection and scroll position when there are embeds from URL.
- Add editor setting to disable keeping selection and scroll position.
- Remove dependency on Underscore.js.
- Fix error in the Text widget editor.
Props biskobe.
Fixes#42059, see #40854.
Built from https://develop.svn.wordpress.org/trunk@41783
git-svn-id: http://core.svn.wordpress.org/trunk@41617 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The super admin on multisite as well as the administrator on non-multisite both have this capability already. For custom post types using different capabilities this change ensures that only users with that capability have permissions.
Fixes#39059. See #37616.
Built from https://develop.svn.wordpress.org/trunk@39539
git-svn-id: http://core.svn.wordpress.org/trunk@39479 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WordPress has supported custom page templates for over 12 years, allowing developers to create various layouts for specific pages.
While this feature is very helpful, it has always been limited to the 'page' post type and not was not available to other post types.
By opening up the page template functionality to all post types, we continue to improve the template hierarchy's flexibility.
In addition to the `Template Name` file header, the post types supported by a template can be specified using `Template Post Type: post, foo, bar`.
When at least one template exists for a post type, the 'Post Attributes' meta box will be displayed in the back end, without the need to add post type support for `'page-attributes'`. 'Post Attributes' can be customized per post type using the `'attributes'` label when registering a post type.
Props johnbillion, Mte90, dipesh.kakadiya, swissspidy.
Fixes#18375.
Built from https://develop.svn.wordpress.org/trunk@38951
git-svn-id: http://core.svn.wordpress.org/trunk@38894 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changes the global `$wp_post_types` to an array of `WP_Post_Type` objects. `WP_Post_Type` includes methods to handle post type supports, rewrite rules, meta boxes, hooks, and taxonomies.
Each post type argument becomes a property of `WP_Post_Type`.
Props swissspidy, flixos90.
Fixes#36217.
Built from https://develop.svn.wordpress.org/trunk@37890
git-svn-id: http://core.svn.wordpress.org/trunk@37831 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The media library can contain files which aren't attached yet. When attaching a file you currently get "Media attachment reattached.", or the opposite "Media attachment detached.". That's redundant and can be inaccurate. It's also not easy to translate in some languages.
This change generalizes the strings to refer to a "media file" instead.
Props SergeyBiryukov, ocean90, netweb.
Fixes#36089.
Built from https://develop.svn.wordpress.org/trunk@36887
git-svn-id: http://core.svn.wordpress.org/trunk@36854 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Move the array processing to a new function, `_wp_post_revision_data()`.
* Make both functions accept a post array or a `WP_Post` object.
* Always apply the `_wp_post_revision_fields` filter and pass the post data to it.
Fixes#13382.
Built from https://develop.svn.wordpress.org/trunk@36659
git-svn-id: http://core.svn.wordpress.org/trunk@36626 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Shortlinks had their day in the popular usage sun before all these services moved to their own shorteners and running your own custom one became a lot easier. Shortlinks are still useful in some contexts, such as analytics or when links need to be shared verbally or copied down by hand.
If any filters are hooked onto `pre_get_shortlink` or `get_shortlink` and produce a non-empty value (with an exception described below), the button will magically reappear. This allows any custom shortlinks to keep the button without hiccups.
If you're in need of the default shortlinks, the fastest way to reenable them is `add_filter( 'pre_get_shortlink', '__return_false' )`. Note that it must return false in order to continue on to the rest of `wp_get_shortlink()`.
props grvrulz for the initial patch.
fixes#33495.
Built from https://develop.svn.wordpress.org/trunk@34556
git-svn-id: http://core.svn.wordpress.org/trunk@34520 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Discussion: Post Type stops supporting comments, but comments and/or pings are open on a post.
* Comments: Post is published or private, the post type has stopped supporting comments, but comments and/or pings are open on a post.
Currently, there is no way to toggle those settings off.
Props couturefreak, wonderboymusic, rachelbaker.
Fixes#28080.
Built from https://develop.svn.wordpress.org/trunk@34461
git-svn-id: http://core.svn.wordpress.org/trunk@34425 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Introduce `is_post_type_viewable( $post_type_object )`
* Separate the HTML bits from the translatable bits in the `post` messages array in `edit-form-advanced.php`
* Don't show certain UI pieces when a post is not viewable on the front end
When a custom post type item is not viewable on the front end, we don't want to show links to View it (on the front end) all over the admin. We also want to hide the Preview link, et al. We also want our admin messages to not contain said links.
Custom post types with `public_queryable` set to `false` are not viewable on the front end.
`'page'` is viewable on the front end, but `'page'` is a `_builtin` type, and `public_queryable` is set to `false` when it is registered - see `WP::parse_request()` for when `public_queryable` gets used.
This is confusing, but also somewhat straightforward: to determine if a post type is viewable on the front end, we can check one way for `_builtin => true` and another way for `_builtin => false`:
`$post_type->publicly_queryable || ( $post_type->_builtin && $post_type->public )`
If a post type is `publicly_queryable`, it's viewable. If that value is `false`, it is viewable if it's a `_builtin` type that is also `public`.
I am in search of edge cases, so this shall land.
Props wonderboymusic, DrewAPicture.
See #17609.
Built from https://develop.svn.wordpress.org/trunk@33666
git-svn-id: http://core.svn.wordpress.org/trunk@33633 1a063a9b-81f0-0310-95a4-ce76da25c4cd
