Using more than one instance of `WP_UnitTest_Factory` causes all kinds of craziness, due to out-of-sync internal generator sequences. Since we want to use `setUpBeforeClass`, we were creating ad hoc instances. To avoid that, we were injecting one `static` instance via Dependency Injection in `wpSetUpBeforeClass`. All tests should really use the `static` instance, so we will remove the instance prop `$factory`.
Replace `$this->factory` with `self::$factory` over 2000 times.
Rewrite all of the tests that were hard-coding dynamic values.
#YOLOFriday
git-svn-id: https://develop.svn.wordpress.org/trunk@35225 602fd350-edb4-49c9-b593-d223f7449a82
The `WP_INSTALLING` constant is a flag that WordPress sets in a number of
places, telling the system that options should be fetched directly from the
database instead of from the cache, that WP should not ping wordpress.org for
updates, that the normal "not installed" checks should be bypassed, and so on.
A constant is generally necessary for this purpose, because the flag is
typically set before the WP bootstrap, meaning that WP functions are not yet
available. However, it is possible - notably, during `wpmu_create_blog()` -
for the "installing" flag to be set after WP has already loaded. In these
cases, `WP_INSTALLING` would be set for the remainder of the process, since
there's no way to change a constant once it's defined. This, in turn, polluted
later function calls that ought to have been outside the scope of site
creation, particularly the non-caching of option data. The problem was
particularly evident in the case of the automated tests, where `WP_INSTALLING`
was set the first time a site was created, and remained set for the rest of the
suite.
The new `wp_installing()` function allows developers to fetch the current
installation status (when called without any arguments) or to set the
installation status (when called with a boolean `true` or `false`). Use of
the `WP_INSTALLING` constant is still supported; `wp_installing()` will default
to `true` if the constant is defined during the bootstrap.
Props boonebgorges, jeremyfelt.
See #31130.
git-svn-id: https://develop.svn.wordpress.org/trunk@34828 602fd350-edb4-49c9-b593-d223f7449a82
Post type objects are reponsible for mapping their capabilities to core caps.
As a result, when the post type is no longer registered, the caps are no
longer mapped. This causes problems when a post is left in the database after
the post type is no longer present, and WP does an 'edit_post' or other cap
check against it: a PHP notice is thrown, and the cap check always fails.
As a more graceful fallback, we map all post-type-dependent caps onto
'edit_others_posts', which allows highly privileged users to be able to
access orphaned content (such as comments belonging to disabled post types),
while minimizing the possibility of unintended privilege escalation.
We also add a `_doing_it_wrong()` notice, so that developers and site
administrators are aware that the cap mapping is failing in the absence of
the registered post type.
Props mitchoyoshitaka, DrewAPicture, imath, codeelite, boonebgorges, nofearinc, SergeyBiryukov, jorbin, dlh.
Fixes#16956.
git-svn-id: https://develop.svn.wordpress.org/trunk@34091 602fd350-edb4-49c9-b593-d223f7449a82
Other users in a network can now be given capabilities to manage users without also having global super admin privileges.
* Users with `manage_network_users` can not edit super admins.
* Users with `manage_network_users` can not promote users to super admin.
* Uses of `is_super_admin()` in `user-new.php` are now updated to `manage_network_users`.
Props daniellandau, chriscct7.
Fixes#16860.
git-svn-id: https://develop.svn.wordpress.org/trunk@33988 602fd350-edb4-49c9-b593-d223f7449a82
An administrator in multisite can not edit users other than itself.
Props daniellandau for the initial patch.
See #16860.
git-svn-id: https://develop.svn.wordpress.org/trunk@33987 602fd350-edb4-49c9-b593-d223f7449a82
Undoes [12053]. While it risks breakage, this is a far safer and saner default for these situations.
props danielbachhuber.
fixes#27020.
git-svn-id: https://develop.svn.wordpress.org/trunk@27390 602fd350-edb4-49c9-b593-d223f7449a82
* Remove duplicated code for deprecated function notice suppression
* Add support in `WP_UnitTestCase` setUp/tearDown methods for `$deprecated_functions` fixture if the extending class has added it
* Add a `$deprecated_functions` fixture to each extending class that needs it
To use this fixture, add something to your Test Case class like so:
`protected $deprecated_functions = array( 'get_theme', 'get_themes', 'get_theme_data', 'get_current_theme' );`
See #25282.
git-svn-id: https://develop.svn.wordpress.org/trunk@25402 602fd350-edb4-49c9-b593-d223f7449a82
wp-tests-config.php can/should reside in the root of a develop checkout. `phpunit` should be run from the root.
see #25088.
git-svn-id: https://develop.svn.wordpress.org/trunk@25165 602fd350-edb4-49c9-b593-d223f7449a82
