mirror of
https://github.com/gosticks/wordpress-develop.git
synced 2025-10-16 12:05:38 +00:00
0cf6d3e48d
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. git-svn-id: https://develop.svn.wordpress.org/trunk@51943 602fd350-edb4-49c9-b593-d223f7449a82 |
||
|---|---|---|
| .. | ||
| data | ||
| includes | ||
| tests | ||
| build.xml | ||
| multisite.xml | ||
| README.txt | ||
| wp-mail-real-test.php | ||
The short version:
1. Create a clean MySQL database and user. DO NOT USE AN EXISTING DATABASE or you will lose data, guaranteed.
2. Copy wp-tests-config-sample.php to wp-tests-config.php, edit it and include your database name/user/password.
3. $ svn up
4. Run the tests from the "trunk" directory:
To execute a particular test:
$ phpunit tests/phpunit/tests/test_case.php
To execute all tests:
$ phpunit
Notes:
Test cases live in the 'tests' subdirectory. All files in that directory will be included by default. Extend the WP_UnitTestCase class to ensure your test is run.
phpunit will initialize and install a (more or less) complete running copy of WordPress each time it is run. This makes it possible to run functional interface and module tests against a fully working database and codebase, as opposed to pure unit tests with mock objects and stubs. Pure unit tests may be used also, of course.
Changes to the test database will be rolled back as tests are finished, to ensure a clean start next time the tests are run.
phpunit is intended to run at the command line, not via a web server.