When `add_filter( 'wp_is_application_passwords_available', '__return_false' )` exists, HTTPS requirement message is shown even if HTTPS is enabled on the site. This happens because `wp_is_application_passwords_available_for_user()` first invokes `wp_is_application_passwords_available()` which is filterable. The situation could happen if the `'wp_is_application_passwords_available_for_user'` filter returns `false`.
To fix this, the check for HTTPS (or if in a 'local' environment) is moved to a new function called `wp_is_application_passwords_supported()`. Then the return from this function is used as an OR condition for the Application Passwords section and for displaying the HTTPS required message.
Tests are included for both `wp_is_application_passwords_supported()` and `wp_is_application_passwords_available()`.
Follow-up to [51980], [51988].
Props davidbinda, SergeyBiryukov, ocean90, felipeelia, costdev, hellofromTonya.
Fixes#53658.
Built from https://develop.svn.wordpress.org/trunk@52398
git-svn-id: http://core.svn.wordpress.org/trunk@51990 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds the `wp_login_url()` login link to the Error message to be more helpful to users when their user email already is registered.
Improves the error message to more clearly communicate next step.
Follow-up to [16009], [22124], [31963].
Props andynick, costdev, dansoschin, sabernhardt, webcommsat.
Fixes#53631.
Built from https://develop.svn.wordpress.org/trunk@52074
git-svn-id: http://core.svn.wordpress.org/trunk@51666 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces a new function called `wp_list_users()`. Similar to other list functions such as `wp_list_authors()`, it lists all the users of the site. Options are available to configure the HTML output.
Following the same pattern of the other list functions, the list's HTML output is rendered by default. Setting the `echo` argument to `false`, returns the list's HTML output.
A new test class is included.
Props afercia, audrasjb, chriscct7, costdev, desrosj, greenshady, hellofromTonya, mte90, nacin, rohan013, sergeybiryukov.
Fixes#15145.
Built from https://develop.svn.wordpress.org/trunk@52064
git-svn-id: http://core.svn.wordpress.org/trunk@51656 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Load a language switcher on the login and registration screens that allows users to choose any already-installed language. Set user locale on registration.
Props johnbillion, Nikschavan, afercia, sabernhardt, garrett-eclipse, keyur5, paaljoachim, Clorith, tobifjellner.
Fixes#43700.
Built from https://develop.svn.wordpress.org/trunk@52058
git-svn-id: http://core.svn.wordpress.org/trunk@51650 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Similar to the existing `role`/`role__in`/`role__not_in` query arguments, this adds support for three new query arguments in `WP_User_Query`:
* `capability`
* `capability__in`
* `capability__not_in`
These can be used to fetch users with (or without) a specific set of capabilities, for example to get all users
with the capability to edit a certain post type.
Under the hood, this will check all existing roles on the site and perform a `LIKE` query against the `capabilities` user meta field to find:
* all users with a role that has this capability
* all users with the capability being assigned directly
Note: In WordPress, not all capabilities are stored in the database. Capabilities can also be modified using filters like `map_meta_cap`. These new query arguments do NOT work for such capabilities.
The prime use case for capability queries is to get all "authors", i.e. users with the capability to edit a certain post type.
Until now, `'who' => 'authors'` was used for this, which relies on user levels. However, user levels were deprecated a long time ago and thus never added to custom roles. This led to constant frustration due to users with custom roles missing from places like author dropdowns.
This updates any usage of `'who' => 'authors'` in core to use capability queries instead.
Subsequently, `'who' => 'authors'` queries are being **deprecated** in favor of these new query arguments.
Also adds a new `capabilities` parameter (mapping to `capability__in` in `WP_User_Query`) to the REST API users controller.
Also updates `twentyfourteen_list_authors()` in Twenty Fourteen to make use of this new functionality, adding a new `twentyfourteen_list_authors_query_args` filter to make it easier to override this behavior.
Props scribu, lgladdly, boonebgorges, spacedmonkey, peterwilsoncc, SergeyBiryukov, swissspidy.
Fixes#16841.
Built from https://develop.svn.wordpress.org/trunk@51943
git-svn-id: http://core.svn.wordpress.org/trunk@51532 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows custom user meta values to be provided when creating or updating a user in the same way custom post meta can be provided to `wp_insert_post()` when creating or updating a post.
Also introduces the `insert_custom_user_meta` to filter these values.
Props desrosj, donmhico
Fixes#41950
Built from https://develop.svn.wordpress.org/trunk@51738
git-svn-id: http://core.svn.wordpress.org/trunk@51346 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Typo corrections in filter descriptions.
- DocBlocks are now now wrapped to the next line after 80 characters, and not extending beyond 120 total characters wide.
- Remove unnecessary repeated references to the suggested replacement hooks.
- Adjustments to the indentation for consistency with other emails in Core, allowing the `phpcs:ignore` comment to be removed.
Props SergeyBiryukov.
Fixes#44314.
Built from https://develop.svn.wordpress.org/trunk@51410
git-svn-id: http://core.svn.wordpress.org/trunk@51021 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The filters `user_confirmed_action_email_content`, `user_erasure_complete_email_subject`, and `user_erasure_complete_email_headers` have been deprecated.
They have been replaced with `user_erasure_fulfillment_email_content`, `user_erasure_fulfillment_email_subject`, and `user_erasure_fulfillment_email_headers`.
Props desrosj, garrett-eclipse, birgire, DrewAPicture, lifeforceinst, ocean90, pbiron, pento, coffee2code, TZ-Media, SergeyBiryukov, johnbillion, audrasjb, davidbaumwald, hellofromTonya, helen, xkon, antpb, peterwilsoncc, lukecarbis.
Fixes#44314.
Built from https://develop.svn.wordpress.org/trunk@51129
git-svn-id: http://core.svn.wordpress.org/trunk@50738 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This adds a new parameter to the action and filter hooks found in `wp_insert_user()` to pass the raw user data received through `$userdata` to hooked functions.
This will allow hooked functions to perform more contextual adjustments to new users, and makes supplying custom user meta fields possible.
Props johnbillion, audrasjb.
Fixes#53110.
Built from https://develop.svn.wordpress.org/trunk@51005
git-svn-id: http://core.svn.wordpress.org/trunk@50614 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `update_user_option()` function is a way to update a user meta value after adding a blog’s prefix to the beginning of the meta key. But when the fourth parameter is `true`, the behavior is exactly the same as calling `update_user_meta()` directly.
This replaces all instances of `update_user_option()` when the fourth parameter is `true` in Core with a direct call to `update_user_meta()` to prevent an unnecessary call to `update_user_option()`.
Props johnjamesjacoby, zkancs, obenland, desrosj.
Fixes#43339.
Built from https://develop.svn.wordpress.org/trunk@50981
git-svn-id: http://core.svn.wordpress.org/trunk@50590 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, these properties could be unexpectedly converted to strings in some contexts.
This applies to the following functions:
* `sanitize_post_field()`
* `sanitize_term_field()`
* `sanitize_user_field()`
and the following properties:
* `WP_Post::ID`
* `WP_Post::post_parent`
* `WP_Post::menu_order`
* `WP_Term::term_id`
* `WP_Term::term_taxonomy_id`
* `WP_Term::parent`
* `WP_Term::count`
* `WP_Term::term_group`
* `WP_User::ID`
Props grantmkin, SergeyBiryukov.
Fixes#53235. See #52995.
Built from https://develop.svn.wordpress.org/trunk@50935
git-svn-id: http://core.svn.wordpress.org/trunk@50544 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Share the `WP_User` instance for the current user between the functions `get_userdata()` and `wp_get_current_user()`. Both functions return the `$current_user` global for the current user.
Force refresh the `$current_user` global within `clean_user_cache()` by immediately re-calling `wp_set_current_user()` with the current user's ID. This ensures any changes to the current user's permissions or other settings are reflected in the global. As a side-effect this immediately rewarms the current user's cache.
Props chaion07, chriscct7, donmhico, hellofromtonya, lukecarbis, peterwilsoncc, rmccue, TimothyBlynJacobs.
Fixes#28020.
Built from https://develop.svn.wordpress.org/trunk@50790
git-svn-id: http://core.svn.wordpress.org/trunk@50399 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[48658] documented that various metadata functions return false for an invalid ID. However, that does not clarify what an invalid ID is: a non-numeric, zero, or negative value. This change adds the clarification in all relevant metadata function docblocks.
Props icopydoc, SergeyBiryukov, davidkryzaniak, audrasjb.
Fixes#51797.
Built from https://develop.svn.wordpress.org/trunk@50641
git-svn-id: http://core.svn.wordpress.org/trunk@50253 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This adds a form option to skip the admin email alert when exporting personal data.
Props xkon, azaozz, TZ-Media, iandunn, desrosj, iprg, allendav, wesselvandenberg, karmatosed, birgire, davidbaumwald, estelaris, paaljoachim, hellofromTonya.
Fixes#43890.
Built from https://develop.svn.wordpress.org/trunk@50159
git-svn-id: http://core.svn.wordpress.org/trunk@49838 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, only the username was checked which caused a PHP warning in some server setups, for instance Shibboleth SSO, where the server only populates the `PHP_AUTH_USER` field.
Props MadtownLems, johnbillion, richard.tape, engahmeds3ed.
Fixes#52003.
Built from https://develop.svn.wordpress.org/trunk@49919
git-svn-id: http://core.svn.wordpress.org/trunk@49618 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Application Passwords uses Basic Authentication to transfer authentication details. If the site is already using Basic Auth, for instance to implement a private staging environment, then the REST API will treat this as an authentication attempt and would end up generating an error for any REST API request.
Now, Application Password authentication will only be attempted if Application Passwords is in use by a site. This is flagged by setting an option whenever an Application Password is created. An upgrade routine is added to set this option if any App Passwords already exist.
Lastly, creating an Application Password will be prevented if the site appears to already be using Basic Authentication.
Props chexwarrior, georgestephanis, adamsilverstein, helen, Clorith, marybaum, TimothyBlynJacobs.
Fixes#51939.
Built from https://develop.svn.wordpress.org/trunk@49752
git-svn-id: http://core.svn.wordpress.org/trunk@49475 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously App Passwords used a mix of "enabled" and "available". We've now standardized on using "available".
Additionally, we now use a 501 status code when indicating that App Passwords is not available.
Props SergeyBiryukov, ocean90, TimothyBlynJacobs.
Fixes#51513.
Built from https://develop.svn.wordpress.org/trunk@49617
git-svn-id: http://core.svn.wordpress.org/trunk@49355 1a063a9b-81f0-0310-95a4-ce76da25c4cd
