When inserting an image into a post, the values in `wp.media.controller.Library` should not default to linking the image when no user settings are present.
The default display setting value for `link` is now `none`. User settings persist and will override or confirm this value based on user actions.
Props liljimmi, janhenckens, eherman24, wonderboymusic.
Fixes#31467.
git-svn-id: https://develop.svn.wordpress.org/trunk@33729 602fd350-edb4-49c9-b593-d223f7449a82
Since the value of the filter is passed through `sprintf()` it's important to note that any filtered output needs to contain the expected specifiers.
See #31315.
git-svn-id: https://develop.svn.wordpress.org/trunk@33717 602fd350-edb4-49c9-b593-d223f7449a82
This allows the `count` property to reflect the pre-delete state of affairs,
rather than always being 0.
Props nicholas_io.
Fixes#33485.
git-svn-id: https://develop.svn.wordpress.org/trunk@33711 602fd350-edb4-49c9-b593-d223f7449a82
[32523] introduced the `$public_only` parameter to `count_user_posts()`. That
changeset was supposed to pass `$public_only` to the 'get_usernumposts' filter
at the end of the function, but only the documentation was modified, not the
filter itself.
This changeset also fixes an incorrect variable name in the docblock for
the same filter.
Props swisspidy, tmatsuur.
Fixes#33481 for trunk.
git-svn-id: https://develop.svn.wordpress.org/trunk@33710 602fd350-edb4-49c9-b593-d223f7449a82
Add a query var, `title`, that allows you to query posts by `post_title`. To accomplish this now, you have to do something like:
{{{
$tacos = get_posts( [
'post_type' => 'taco',
's' => $name,
'exact' => true,
'sentence' => true,
'post_status' => 'publish',
'fields' => 'ids',
'posts_per_page' => 1
] );
}}}
Adds unit tests.
Fixes#33074.
git-svn-id: https://develop.svn.wordpress.org/trunk@33706 602fd350-edb4-49c9-b593-d223f7449a82
The "month" isn't really a month. It's a WordPress Month. As the docs make clear, it's not about accuracy as much as it about convenience. This adds a missing step in the time convenience constants.
Props egill
Fixes#33397
git-svn-id: https://develop.svn.wordpress.org/trunk@33698 602fd350-edb4-49c9-b593-d223f7449a82
Reverts unnecessary change in [32602] since `array_key_exists()` does actually work with `ArrayIterator` objects.
See #32474.
Fixes#33442.
git-svn-id: https://develop.svn.wordpress.org/trunk@33696 602fd350-edb4-49c9-b593-d223f7449a82
As noted in the description, returned keys being set is dependent on the existence of those keys in user meta at the point where `_get_additional_user_keys()` is called in `wp_update_user()`.
Fixes#29120.
git-svn-id: https://develop.svn.wordpress.org/trunk@33687 602fd350-edb4-49c9-b593-d223f7449a82
As of [32484], `wp_dropdown_categories()` uses the `$value_field` value to
decide whether a given `<option>` should be 'selected'. However, `$value_field`
can refer to a value that is a string, such as a category's slug. This causes
problems when doing a loose comparison (`==`) with the value of the `'selected'`
parameter, which defaults to `0`, because when doing a loose comparison
between an integer and a string, PHP will cast the string to an integer. This
creates false matches, resulting in `<option>` elements getting a 'selected'
attribute incorrectly.
We address the issue by casting the comparison values to strings, and then
using the strict comparison operator `===`.
Fixes#33452 for trunk.
git-svn-id: https://develop.svn.wordpress.org/trunk@33681 602fd350-edb4-49c9-b593-d223f7449a82
* 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.
git-svn-id: https://develop.svn.wordpress.org/trunk@33666 602fd350-edb4-49c9-b593-d223f7449a82
