If a validation_callback returns a WP_Error it should give the same response format as if it returned `false`. This makes programmatically reading the validation errors better.
Props bradyvercher for initial patch.
Fixes#35028.
git-svn-id: https://develop.svn.wordpress.org/trunk@35890 602fd350-edb4-49c9-b593-d223f7449a82
In `wp_update_comment()` only check if the given `comment_post_ID` is valid if it isn’t `0`. This allows comments that were created programmatically via `wp_insert_comment()` without the (optional) `comment_post_ID` parameter to be edited.
Props subharanjan for the initial patch.
Fixes#34954
git-svn-id: https://develop.svn.wordpress.org/trunk@35853 602fd350-edb4-49c9-b593-d223f7449a82
`wp_get_object_terms()` can return a `WP_Error` object. As such, the
`get_the_terms()` cache wrapper should handle them properly. To wit:
* Don't try to map an error object to `get_term()`. Introduced in [35032].
* Don't cache an error object as taxonomy relationships. Introduced in at least [16487], maybe earlier.
Props stephenharris.
Fixes#34723.
git-svn-id: https://develop.svn.wordpress.org/trunk@35850 602fd350-edb4-49c9-b593-d223f7449a82
We rely on the `wp-image-` class to quickly find an attachment ID to add responsive image attributes.
To avoid incorrect images being displayed, do not add these attributes if the `src` does not match the
meta from the attachment ID in the class.
Props azaozz, kovshenin, joemcgill.
Fixes: #34898.
git-svn-id: https://develop.svn.wordpress.org/trunk@35820 602fd350-edb4-49c9-b593-d223f7449a82
Ensure that plugin filters apply as expected for any settings registered statically without passing in an explicit class instance to `WP_Customize_Manager::add_setting()`.
Fixes#34597.
git-svn-id: https://develop.svn.wordpress.org/trunk@35810 602fd350-edb4-49c9-b593-d223f7449a82
Previously when updating a post using wp_insert_post(), post_name was
regenerated based on post_title every time if post_name was not passed in
explicitly. This irons out the expectation that properties not passed into the
function should not be modified.
Props jason_the_adams.
Fixes#34865.
git-svn-id: https://develop.svn.wordpress.org/trunk@35800 602fd350-edb4-49c9-b593-d223f7449a82
User dropdowns in wp-admin have traditionally shown the users' display names.
However, this causes ambiguity when users share display names. To correct this,
we now show the unique user_login in parentheses after the display name.
The new `display_name_with_login` value for the `show` parameter of
`wp_dropdown_users()` enables this functionality. The default value of `show`
has not been changed, for backward compatibility, but all instances of
`wp_dropdown_users()` in core wp-admin have been switched.
This changeset also reduces some duplicated logic when assembling a user list
when `include_selected` is true.
Props krogsgard, boonebgorges.
Fixes#31251.
git-svn-id: https://develop.svn.wordpress.org/trunk@35790 602fd350-edb4-49c9-b593-d223f7449a82
The whole string is escaped with `esc_html()` anyway, so we don't
need to `wp_kses_post()`. This is a better experience for users who
want to use angle brackets in their site title or description.
Does not allow any HTML, adds unit tests.
props BandonRandon, pauldewouters.
fixes#27942.
git-svn-id: https://develop.svn.wordpress.org/trunk@35788 602fd350-edb4-49c9-b593-d223f7449a82
This gives us better compatibility with existing errors thrown by
`sanitize_user()`, especially in Multisite, where user_login has more
restrictions on allowed characters.
Props markjaquith.
Fixes#27317.
git-svn-id: https://develop.svn.wordpress.org/trunk@35772 602fd350-edb4-49c9-b593-d223f7449a82
In `populate_options()`, if the theme specified by `WP_DEFAULT_THEME` doesn't exist, fall back to the latest core default theme. If we can't find a core default theme, `WP_DEFAULT_THEME` is the best we can do.
Props nacin, jeremyfelt, dd32.
See #34306.
git-svn-id: https://develop.svn.wordpress.org/trunk@35738 602fd350-edb4-49c9-b593-d223f7449a82
Hello, it's me again. A pluggable function named `wp_new_user_notification()`. A few months ago, after [33023], I have lost my second parameter `$plaintext_pass`. But thanks to [33620] I got a new one.
Bad idea - It hasn't had the same behavior as my previous parameter.
To solve that the second parameter got deprecated and reintroduced as the third parameter in [34116]. I was happy again, for a short time.
You remember my lost friend `$plaintext_pass`? No? Well, if its value was empty no notification was sent to the user. This behavior was still lost. And that's what this change is about: Don't notify a user if a plugin uses `wp_new_user_notification( $user_id )`.
You're asking if I'm happy now? Dunno, but maybe you have learned something about pluggable functions, have you?
Props danielbachhuber.
Fixes#34377.
git-svn-id: https://develop.svn.wordpress.org/trunk@35735 602fd350-edb4-49c9-b593-d223f7449a82
The old URL redirects to `login.wordpress.org` because it's the new canonical URL for all logins on wordpress.org.
Fixes#34782.
git-svn-id: https://develop.svn.wordpress.org/trunk@35734 602fd350-edb4-49c9-b593-d223f7449a82
* Introduce `customize_post_value_set_{$setting_id}` and `customize_post_value_set` actions which are done when `WP_Customize_Manager::set_post_value()` is called.
* Clear the `preview_applied` flag for aggregated multidimensional settings when a post value is set. This ensures the new value is used instead of a previously-cached previewed value.
* Move `$is_preview` property from subclasses to `WP_Customize_Setting` parent class.
* Deferred preview: Ensure that when `preview()` short-circuits due to not being applicable that it will be called again later when the post value is set.
* Populate post value for updated-widget with the (unsanitized) JS-value in `WP_Customize_Widgets::call_widget_update()` so that value will be properly sanitized when accessed in `WP_Customize_Manager::post_value()`.
Includes unit tests with assertions to check the reported issues and validate the fixes.
Fixes defect introduced in [35007].
See #32103.
Fixes#34738.
git-svn-id: https://develop.svn.wordpress.org/trunk@35724 602fd350-edb4-49c9-b593-d223f7449a82
Previously, `&` would be converted everywhere, which caused problems when it was converted within a `<script>`, for example.
`convert_chars()` is now removed from the `the_content` filter, as it was doing the same job as `wptexturize()`.
KSES correctly handles converting `&` within HTML attributes, so there's no need for `wptexturize()` and `convert_chars()` to do the same job.
Fixes#34698.
git-svn-id: https://develop.svn.wordpress.org/trunk@35709 602fd350-edb4-49c9-b593-d223f7449a82
This is just an artifact of how we parse the URL, and is already available
via $request->get_route()
Props danielbachhuber.
Fixes#34647.
git-svn-id: https://develop.svn.wordpress.org/trunk@35659 602fd350-edb4-49c9-b593-d223f7449a82
If `DB_CHARSET` isn't defined (or is empty), `wpdb::$charset` will be empty, too. `wpdb::strip_invalid_text()` assumes that it isn't empty, however, so we need to fall back to the connection character set when we're running our sanity checks.
Fixes#34708.
git-svn-id: https://develop.svn.wordpress.org/trunk@35655 602fd350-edb4-49c9-b593-d223f7449a82
This fixes an edge case where the Close button could never link the user out of the Customizer, if the user initially accessed it without a `url` param and then clicked a link (provided by a plugin) that took them to another `customize.php` URL.
See #32637.
git-svn-id: https://develop.svn.wordpress.org/trunk@35635 602fd350-edb4-49c9-b593-d223f7449a82
Joe Hoyle
johnbillion
John Blackbourn
Boone Gorges
Rachel Baker
Mike Schroder
Weston Ruter
Eric Andrew Lewis
Konstantin Kovshenin
Scott Taylor
Dominik Schilling (ocean90)
Andrew Nacin
Mark Jaquith
Sergey Biryukov
Gary Pendergast
Ryan McCue