wordpress-develop/tests/phpunit
Tonya Mork d0f1816c36 Code Modernization: Fix dynamic properties in WP_Admin_Bar.
To fix the dynamic properties, the following changes are included:
* Removes `WP_Admin_Bar::__get()`.
* Declares `menu` as a property on the class, deprecates it, and initializes it to an empty array.
* Removes the unused 'proto' dynamic property.

Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.

== Why remove the `WP_Admin_Bar::__get()` magic method?

tl;dr
The magic method is no longer needed.

The magic method only handled the `menu` and `proto` dynamic properties. Introducing a full set of magic methods is overkill for this class. Instead of having to maintain magic methods, this changeset instead directly addresses the 2 properties (see below).

== Why declare the `menu` property on the class?

tl;dr
To simplify the code while maintaining backwards compatibility for extenders who are using this deprecated property.

The `menu` property was introduced during the 3.1.0 ''development cycle'' as a declared property [15671]. Its purpose was to ''internally'' hold the menu structure.

During the WP 3.3.0 development cycle, it was replaced by a new `private` property called `nodes` (see [19120]).

But breakage reports from extenders caused it to be restored. [19501] added the `__get()` magic method, i.e. for handling it as a dynamic property, and deprecated it.

>We're not going to maintain compat for $menu. Suggest we make it array() and plugins will have to deal. We can throw a _deprecated_argument() and push them to use the new methods.
~ Source: [https://core.trac.wordpress.org/ticket/19371#comment:17 see #19371 comment 17]

[https://wpdirectory.net/search/01GSTW1X69TBN8FH3SY7V8KPY5 A search of the wp.org plugins and themes repository] shows that a few plugins are still using this deprecated property. To maintain backwards compatibility, `menu` is moved back to the class as a declared property, set to an empty array (as it's been since 3.3.0), and deprecated in the property's description.

== Why remove the `proto` dynamic property?

tl;dr
* It was not intended to be released in 3.1.
* There are no usages of it in Core or in the WP.org's plugin or theme directories.
* It should be safe to remove.

This property was first introduced in the WP 3.1.0 ''development cycle'' to replace the `PROTO` constant (see [16038]) for protocol handling for the admin bar's hyperlinks. [16077] replaced the property's usages with URL functions such as `get_admin_url()` and `admin_url()`. But it missed removing the property, which was no longer needed or used.

It was relocated to the `__get()` magic method as a dynamic property when the `menu` property was restored (see [19501]).

A search of WP.org's plugins and themes repositories shows no usages of the property. Core hasn't used it since the removed in [16038] before 3.1 final release. It should be safe to remove it, but committing very early in the 6.3 alpha cycle to give time for reports of usages, if there are any.

References:
* A [https://www.youtube.com/watch?v=vDZWepDQQVE&t=9362s live open public working session] where these changes were discussed and agreed to.
* [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties].

Follow-up to [19501], [19120], [16308], [16038], [15671].

Props antonvlasenko, hellofromTonya, jrf, markjaquith, desrosj, ironprogrammer, peterwilsoncc, SergeyBiryukov.
See #56876, #56034.

git-svn-id: https://develop.svn.wordpress.org/trunk@55580 602fd350-edb4-49c9-b593-d223f7449a82
2023-03-21 19:58:45 +00:00
..
data Build/Tests Tools: Add unit tests for Gallery blocks. 2023-03-07 05:46:16 +00:00
includes Build/Test Tools: Fix issue with add method in object-cache.php. 2023-03-21 17:00:21 +00:00
tests Code Modernization: Fix dynamic properties in WP_Admin_Bar. 2023-03-21 19:58:45 +00:00
multisite.xml Build/Test Tools: Update PHPUnit configuration for PHPUnit 9.5.10/8.5.21+. 2021-09-26 03:11:18 +00:00
README.txt Docs: Remove double spaces in tests/phpunit/README.txt. 2022-04-29 13:31:48 +00:00
wp-mail-real-test.php Docs: Align spelling with American English. 2022-10-21 21:10:29 +00:00

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.