Role="navigation" was required for assistive technology to recognize HTML5 element's native ARIA roles while HTML5 and ARIA were being introduced. With the deprecation of IE11, the role attribute is only required when mapping elements that don't have native role.
Props costdev, mukesh27.
Fixes#54054.
Built from https://develop.svn.wordpress.org/trunk@51967
git-svn-id: http://core.svn.wordpress.org/trunk@51556 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds end-to-end (e2e) tests for the following test scenarios:
* Create a new application password.
* Create an application password with an existing name.
* Revoke a single application password.
* Bulk revoke applications passwords.
Follow-up to [49109], [49276], [49562], [50001], [50367], [51463].
Props justinahinon, swissspidy, juhise, kevin940726, isabel_brison.
Fixes#54241.
Built from https://develop.svn.wordpress.org/trunk@51966
git-svn-id: http://core.svn.wordpress.org/trunk@51555 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Use 3-digit, x.x.x-style semantic versioning for `@since` tags of the `$rest_namespace` property in `WP_Post_Type` and `WP_Taxonomy`.
Add a `@since` note to `WP_REST_Taxonomies_Controller::get_item_schema()` for the `visibility` and `rest_namespace` properties.
The `rest_base` property was also added after the method was initially introduced, but that happened during the same release cycle, so it doesn't need a separate `@since` note.
Follow-up to [38832], [39191], [42729], [51959], [51961], [51962], [51964].
See #53399.
Built from https://develop.svn.wordpress.org/trunk@51965
git-svn-id: http://core.svn.wordpress.org/trunk@51554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While a taxonomy can define a custom route by using the rest_base argument, a namespace of wp/v2 was assumed. This commit introduces support for a rest_namespace argument.
A new rest_get_route_for_taxonomy_items function has been introduced and the rest_get_route_for_term function updated to facilitate getting the correct route for taxonomies.
For maximum compatibility sticking with the default wp/v2 namespace is recommended until the API functions see wider use.
Props spacedmonkey.
Fixes#54267.
See [51962].
Built from https://develop.svn.wordpress.org/trunk@51964
git-svn-id: http://core.svn.wordpress.org/trunk@51553 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change adds two now attribute-related config options to KSES:
- An array of allowed values can be defined for attributes. If the attribute value doesn't fall into the list, the attribute will be removed from the tag.
- Attributes can be marked as required. If a required attribute is not present, KSES will remove all attributes from the tag. As KSES doesn't match opening and closing tags, it's not possible to safely remove the tag itself, the safest fallback is to strip all attributes from the tag, instead.
Included with this change is an implementation of these options, allowing the `<object>` tag to be stored in posts, but only when it has a `type` attribute set to `application/pdf`.
Props pento, swissspidy, peterwilsoncc, dd32, jorbin.
Fixes#54261.
Built from https://develop.svn.wordpress.org/trunk@51963
git-svn-id: http://core.svn.wordpress.org/trunk@51552 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While a custom post type can define a custom route by using the `rest_base` argument, a namespace of `wp/v2` was assumed. This commit introduces support for a `rest_namespace` argument.
A new `rest_get_route_for_post_type_items` function has been introduced and the `rest_get_route_for_post` function updated to facilitate getting the correct route for custom post types.
While the WordPress Core Block Editor bootstrap code has been updated to use these API functions, for maximum compatibility sticking with the default `wp/v2` namespace is recommended until the API functions see wider use.
Props spacedmonkey, swissspidy.
Fixes#53656.
Built from https://develop.svn.wordpress.org/trunk@51962
git-svn-id: http://core.svn.wordpress.org/trunk@51551 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `taxonomies` and `rest_base` properties were also added after the method was initially introduced, but that happened during the same release cycle, so they don't need a separate `@since` note.
Follow-up to [38832], [39097], [39191], [39647], [51959].
See #53399.
Built from https://develop.svn.wordpress.org/trunk@51961
git-svn-id: http://core.svn.wordpress.org/trunk@51550 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This makes the needed adjustments to fix Slack notifications for `scheduled` and `workflow_dispatch` events. The data needed to send notifications for these events are stored in different locations, or need to be accessed through API requests.
Follow up to [51921], [51937].
See #53363.
Built from https://develop.svn.wordpress.org/trunk@51953
git-svn-id: http://core.svn.wordpress.org/trunk@51542 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Closes the admin menu on mobile devices when keyboard focus moves outside of the menu or menu toggle elements. Improves the usability of the menu on mobile by allowing closure anywhere outside the menu rather than only on the toggle.
Props kaneva, costdev, sabernhardt
Fixes#53587.
Built from https://develop.svn.wordpress.org/trunk@51946
git-svn-id: http://core.svn.wordpress.org/trunk@51535 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 avoids an `Uncaught ArgumentCountError: Too few arguments to function {closure}(), 1 passed` PHP fatal error when registering a block style with the `should_load_separate_core_block_assets` filter enabled.
Follow-up to [51471].
Props aristath, shimon246, jrf, gziolo.
Fixes#54323.
Built from https://develop.svn.wordpress.org/trunk@51941
git-svn-id: http://core.svn.wordpress.org/trunk@51530 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change allows for external clients to supply a suggested filename via a `Content-Disposition` response header. This filename is processed through `sanitize_file_name()` to ensure it is allowable (on the server, MIME's, etc...) and `validate_file()` to prevent directory traversal.
If the suggested filename fails the above processing/checks, that suggestion is discarded and the standard temporary filename (generated by WordPress) is used.
If no `Content-Disposition` header is found in the response headers, the standard temporary filename continues to be used as per normal.
Included in this change are 6 additional PHPUnit tests with 9 assertions. These tests confirm that valid filename values are correctly saved, and invalid filename values are correctly rejected.
Props cklosows, costdev, dd32, johnjamesjacoby, ocean90, psrpinto.
Fixes#38231.
Built from https://develop.svn.wordpress.org/trunk@51939
git-svn-id: http://core.svn.wordpress.org/trunk@51528 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Move the directory being tested to the `data` directory, for consistency with other test data.
* Set the `svn:eol-style` property to `native`, for consistency with other files.
* Correct the test class name in `dummy.txt`.
Follow-up to [51246], [51910], [51911].
See #52241, #53363.
Built from https://develop.svn.wordpress.org/trunk@51938
git-svn-id: http://core.svn.wordpress.org/trunk@51527 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When a workflow is triggered through a `workflow_run` event, the context is not the original workflow. The details about the original workflow are passed through the `github.event` context.
This also moves the conditional check controlling whether the Slack workflow is run into the calling workflows to prevent them from running for pull requests.
Follow up to [51921-51922,51924-51925,51934].
See #53363.
Built from https://develop.svn.wordpress.org/trunk@51937
git-svn-id: http://core.svn.wordpress.org/trunk@51526 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [51921], the GitHub Actions workflows were updated to utilize the Slack notifications workflow as a callable one instead of on the `workflow_run` event.
This eliminated the need for an additional “Slack Notifications” workflow run for every completed workflow, but only when other workflows are updated as well. This resulted in notifications from older branches breaking, as the changes in [51921] were not backported.
Instead of backporting the needed changes now (the Slack workflow is still being polished), this commit partially restores the `workflow_run` event for older branches so that notifications will resume.
See #53363.
Built from https://develop.svn.wordpress.org/trunk@51934
git-svn-id: http://core.svn.wordpress.org/trunk@51525 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Split long concatenated lines using `sprintf()`. This aims to improve readability and avoid multiple `esc_attr()` calls for the same value.
* Escape the form `name` and `id` attributes.
Follow-up to [12696], [18444], [19033].
Props sabbirshouvo, mukesh27, audrasjb, henry.wright, SergeyBiryukov.
Fixes#54279.
Built from https://develop.svn.wordpress.org/trunk@51926
git-svn-id: http://core.svn.wordpress.org/trunk@51519 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Rename a duplicate `$feature_name` variable to `$feature_group` for clarity.
* Escape the remaining `$feature_name` variable.
Follow-up to [27636], [35273].
Props sabbirshouvo, sabernhardt, mukesh27, afragen.
Fixes#54277.
Built from https://develop.svn.wordpress.org/trunk@51923
git-svn-id: http://core.svn.wordpress.org/trunk@51516 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The ability to reuse workflow files within GitHub Action workflows was recently added and allows for less code duplication.
In the context of WordPress Core, this also eliminates the need for an additional “Slack Notifications” workflow to run for every completed workflow.
See #53363.
Built from https://develop.svn.wordpress.org/trunk@51921
git-svn-id: http://core.svn.wordpress.org/trunk@51514 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commit adds the `public` visibility keyword to each method which did not have an explicit visibility keyword.
Why `public`?
With no visibility previously declared, these methods are implicitly `public` and available for use. Changing them to anything else would be a backwards-compatibility break.
Props costdev, jrf.
See #54177.
Built from https://develop.svn.wordpress.org/trunk@51919
git-svn-id: http://core.svn.wordpress.org/trunk@51512 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[51916] fixed a bug where `array( `false` )` was added to the cron array when `_get_cron_array()` returned `false`.
This commit:
* Removes any `false` values from the cron array when upgrading to 5.9+.
* Bumps the database version.
Follow-up to [44917], [51916].
Props peterwilsoncc, jrf.
See #53950.
Built from https://develop.svn.wordpress.org/trunk@51917
git-svn-id: http://core.svn.wordpress.org/trunk@51510 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In `wp_schedule_single_event()`, the cron info array is retrieved via a call to `_get_cron_array()` and straight away cast to an array. But as the documentation for that function (correctly) states, the return type of that function is `array|false`, where `false` is returned for a site where no cron jobs have been scheduled (yet).
In the case that `_get_cron_array()` would return `false`, this would now unintentionally create an array with a single entry with key `0` and as the value `false`.
This is a bug. Fixed now by adding validation to the output of `_get_cron_array()` and initializing `$crons` to an empty array if `false` was returned.
Tests added first to prove the bug (a) was introduced in #44818 [44917] and (b) is now fixed.
Follow-up to [44917].
Props jrf, peterwilsoncc.
Fixes#53950.
Built from https://develop.svn.wordpress.org/trunk@51916
git-svn-id: http://core.svn.wordpress.org/trunk@51509 1a063a9b-81f0-0310-95a4-ce76da25c4cd
joedolson
hellofromTonya
Sergey Biryukov
TimothyBlynJacobs
Gary Pendergast
John Blackbourn
desrosj
Pascal Birchler
johnjamesjacoby
Peter Wilson