The following warnings could, in very select circumstances, be shown:
{{{
// PHP 8.0 and higher:
Warning: foreach() argument must be of type array|object, bool given
// PHP 5.6 – 7.4
Warning: Invalid argument supplied for foreach()
}}}
In `WP_Media_List_Table::prepare_items()`, the cron info array is retrieved via a call to `_get_cron_array()`, but as the documentation (correctly) states, the return type of that function is `array|false`, where `false` is returned for a virgin site, with no cron jobs scheduled yet.
However, no type check is done on the return value, and the method just blindly continues by using it in a `foreach`.
Fixed by adding validation for the returned value from `_get_cron_array()` and only running the `foreach` when the returned value is an array.
Reference: [https://developer.wordpress.org/reference/functions/_get_cron_array/ WordPress Developer Resources: _get_cron_array()]
Follow-up to [48417].
Props jrf, hellofromTonya, mukesh27.
Fixes#53949.
Built from https://develop.svn.wordpress.org/trunk@51638
git-svn-id: http://core.svn.wordpress.org/trunk@51244 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Hide the browser's native radio button on the custom background position selector in the Customizer and the legacy background screen. This fixes an issue causing both to display.
Props mukesh27, ravipatel, sabernhardt, walbo.
Fixes#53803.
Built from https://develop.svn.wordpress.org/trunk@51637
git-svn-id: http://core.svn.wordpress.org/trunk@51243 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since PHP 8.1, the `auto_detect_line_endings` setting is deprecated:
> The `auto_detect_line_endings` ini setting modifies the behavior of `file()` and `fgets()` to support an isolated `\r` (as opposed to `\n` or `\r\n`) as a newline character. These newlines were used by “Classic” Mac OS, a system which has been discontinued in 2001, nearly two decades ago. Interoperability with such systems is no longer relevant.
Reference: [https://wiki.php.net/rfc/deprecations_php_8_1#auto_detect_line_endings_ini_setting PHP RFC: Deprecations for PHP 8.1: auto_detect_line_endings ini setting]
> The `auto_detect_line_endings` ini setting has been deprecated. If necessary, handle `\r` line breaks manually instead.
Reference: [1cf4fb739f/UPGRADING (L456-L457) PHP 8.1 Upgrade Notes].
This commit fixes the warning when running tests for the `PO` class:
{{{
Deprecated: auto_detect_line_endings is deprecated in /var/www/src/wp-includes/pomo/po.php on line 16
}}}
While deprecated, the actual `auto_detect_line_endings` functionality has not been removed from PHP (yet) and will still work until PHP 9.0.
For now, we're silencing the deprecation notice as there may still be translation files around which haven't been updated in a long time and which still use the old MacOS standalone `\r` as a line ending.
This should be revisited when PHP 9.0 is in alpha/beta.
Follow-up to [51633].
Props jrf.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51636
git-svn-id: http://core.svn.wordpress.org/trunk@51242 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since PHP 8.1, the `auto_detect_line_endings` setting is deprecated:
> The `auto_detect_line_endings` ini setting modifies the behavior of `file()` and `fgets()` to support an isolated `\r` (as opposed to `\n` or `\r\n`) as a newline character. These newlines were used by “Classic” Mac OS, a system which has been discontinued in 2001, nearly two decades ago. Interoperability with such systems is no longer relevant.
Reference: [https://wiki.php.net/rfc/deprecations_php_8_1#auto_detect_line_endings_ini_setting PHP RFC: Deprecations for PHP 8.1: auto_detect_line_endings ini setting]
> The `auto_detect_line_endings` ini setting has been deprecated. If necessary, handle `\r` line breaks manually instead.
Reference: [1cf4fb739f/UPGRADING (L456-L457) PHP 8.1 Upgrade Notes].
This commit fixes the warning when running tests for the `PO` class:
{{{
Deprecated: auto_detect_line_endings is deprecated in /var/www/src/wp-includes/pomo/po.php on line 16
}}}
Follow-up to [10584], [51628].
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51633
git-svn-id: http://core.svn.wordpress.org/trunk@51239 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Increase the number of media items displayed per page from 40 to 80 to improve the experience for users navigating the library on sites with a large quantity of media in the library.
Props AlGala, antpb, hellofromTonya, joedolson, SergeyBiryukov, wb1234.
Fixes#53827.
Built from https://develop.svn.wordpress.org/trunk@51632
git-svn-id: http://core.svn.wordpress.org/trunk@51238 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Reduces the right margin of the media library modal on small and medium width screens to remove excess white-space. On very narrow screens this was preventing the media icons from displaying.
Props andraganescu, desrosj, joedolson, moch11, mukesh27, sabernhardt, SergeyBiryukov, zieladam.
Fixes#53679.
Built from https://develop.svn.wordpress.org/trunk@51631
git-svn-id: http://core.svn.wordpress.org/trunk@51237 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As per the PHP manual:
> If the `component` parameter is omitted, an associative array is returned.
> If the `component` parameter is specified, `parse_url()` returns a string (or an int, in the case of `PHP_URL_PORT`) instead of an array. If the requested component doesn't exist within the given URL, `null` will be returned.
Reference: [https://www.php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-returnvalues PHP Manual: parse_url(): Return Values]
It is entirely possible for the `siteurl` option to not have a "path" component.
In PHP 8.1, this would lead to a `trim(): Passing null to parameter #1 ($string) of type string is deprecated` notice.
Changing the logic around and adding validation for the return type value of `parse_url()` prevents that.
As this function is declaring global constants, adding tests for this change is not really an option without potentially affecting other tests.
Follow-up to [51606], [51622], [51626], [51629].
Props jrf, hellofromTonya, SergeyBiryukov.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51630
git-svn-id: http://core.svn.wordpress.org/trunk@51236 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As per the PHP manual:
> If the `component` parameter is omitted, an associative array is returned.
> If the `component` parameter is specified, `parse_url()` returns a string (or an int, in the case of `PHP_URL_PORT`) instead of an array. If the requested component doesn't exist within the given URL, `null` will be returned.
Reference: [https://www.php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-returnvalues PHP Manual: parse_url(): Return Values]
While it is probably unlikely that someone would have a direct link to the plugin/theme editor on their home page or even on someone else's homepage, it is entirely possible for the referrer URL to not have a "path" component.
In PHP 8.1, this would lead to a `basename(): Passing null to parameter #1 ($string) of type string is deprecated` notice.
Changing the logic around and adding validation for the return type value of `parse_url()` prevents that.
Follow-up to [51606], [51622], [51626].
Props jrf, hellofromTonya, SergeyBiryukov.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51629
git-svn-id: http://core.svn.wordpress.org/trunk@51235 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As per the PHP manual:
> If the `component` parameter is omitted, an associative array is returned.
> If the `component` parameter is specified, `parse_url()` returns a string (or an int, in the case of `PHP_URL_PORT`) instead of an array. If the requested component doesn't exist within the given URL, `null` will be returned.
Reference: [https://www.php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-returnvalues PHP Manual: parse_url(): Return Values]
This commit adds three unit tests for `download_url()`:
* The first test is "girl-scouting" to make sure that the code up to the point where the error is expected is tested.
* The second test exposed a PHP 8.1 `basename(): Passing null to parameter #1 ($path) of type string is deprecated` error due to the call to `parse_url()` returning `null` when the component requested does not exist in the passed URL.
* The output of the call to `parse_url()` stored in the `$url_path` variable is used in more places in the function logic. The third test exposes a second PHP 8.1 deprecation notice, this time for `substr(): Passing null to parameter #1 ($string) of type string is deprecated`.
This commit also removes duplicate `parse_url()` calls. Neither `$url` nor `$url_filename` are changed between when they are first received/defined and when they are re-used, so there is no need to repeat the function calls.
Follow-up to [51606], [51622].
Props jrf, hellofromTonya, SergeyBiryukov.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51626
git-svn-id: http://core.svn.wordpress.org/trunk@51232 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes a `preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated` notice on PHP 8.1.
The behavior for `null` and `string` input is covered by the existing `Tests_Functions::test_validate_file()` test.
Effect: Errors down by 238, assertions up by 1920, failures down by 1.
Props jrf, hellofromTonya, SergeyBiryukov.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51625
git-svn-id: http://core.svn.wordpress.org/trunk@51231 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes `parse_str(): Passing null to parameter #1 ($string) of type string is deprecated` notices on PHP 8.1, without change in behaviour.
Impact: 311 of the pre-existing tests are affected by this issue.
The PHP native `parse_str()` function expects a string, however, based on the failing tests, it is clear there are functions in WordPress which passes a non-string – including `null` – value to the `wp_parse_str()` function, which would subsequently pass it onto the PHP native function without further input validation.
Most notable offender is the `wp_parse_args()` function which special cases arrays and objects, but passes everything else off to `wp_parse_str()`.
Several ways to fix this issue have been explored, including checking the received value with `is_string()` or `is_scalar()` before passing it off to the PHP native `parse_str()` function.
In the end it was decided against these in favor of a string cast as:
* `is_string()` would significantly change the behavior for anything non-string.
* `is_scalar()` up to a point as well, as it does not take objects with a `__toString()` method into account.
Executing a string cast on the received value before passing it on maintains the pre-existing behavior while still preventing the deprecation notice coming from PHP 8.1.
Reference: [https://www.php.net/manual/en/function.parse-str.php PHP Manual: parse_str()]
Follow-up to [5709].
Props jrf, hellofromTonya, lucatume, SergeyBiryukov.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51624
git-svn-id: http://core.svn.wordpress.org/trunk@51230 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As per the PHP manual:
> If the `component` parameter is omitted, an associative array is returned.
> If the `component` parameter is specified, `parse_url()` returns a string (or an int, in the case of `PHP_URL_PORT`) instead of an array. If the requested component doesn't exist within the given URL, `null` will be returned.
Reference: [https://www.php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-returnvalues PHP Manual: parse_url(): Return Values]
In this case, `parse_url()` is called with the `PHP_URL_PATH` as `$component`. This will return `null` in the majority of cases, as – exсept for subdirectory-based sites – `home_url()` returns a URL without the trailing slash, like `http://example.org`.
The return value of `parse_url()` was subsequently passed to `trim()`, leading to a `trim(): Passing null to parameter #1 ($string) of type string is deprecated` notice on PHP 8.1.
Fixed by adjusting the logic flow to:
* Only pass the return value of `parse_url()` to follow-on functions if it makes sense, i.e. if it isn't `null`, nor an empty string.
* Preventing calls to `preg_replace()` and `trim()` further down in the function logic flow, when `preg_replace()`/`trim()` would have nothing to do anyhow.
Follow-up to [25617].
Props jrf, hellofromTonya, SergeyBiryukov.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51622
git-svn-id: http://core.svn.wordpress.org/trunk@51228 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes a "Deprecated: Automatic conversion of false to array is deprecated" warning on PHP 8.1.
In `wp_schedule_event()`, the cron info array is retrieved via a call to `_get_cron_array()`, but as the documentation (correctly) states, the return type of that function is `array|false`, where `false` is returned for a virgin site, with no cron jobs scheduled yet.
However, no type check is done on the return value, and the `wp_schedule_event()` function just blindly continues by assigning a value to a subkey of the `$crons` "array".
Fixed by adding validation for the returned value from `_get_cron_array()` and initializing an empty array if `false` was returned.
Reference: [https://developer.wordpress.org/reference/functions/_get_cron_array/ WordPress Developer Resources: _get_cron_array()]
Props jrf, hellofromTonya, lucatume, pbearne, iluy, pedromendonca, SergeyBiryukov.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51619
git-svn-id: http://core.svn.wordpress.org/trunk@51225 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Update the `wp_die_handler()` method to pass the response into `WPDieException` so that `expectExceptionCode()` calls work as expected.
Follow-up to [1221/tests], [3934], [4009], [12309].
Props pbearne, jrf, mukesh27.
Fixes#53882.
Built from https://develop.svn.wordpress.org/trunk@51608
git-svn-id: http://core.svn.wordpress.org/trunk@51219 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As per the PHP manual:
> If the `component` parameter is omitted, an associative array is returned.
> If the `component` parameter is specified, `parse_url()` returns a string (or an int, in the case of `PHP_URL_PORT`) instead of an array. If the requested component doesn't exist within the given URL, `null` will be returned.
Reference: [https://www.php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-returnvalues PHP Manual: parse_url(): Return Values]
In this case, `parse_url()` is called with the `PHP_URL_PATH` as `$component`, but the returned value is subsequently checked against `false`.
In other words, this condition would previously always result in `true` and would lead to `null` potentially being passed to the PHP native `pathinfo()` function which expects a string.
On PHP 8.1, this would result in a test failure with a `pathinfo(): Passing null to parameter #1 ($path) of type string is deprecated` error.
Reference: [https://www.php.net/manual/en/function.pathinfo.php PHP Manual: pathinfo()]
Follow-up to [46175].
Props jrf.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51606
git-svn-id: http://core.svn.wordpress.org/trunk@51217 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_UnitTestCase_Base::checkRequirements()` method calls the `parent::checkRequirements()` method, but this method became `private` in PHPUnit 7.0 via commit [932238a6a3sebastianbergmann/phpunit@932238a].
Aside from that, the `TestCase::getAnnotations()` method which is called next is now also removed in PHPUnit 9.5.
WP core does not use the method anymore, and the method only remains to prevent potentially breaking external integration tests relying on the method. However, in effect, the method is not functional anymore in PHPUnit 7.0+.
Follow-up to [893/tests], [894/tests], [896/tests], [918/tests], [30526], [40520], [40564], [43005], [44701], [51559-51577].
Props jrf.
See #46149.
Built from https://develop.svn.wordpress.org/trunk@51605
git-svn-id: http://core.svn.wordpress.org/trunk@51216 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This removes the previously duplicated set of test runs specifically for PHP 8.1 in favor of combining `if` conditions for individual test runs with the `continue-on-error` option.
Follow-up to [51588].
Props desrosj, swissspidy, jrf.
Fixes#53891.
Built from https://develop.svn.wordpress.org/trunk@51604
git-svn-id: http://core.svn.wordpress.org/trunk@51215 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_UnitTestCase_Base::checkRequirements()` method calls the `parent::checkRequirements()` method, but this method became `private` in PHPUnit 7.0 via commit [932238a6a3sebastianbergmann/phpunit@932238a].
Aside from that, the `TestCase::getAnnotations()` method which is called next is now also removed in PHPUnit 9.5.
WP core does not use the method anymore, and the method only remains to prevent potentially breaking external integration tests relying on the method. However, in effect, the method is not functional anymore in PHPUnit 7.0+.
Follow-up to [893/tests], [894/tests], [896/tests], [918/tests], [30526], [40520], [40564], [43005], [44701], [51559-51577].
Props jrf.
See #46149.
Built from https://develop.svn.wordpress.org/trunk@51602
git-svn-id: http://core.svn.wordpress.org/trunk@51213 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The PHPUnit Polyfills are, since [51559], a required dependency for the WP test suite and, by extension, for plugin/theme integration test suites which are based on and use (parts of) the WP core test suite.
However, plugin/theme integration test suites may not use a full WordPress installation.
This commit:
* Removes the presumption that a full WP install, including `vendor` directory, will be available when the test `bootstrap.php` file is run.
* Makes the loading of the PHPUnit Polyfills autoload file more flexible by:
* Checking if the autoload class contained within the autoload file is already available before attempting to load the file.[[BR]]
This allows for plugin/theme integration test suites to load the `phpunitpolyfills-autoload.php` file from any location, as long as it is loaded before the WP core test `bootstrap.php` file is run.
* Allowing for the path to an arbitrary installation location for the PHPUnit Polyfills to be passed as a constant.[[BR]]
As long as the provided location is a valid file path and the `phpunitpolyfills-autoload.php` file exists in the provided location, that file will be loaded.[[BR]]
The constant can be declared in a plugin/theme integration test suite native test bootstrap file, or in the `wp-tests-config.php` file, or even in a `phpunit.xml[.dist]` file via `<php><const name="WP_TESTS_PHPUNIT_POLYFILLS_PATH" value="path/to/yoast/phpunit-polyfills"/></php>`.
* Adds a version check for the PHPUnit Polyfills to prevent a mismatch between the version of the package expected by WordPress and the version used by plugins/themes.[[BR]]
The version this checks for should be in line with the minimum version requirement for the PHPUnit Polyfills as declared in the `composer.json` file.[[BR]]
This version number should only be updated when new features added in later PHPUnit Polyfills releases are actually used in the WP core test suite.
* Adds appropriate error messages for every possible error condition.
* Upgrades the PHPUnit Polyfills to version 1.0.1, which now includes a version constant.
Follow-up to [51559-51577].
Props jrf, hellofromTonya, swissspidy, jeherve, thomasplevy, SergeyBiryukov.
See #46149.
Built from https://develop.svn.wordpress.org/trunk@51598
git-svn-id: http://core.svn.wordpress.org/trunk@51209 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A general security rule is "Sanitize when you save, escape when you echo", and for the most part WordPress has well-named functions like `sanitize_email()` and others, with `esc_url_raw()` being a single exception that does not follow the naming.
This commit restores the previously deprecated `sanitize_url()` function as a valid alias of `esc_url_raw()`.
This better aligns with the naming with other `sanitize_*()` functions:
* `sanitize_bookmark()`
* `sanitize_bookmark_field()`
* `sanitize_category()`
* `sanitize_category_field()`
* `sanitize_comment_cookies()`
* `sanitize_email()`
* `sanitize_file_name()`
* `sanitize_hex_color()`
* `sanitize_hex_color_no_hash()`
* `sanitize_html_class()`
* `sanitize_key()`
* `sanitize_meta()`
* `sanitize_mime_type()`
* `sanitize_option()`
* `sanitize_post()`
* `sanitize_post_field()`
* `sanitize_sql_orderby()`
* `sanitize_term()`
* `sanitize_term_field()`
* `sanitize_text_field()`
* `sanitize_textarea_field()`
* `sanitize_title()`
* `sanitize_title_for_query()`
* `sanitize_title_with_dashes()`
* `sanitize_trackback_urls()`
* `sanitize_user()`
* `sanitize_user_field()`
Follow-up to [11383], [13096].
Props Ipstenu, aadilali.
Fixes#53876.
Built from https://develop.svn.wordpress.org/trunk@51597
git-svn-id: http://core.svn.wordpress.org/trunk@51208 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the original "404" template key was lost when "Default template" is merged into the available templates array, as the `array_merge()` function renumbers numeric keys. Later, when we merge templates on the client side, this caused duplicate "404" templates to appear in the dropdown.
By replacing the `array_merge()` call with `array_replace()`, we make sure to keep the original numeric keys.
Props Mamaduka, Toro_Unit, youknowriad.
Fixes#53898.
Built from https://develop.svn.wordpress.org/trunk@51595
git-svn-id: http://core.svn.wordpress.org/trunk@51206 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes the "Deprecated: Return type of `CountableFake::count()` should be compatible with `Countable::count(): int`" warning on PHP 8.1.
PHP native interfaces now have declared return types and methods in classes implementing these interfaces need to either have the return type declared (in a covariant compatible manner with the PHP native interface method declaration), or need to silence the deprecation warning using the `#[ReturnTypeWillChange]` attribute.
Follow-up to [51517], [51529], [51530], [51531], [51532].
Props jrf.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51594
git-svn-id: http://core.svn.wordpress.org/trunk@51205 1a063a9b-81f0-0310-95a4-ce76da25c4cd
PHP 8.1 is expected to be released at the end of November 2021.
Enabling the tests to run in CI on PHP 8.1 allows us to get WordPress ready in time.
As an interim measure, while working through the PHP 8.1 issues, separate conditional steps are added to run the tests on PHP 8.1 with the `continue-on-error` option. That allows the test builds to show as "successful" if all non-PHP 8.1 test runs pass.
Follow-up to [51517], [51543], [51545], [51574], [51582], [51586].
Props jrf.
Fixes#53891. See #53635.
Built from https://develop.svn.wordpress.org/trunk@51588
git-svn-id: http://core.svn.wordpress.org/trunk@51199 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since PHP 8.1, the `strftime()` and `gmstrftime()` functions are deprecated:
> The `strftime()` and `gmstrftime()` functions exhibit similar issues as `strptime()`, in that the formats they support, as well as their behavior, is platform-dependent. Unlike `strptime()`, these functions are available on Windows, though with a different feature set than on Linux. Musl-based distributions like Alpine do not support timezone-related format specifiers correctly. These functions are also locale-based, and as such may exhibit thread-safety issues.
>
> `date()` or `DateTime::format()` provide portable alternatives, and `IntlDateFormatter::format()` provides a more sophisticated, localization-aware alternative.
Reference: [https://wiki.php.net/rfc/deprecations_php_8_1#strftime_and_gmstrftime PHP RFC: Deprecations for PHP 8.1: strftime() and gmstrftime()]
> The `strftime()` and `gmstrftime()` functions have been deprecated in favor of
> `date()/DateTime::format()` (for locale-independent formatting) or
> `IntlDateFormatter::format()` (for locale-dependent formatting).
Reference: [1cf4fb739f/UPGRADING (L379-L381) PHP 8.1 Upgrade Notes].
Aside from one instance in SimplePie, the `strftime()` and `gmstrftime()` functions are only used within the test suite of WordPress to create formatted timestamps.
As the function is used in test code, this leads to test warnings like this on PHP 8.1:
{{{
Deprecated: Function strftime() is deprecated in path/to/tests/phpunit/tests/canonical/postStatus.php on line 37
}}}
These calls can all be safely converted to use a pattern along the lines of:
{{{#!php
<?php
date_format( date_create( 'time phrase or timestamp' ), $format )
}}}
Other references:
* [https://www.php.net/manual/en/function.strftime.php PHP Manual: strftime()] (for the old format string characters)
* [https://www.php.net/manual/en/datetime.format.php PHP Manual: DateTime::format()] (for the new format string characters)
* [https://www.php.net/manual/en/datetime.construct.php PHP Manual: DateTime::__construct()] (see Example 2 for a Unix timestamp code sample)
Props jrf, SergeyBiryukov.
Fixes#53897.
Built from https://develop.svn.wordpress.org/trunk@51587
git-svn-id: http://core.svn.wordpress.org/trunk@51198 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since PHP 8.1, `readonly` is a reserved keyword and cannot be used as a function name.
In order to avoid PHP parser errors, the `readonly()` function was extracted to a separate file and is now only included conditionally on PHP < 8.1.
This commit also:
* Moves the tests for the `__checked_selected_helper()` function and all the related functions to their own file.
* Switches to named data providers. This makes the output when using the `--testdox` option more descriptive and is helpful when trying to debug which data set from a data provider failed the test.
* Improves the tests in question to make them feature-complete and expand test coverage.
Props jrf, ayeshrajans, haosun, knutsp, swissspidy, SergeyBiryukov.
Fixes#53858.
Built from https://develop.svn.wordpress.org/trunk@51586
git-svn-id: http://core.svn.wordpress.org/trunk@51197 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Not all CLI tools can handle Unicode characters or non-system specific line endings well, so this type of CLI messaging should always be written with the optimal cross-platform, cross-CLI tool end-user experience in mind.
Follow-up to [51581].
Props jrf.
See #53363.
Built from https://develop.svn.wordpress.org/trunk@51584
git-svn-id: http://core.svn.wordpress.org/trunk@51195 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The current config files validate against the PHPUnit XSD schema for config files for PHPUnit 5.7 – 9.2.
The schema was changed in PHPUnit 9.3, and the `filter` and `logging` settings were deprecated in favor of `coverage` and a different format for `logging`.
This commit explicitly sets the schema against which the files currently validate, for clarity.
Props jrf.
See #53363.
Built from https://develop.svn.wordpress.org/trunk@51583
git-svn-id: http://core.svn.wordpress.org/trunk@51194 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to PHP 8.1, the default error handling mode was `MYSQLI_REPORT_OFF`. An error in the extension, database, query, or the database connection returned `false` and emitted a PHP warning:
{{{
$mysqli = new mysqli("localhost", "non-existing-user", "", "");
Warning: mysqli::__construct(): (HY000/2002): No connection could be made because the target machine actively refused it in ... on line ...
}}}
From PHP 8.1 and later, the default error mode is set to `MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT`. An error in the extension, database, query, or the database connection throws an exception:
{{{
$mysqli = new mysqli("localhost", "non-existing-user", "", "");
Fatal error: Uncaught mysqli_sql_exception: Connection refused in ...:...
}}}
WordPress has its own error reporting and gracefully handles the database errors by inspecting the error codes. Setting the MySQLi error reporting to off avoids fatal errors due to uncaught exceptions and maintains the current behavior.
References:
* [https://php.watch/versions/8.1/mysqli-error-mode PHP 8.1: MySQLi: Default error mode set to exceptions]
* [https://wiki.php.net/rfc/mysqli_default_errmode PHP RFC: Change Default mysqli Error Mode]
Props ayeshrajans, jrf.
Fixes#52825.
Built from https://develop.svn.wordpress.org/trunk@51582
git-svn-id: http://core.svn.wordpress.org/trunk@51193 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Any messages to the user which are echo-ed out in the test bootstrap will generally display on a command-line interface.
The *nix specific `"\n"` line ending will be ignored on Windows, making the messages less readable.
For new lines in CLI messages, `PHP_EOL` should be used instead.
This was already done in a few places in the script, but not consistently so. Fixed now.
Follow-up to [UT882], [UT890], [44723], [45020], [48592], [49535], [51560].
Props jrf.
See #53363.
Built from https://develop.svn.wordpress.org/trunk@51581
git-svn-id: http://core.svn.wordpress.org/trunk@51192 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This replaces instances of `assertTrue( is_dir( ... ) )` with `assertDirectoryExists()` to use native PHPUnit functionality.
The `assertDirectoryExists()` method was introduced in PHPUnit 5.6. As the minimum supported PHPUnit version has been raised to PHPUnit 5.7.21, it can now be used.
Follow-up to [51543], [51574], [51579].
Props jrf.
See #53363.
Built from https://develop.svn.wordpress.org/trunk@51580
git-svn-id: http://core.svn.wordpress.org/trunk@51191 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Sergey Biryukov
Peter Wilson
gziolo