Testing 52728 / debugging the test #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…vant test Quick hack to make the preserve GH resources and get results quicker while testing this issue.
|
@dlh01 Just FYI: I've added two commits to help with debugging - the first "DELETE" commit is just slimming down the actions being run to those we need to see the output of this particular test, which should make the results of pushes accessible a lot faster. |
jrfnl
pushed a commit
that referenced
this pull request
Aug 4, 2021
… `wp_default_packages_inline_scripts()`. This fixes a "Deprecated: `DateTime::__construct()`: Passing null to parameter #1 (`$datetime`) of type string is deprecated" warning on PHP 8.1. Follow-up to [49083]. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51533 602fd350-edb4-49c9-b593-d223f7449a82
jrfnl
added a commit
that referenced
this pull request
Aug 8, 2021
Fixes `strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated` notices on PHP 8.1. Impact: 38 of the pre-existing tests are affected by this issue.
jrfnl
added a commit
that referenced
this pull request
Aug 8, 2021
Fixes `strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated` notices on PHP 8.1. Impact: 38 of the pre-existing tests are affected by this issue.
jrfnl
added a commit
that referenced
this pull request
Aug 9, 2021
Fixes `parse_str(): Passing null to parameter #1 ($string) of type string is deprecated` notices on PHP 8.1. Impact: 311 of the pre-existing tests are affected by this issue.
jrfnl
added a commit
that referenced
this pull request
Aug 9, 2021
Fixes `strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated` notices on PHP 8.1. Impact: 38 of the pre-existing tests are affected by this issue.
jrfnl
added a commit
that referenced
this pull request
Aug 9, 2021
Fixes `parse_str(): Passing null to parameter #1 ($string) of type string is deprecated` notices on PHP 8.1. Impact: 311 of the pre-existing tests are affected by this issue.
jrfnl
added a commit
that referenced
this pull request
Aug 11, 2021
Fixes `strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated` notices on PHP 8.1. Impact: 38 of the pre-existing tests are affected by this issue.
jrfnl
added a commit
that referenced
this pull request
Aug 11, 2021
Fixes `strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated` notices on PHP 8.1. Impact: 38 of the pre-existing tests are affected by this issue.
jrfnl
added a commit
that referenced
this pull request
Aug 11, 2021
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.
jrfnl
added a commit
that referenced
this pull request
Aug 11, 2021
… function The output of the call to `parse_url()` stored in the `$url_path` variable is used in more places in the function logic. This test exposes a second PHP 8.1 deprecation notice, this time for `substr(): Passing null to parameter #1 ($string) of type string is deprecated`.
jrfnl
added a commit
that referenced
this pull request
Aug 12, 2021
…notice 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. Ref: https://www.php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-returnvalues In this case, `parse_url()` is called with the `PHP_URL_PATH` as `$component`. This will return `null` in the majority of cases, as - expect for subdirectory-based sites - `home_url()` will return a URL without 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` deprecation 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.
jrfnl
added a commit
that referenced
this pull request
Aug 12, 2021
…notice 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. Ref: https://www.php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-returnvalues In this case, `parse_url()` is called with the `PHP_URL_PATH` as `$component`. This will return `null` in the majority of cases, as - expect for subdirectory-based sites - `home_url()` will return a URL without 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` deprecation 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.
jrfnl
pushed a commit
that referenced
this pull request
Aug 13, 2021
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. git-svn-id: https://develop.svn.wordpress.org/trunk@51606 602fd350-edb4-49c9-b593-d223f7449a82
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
…able" notice 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` deprecation notice. Changing the logic around and adding validation for the return type value of `parse_url()` prevents that.
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
…" notice 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` deprecation notice. Changing the logic around and adding validation for the return type value of `parse_url()` prevents that. Unfortunately, as this function is declaring global constants, adding tests for this change is not really an option without potentially affecting other tests. Also note, that it is possible, though unlikely, for the option to not be available. In that case though, the `get_option()` method returns `false` and while passing that to `parse_url()` does not deserve any prices for clean code, it also is not problematic (at this point in time).
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
Fixes `parse_str(): Passing null to parameter #1 ($string) of type string is deprecated` notices on PHP 8.1. Impact: 311 of the pre-existing tests are affected by this issue.
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
Fixes `parse_str(): Passing null to parameter #1 ($string) of type string is deprecated` notices on PHP 8.1. Impact: 311 of the pre-existing tests are affected by this issue.
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
…notice 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. Ref: https://www.php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-returnvalues In this case, `parse_url()` is called with the `PHP_URL_PATH` as `$component`. This will return `null` in the majority of cases, as - expect for subdirectory-based sites - `home_url()` will return a URL without 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` deprecation 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.
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
…able" notice 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` deprecation notice. Changing the logic around and adding validation for the return type value of `parse_url()` prevents that.
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
…" notice 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` deprecation notice. Changing the logic around and adding validation for the return type value of `parse_url()` prevents that. Unfortunately, as this function is declaring global constants, adding tests for this change is not really an option without potentially affecting other tests. Also note, that it is possible, though unlikely, for the option to not be available. In that case though, the `get_option()` method returns `false` and while passing that to `parse_url()` does not deserve any prices for clean code, it also is not problematic (at this point in time).
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
…able" notice 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` deprecation notice. Changing the logic around and adding validation for the return type value of `parse_url()` prevents that.
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
…" notice 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` deprecation notice. Changing the logic around and adding validation for the return type value of `parse_url()` prevents that. Unfortunately, as this function is declaring global constants, adding tests for this change is not really an option without potentially affecting other tests. Also note, that it is possible, though unlikely, for the option to not be available. In that case though, the `get_option()` method returns `false` and while passing that to `parse_url()` does not deserve any prices for clean code, it also is not problematic (at this point in time).
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
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.
jrfnl
added a commit
that referenced
this pull request
Aug 13, 2021
… function The output of the call to `parse_url()` stored in the `$url_path` variable is used in more places in the function logic. This test exposes a second PHP 8.1 deprecation notice, this time for `substr(): Passing null to parameter #1 ($string) of type string is deprecated`.
jrfnl
added a commit
that referenced
this pull request
Sep 12, 2022
…lable and more The `wp_xmlrpc_server::mw_newPost()` method creates a new post via `wp_insert_post()`, but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. For this commit, I've: * Ensured that all arguments are defined before they are `compact()`-ed together to the arguments array. * Verified that the default/fall-back value of the arguments as set within the `wp_xmlrpc_server::mw_newPost()` method are the same as the default/fall-back values used in the `wp_insert_post()` function. * Verified that arguments which do not have a default/fall-back value defined in the `wp_insert_post()` function are handled correctly. - This was not the case for `$post_name`, which would previously already get an empty string default value in the `wp_xmlrpc_server::mw_newPost()` function, but then in the `wp_insert_post()` function, this would prevent the slug generation from being activated. Fixed now by setting the default in the `wp_xmlrpc_server::mw_newPost()` function to `null`.. - The `page_template` argument was handled, but not documented in the `wp_insert_post()` function. I've now documented the argument in the `wp_insert_post()` function docblock. Note: there are more than likely several other potential arguments missing from that list, but verifying the whole list is outside the scope of this particular commit. Includes minor simplifications, such as: * Setting a default ahead of an `if`, instead of in an `else` clause (as long as no function call is needed to set the default). * Remove the unnecessary logic duplication in the `$post_status` switch. * Using a combined concatenation + assignment operator for adding `$post_more`. Fixes various errors along the lines of: ``` 1) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated /var/www/src/wp-includes/formatting.php:2497 /var/www/src/wp-includes/class-wp-hook.php:308 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5616 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 ``` ``` 23) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5615 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 12, 2022
…ullable and more The `wp_xmlrpc_server::_insert_post()` method creates a new post via `wp_insert_post()` or updates an existing one via `wp_update_post()` (which subsequently calls `wp_insert_post()`), but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. Unfortunately, the conditional logic within the `wp_xmlrpc_server::_insert_post()` function itself often uses an `isset()` to trigger certain code blocks., so syncing the defaults with those used in the `wp_insert_post()` function was not an option. So for this commit, I've: * I've updated the default/fall-back values in the `$defaults` array only for those values where this would not lead to a change in the behaviour of the function. * I've also added a safeguard function, filtering out all remaining `null` values from the `$post_data` array before it is passed on to the `wp_insert_post()` or `wp_update_post()` functions. Removing those values is safe as this means that these array keys will now: - either be set to the default/fall-back value as defined in `wp_insert_post()`. - or not be set and for those values which don't have a default/fall-back value in `wp_insert_post()`, `wp_insert_post()` does an `! empty()` or `isset()` check anyway and those array keys not being defined means that the result of those checks will remain the same. Includes removing a couple of conditions which are now redundant. Includes removing an `expectDeprecation()` in the `Tests_Date_XMLRPC` test class, which is now no longer needed. Fixes various errors along the lines of: ``` 36) Tests_XMLRPC_wp_newPost::test_no_content json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1683 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1347 /var/www/tests/phpunit/tests/xmlrpc/wp/newPost.php:25 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 12, 2022
…o non-nullable Not all requests are accompanied by a `$request['email']`. This leads to a PHP 8.1 "passing null to non-nullable" deprecation notice when the `WP_REST_Users_Controller::update_item()` method passes a `null` email address onto `email_exists()`, which eventually reached the `WP_User::get_data_by()` method where things go wrong. In the next condition in the code of the `WP_REST_Users_Controller::update_item()` method - `if ( $owner_id && $owner_id !== $id )` - you can see that the code already takes this into account as it will not throw a `WP_Error` if `$owner_id` is falsey. `WP_User::get_data_by()` returns `false` for a failed field request. The other functions through which the return value is passed through, do the same. So, by setting a default value for `$owner_id` of `false` and only checking `email_exists()` when there is an email to check, the "passing null to non-nullable" deprecation notice is bypassed without breaking BC. Fixes a whole slew of test errors along the lines of: ``` 6) WP_Test_REST_Users_Controller::test_update_item_en_US_locale trim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/class-wp-user.php:211 /var/www/src/wp-includes/pluggable.php:105 /var/www/src/wp-includes/user.php:1953 /var/www/src/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php:728 /var/www/src/wp-includes/rest-api/class-wp-rest-server.php:1143 /var/www/src/wp-includes/rest-api/class-wp-rest-server.php:990 /var/www/tests/phpunit/includes/spy-rest-server.php:67 /var/www/tests/phpunit/tests/rest-api/rest-users-controller.php:1719 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 12, 2022
The `$path` parameter has a default value of `null`, but would be passed onto the `untrailingslashit()` function without any input validation, even though the `untrailingslashit()` function explicitly only expects/supports a string input. > 👉 An alternative - and possibly better - solution would be to change the default value of the `$path` parameter to an empty string. > However, such a change would have a wider impact as all function calls which currently pass the `null` default value for `$path` would need to be updated as well. Within WP, this is largely an issue in the tests, but it _could_ potentially have an impact on external calls to the function as well. Note: I'm explicitly not changing the `untrailingslashit()` function, but fixing this at the point where the invalid input is incorrectly (not) validated. Includes adding a dedicated unit test for this issue. This fix also allows to remove a couple of calls to `expectDeprecation()` in unrelated tests. Fixes: ``` 4) Tests_Dependencies_Scripts::test_wp_external_wp_i18n_print_order rtrim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/formatting.php:2782 /var/www/src/wp-includes/l10n.php:1068 /var/www/src/wp-includes/class.wp-scripts.php:605 /var/www/src/wp-includes/class.wp-scripts.php:320 /var/www/src/wp-includes/class.wp-dependencies.php:136 /var/www/src/wp-includes/functions.wp-scripts.php:109 /var/www/tests/phpunit/tests/dependencies/scripts.php:1505 /var/www/tests/phpunit/includes/utils.php:436 /var/www/tests/phpunit/tests/dependencies/scripts.php:1507 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 12, 2022
…lable and more The `wp_xmlrpc_server::mw_newPost()` method creates a new post via `wp_insert_post()`, but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. For this commit, I've: * Ensured that all arguments are defined before they are `compact()`-ed together to the arguments array. * Verified that the default/fall-back value of the arguments as set within the `wp_xmlrpc_server::mw_newPost()` method are the same as the default/fall-back values used in the `wp_insert_post()` function. * Verified that arguments which do not have a default/fall-back value defined in the `wp_insert_post()` function are handled correctly. - This was not the case for `$post_name`, which would previously already get an empty string default value in the `wp_xmlrpc_server::mw_newPost()` function, but then in the `wp_insert_post()` function, this would prevent the slug generation from being activated. Fixed now by setting the default in the `wp_xmlrpc_server::mw_newPost()` function to `null`.. - The `page_template` argument was handled, but not documented in the `wp_insert_post()` function. I've now documented the argument in the `wp_insert_post()` function docblock. Note: there are more than likely several other potential arguments missing from that list, but verifying the whole list is outside the scope of this particular commit. Includes minor simplifications, such as: * Setting a default ahead of an `if`, instead of in an `else` clause (as long as no function call is needed to set the default). * Remove the unnecessary logic duplication in the `$post_status` switch. * Using a combined concatenation + assignment operator for adding `$post_more`. Fixes various errors along the lines of: ``` 1) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated /var/www/src/wp-includes/formatting.php:2497 /var/www/src/wp-includes/class-wp-hook.php:308 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5616 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 ``` ``` 23) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5615 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 12, 2022
…ullable and more The `wp_xmlrpc_server::_insert_post()` method creates a new post via `wp_insert_post()` or updates an existing one via `wp_update_post()` (which subsequently calls `wp_insert_post()`), but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. Unfortunately, the conditional logic within the `wp_xmlrpc_server::_insert_post()` function itself often uses an `isset()` to trigger certain code blocks., so syncing the defaults with those used in the `wp_insert_post()` function was not an option. So for this commit, I've: * I've updated the default/fall-back values in the `$defaults` array only for those values where this would not lead to a change in the behaviour of the function. * I've also added a safeguard function, filtering out all remaining `null` values from the `$post_data` array before it is passed on to the `wp_insert_post()` or `wp_update_post()` functions. Removing those values is safe as this means that these array keys will now: - either be set to the default/fall-back value as defined in `wp_insert_post()`. - or not be set and for those values which don't have a default/fall-back value in `wp_insert_post()`, `wp_insert_post()` does an `! empty()` or `isset()` check anyway and those array keys not being defined means that the result of those checks will remain the same. Includes removing a couple of conditions which are now redundant. Includes removing an `expectDeprecation()` in the `Tests_Date_XMLRPC` test class, which is now no longer needed. Fixes various errors along the lines of: ``` 36) Tests_XMLRPC_wp_newPost::test_no_content json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1683 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1347 /var/www/tests/phpunit/tests/xmlrpc/wp/newPost.php:25 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 12, 2022
…o non-nullable Not all requests are accompanied by a `$request['email']`. This leads to a PHP 8.1 "passing null to non-nullable" deprecation notice when the `WP_REST_Users_Controller::update_item()` method passes a `null` email address onto `email_exists()`, which eventually reached the `WP_User::get_data_by()` method where things go wrong. In the next condition in the code of the `WP_REST_Users_Controller::update_item()` method - `if ( $owner_id && $owner_id !== $id )` - you can see that the code already takes this into account as it will not throw a `WP_Error` if `$owner_id` is falsey. `WP_User::get_data_by()` returns `false` for a failed field request. The other functions through which the return value is passed through, do the same. So, by setting a default value for `$owner_id` of `false` and only checking `email_exists()` when there is an email to check, the "passing null to non-nullable" deprecation notice is bypassed without breaking BC. Fixes a whole slew of test errors along the lines of: ``` 6) WP_Test_REST_Users_Controller::test_update_item_en_US_locale trim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/class-wp-user.php:211 /var/www/src/wp-includes/pluggable.php:105 /var/www/src/wp-includes/user.php:1953 /var/www/src/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php:728 /var/www/src/wp-includes/rest-api/class-wp-rest-server.php:1143 /var/www/src/wp-includes/rest-api/class-wp-rest-server.php:990 /var/www/tests/phpunit/includes/spy-rest-server.php:67 /var/www/tests/phpunit/tests/rest-api/rest-users-controller.php:1719 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 20, 2022
The `$path` parameter has a default value of `null`, but would be passed onto the `untrailingslashit()` function without any input validation, even though the `untrailingslashit()` function explicitly only expects/supports a string input. Note: I'm explicitly not changing the `untrailingslashit()` function, but fixing this at the point where the invalid input is incorrectly (not) validated. Includes adding a dedicated unit test for this issue. This fix also allows to remove a couple of calls to `expectDeprecation()` in unrelated tests. Fixes: ``` 4) Tests_Dependencies_Scripts::test_wp_external_wp_i18n_print_order rtrim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/formatting.php:2782 /var/www/src/wp-includes/l10n.php:1068 /var/www/src/wp-includes/class.wp-scripts.php:605 /var/www/src/wp-includes/class.wp-scripts.php:320 /var/www/src/wp-includes/class.wp-dependencies.php:136 /var/www/src/wp-includes/functions.wp-scripts.php:109 /var/www/tests/phpunit/tests/dependencies/scripts.php:1505 /var/www/tests/phpunit/includes/utils.php:436 /var/www/tests/phpunit/tests/dependencies/scripts.php:1507 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 20, 2022
…lable and more The `wp_xmlrpc_server::mw_newPost()` method creates a new post via `wp_insert_post()`, but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. For this commit, I've: * Ensured that all arguments are defined before they are `compact()`-ed together to the arguments array. * Verified that the default/fall-back value of the arguments as set within the `wp_xmlrpc_server::mw_newPost()` method are the same as the default/fall-back values used in the `wp_insert_post()` function. * Verified that arguments which do not have a default/fall-back value defined in the `wp_insert_post()` function are handled correctly. - This was not the case for `$post_name`, which would previously already get an empty string default value in the `wp_xmlrpc_server::mw_newPost()` function, but then in the `wp_insert_post()` function, this would prevent the slug generation from being activated. Fixed now by setting the default in the `wp_xmlrpc_server::mw_newPost()` function to `null`.. - The `page_template` argument was handled, but not documented in the `wp_insert_post()` function. I've now documented the argument in the `wp_insert_post()` function docblock. Note: there are more than likely several other potential arguments missing from that list, but verifying the whole list is outside the scope of this particular commit. Includes minor simplifications, such as: * Setting a default ahead of an `if`, instead of in an `else` clause (as long as no function call is needed to set the default). * Remove the unnecessary logic duplication in the `$post_status` switch. * Using a combined concatenation + assignment operator for adding `$post_more`. Fixes various errors along the lines of: ``` 1) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated /var/www/src/wp-includes/formatting.php:2497 /var/www/src/wp-includes/class-wp-hook.php:308 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5616 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 ``` ``` 23) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5615 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 20, 2022
…ullable and more The `wp_xmlrpc_server::_insert_post()` method creates a new post via `wp_insert_post()` or updates an existing one via `wp_update_post()` (which subsequently calls `wp_insert_post()`), but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. Unfortunately, the conditional logic within the `wp_xmlrpc_server::_insert_post()` function itself often uses an `isset()` to trigger certain code blocks., so syncing the defaults with those used in the `wp_insert_post()` function was not an option. So for this commit, I've: * I've updated the default/fall-back values in the `$defaults` array only for those values where this would not lead to a change in the behaviour of the function. * I've also added a safeguard function, filtering out all remaining `null` values from the `$post_data` array before it is passed on to the `wp_insert_post()` or `wp_update_post()` functions. Removing those values is safe as this means that these array keys will now: - either be set to the default/fall-back value as defined in `wp_insert_post()`. - or not be set and for those values which don't have a default/fall-back value in `wp_insert_post()`, `wp_insert_post()` does an `! empty()` or `isset()` check anyway and those array keys not being defined means that the result of those checks will remain the same. Includes removing a couple of conditions which are now redundant. Includes removing an `expectDeprecation()` in the `Tests_Date_XMLRPC` test class, which is now no longer needed. Fixes various errors along the lines of: ``` 36) Tests_XMLRPC_wp_newPost::test_no_content json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1683 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1347 /var/www/tests/phpunit/tests/xmlrpc/wp/newPost.php:25 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 20, 2022
…o non-nullable Not all requests are accompanied by a `$request['email']`. This leads to a PHP 8.1 "passing null to non-nullable" deprecation notice when the `WP_REST_Users_Controller::update_item()` method passes a `null` email address onto `email_exists()`, which eventually reached the `WP_User::get_data_by()` method where things go wrong. In the next condition in the code of the `WP_REST_Users_Controller::update_item()` method - `if ( $owner_id && $owner_id !== $id )` - you can see that the code already takes this into account as it will not throw a `WP_Error` if `$owner_id` is falsey. `WP_User::get_data_by()` returns `false` for a failed field request. The other functions through which the return value is passed through, do the same. So, by setting a default value for `$owner_id` of `false` and only checking `email_exists()` when there is an email to check, the "passing null to non-nullable" deprecation notice is bypassed without breaking BC. Fixes a whole slew of test errors along the lines of: ``` 6) WP_Test_REST_Users_Controller::test_update_item_en_US_locale trim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/class-wp-user.php:211 /var/www/src/wp-includes/pluggable.php:105 /var/www/src/wp-includes/user.php:1953 /var/www/src/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php:728 /var/www/src/wp-includes/rest-api/class-wp-rest-server.php:1143 /var/www/src/wp-includes/rest-api/class-wp-rest-server.php:990 /var/www/tests/phpunit/includes/spy-rest-server.php:67 /var/www/tests/phpunit/tests/rest-api/rest-users-controller.php:1719 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 20, 2022
The `$path` parameter has a default value of `null`, but would be passed onto the `untrailingslashit()` function without any input validation, even though the `untrailingslashit()` function explicitly only expects/supports a string input. > 👉 An alternative - and possibly better - solution would be to change the default value of the `$path` parameter to an empty string. > However, such a change would have a wider impact as all function calls which currently pass the `null` default value for `$path` would need to be updated as well. Within WP, this is largely an issue in the tests, but it _could_ potentially have an impact on external calls to the function as well. Note: I'm explicitly not changing the `untrailingslashit()` function, but fixing this at the point where the invalid input is incorrectly (not) validated. Includes adding a dedicated unit test for this issue. This fix also allows to remove a couple of calls to `expectDeprecation()` in unrelated tests. Fixes: ``` 4) Tests_Dependencies_Scripts::test_wp_external_wp_i18n_print_order rtrim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/formatting.php:2782 /var/www/src/wp-includes/l10n.php:1068 /var/www/src/wp-includes/class.wp-scripts.php:605 /var/www/src/wp-includes/class.wp-scripts.php:320 /var/www/src/wp-includes/class.wp-dependencies.php:136 /var/www/src/wp-includes/functions.wp-scripts.php:109 /var/www/tests/phpunit/tests/dependencies/scripts.php:1505 /var/www/tests/phpunit/includes/utils.php:436 /var/www/tests/phpunit/tests/dependencies/scripts.php:1507 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 20, 2022
…lable and more The `wp_xmlrpc_server::mw_newPost()` method creates a new post via `wp_insert_post()`, but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. For this commit, I've: * Ensured that all arguments are defined before they are `compact()`-ed together to the arguments array. * Verified that the default/fall-back value of the arguments as set within the `wp_xmlrpc_server::mw_newPost()` method are the same as the default/fall-back values used in the `wp_insert_post()` function. * Verified that arguments which do not have a default/fall-back value defined in the `wp_insert_post()` function are handled correctly. - This was not the case for `$post_name`, which would previously already get an empty string default value in the `wp_xmlrpc_server::mw_newPost()` function, but then in the `wp_insert_post()` function, this would prevent the slug generation from being activated. Fixed now by setting the default in the `wp_xmlrpc_server::mw_newPost()` function to `null`.. - The `page_template` argument was handled, but not documented in the `wp_insert_post()` function. I've now documented the argument in the `wp_insert_post()` function docblock. Note: there are more than likely several other potential arguments missing from that list, but verifying the whole list is outside the scope of this particular commit. Includes minor simplifications, such as: * Setting a default ahead of an `if`, instead of in an `else` clause (as long as no function call is needed to set the default). * Remove the unnecessary logic duplication in the `$post_status` switch. * Using a combined concatenation + assignment operator for adding `$post_more`. Fixes various errors along the lines of: ``` 1) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated /var/www/src/wp-includes/formatting.php:2497 /var/www/src/wp-includes/class-wp-hook.php:308 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5616 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 ``` ``` 23) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5615 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 20, 2022
…ullable and more The `wp_xmlrpc_server::_insert_post()` method creates a new post via `wp_insert_post()` or updates an existing one via `wp_update_post()` (which subsequently calls `wp_insert_post()`), but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. Unfortunately, the conditional logic within the `wp_xmlrpc_server::_insert_post()` function itself often uses an `isset()` to trigger certain code blocks., so syncing the defaults with those used in the `wp_insert_post()` function was not an option. So for this commit, I've: * I've updated the default/fall-back values in the `$defaults` array only for those values where this would not lead to a change in the behaviour of the function. * I've also added a safeguard function, filtering out all remaining `null` values from the `$post_data` array before it is passed on to the `wp_insert_post()` or `wp_update_post()` functions. Removing those values is safe as this means that these array keys will now: - either be set to the default/fall-back value as defined in `wp_insert_post()`. - or not be set and for those values which don't have a default/fall-back value in `wp_insert_post()`, `wp_insert_post()` does an `! empty()` or `isset()` check anyway and those array keys not being defined means that the result of those checks will remain the same. Includes removing a couple of conditions which are now redundant. Includes removing an `expectDeprecation()` in the `Tests_Date_XMLRPC` test class, which is now no longer needed. Fixes various errors along the lines of: ``` 36) Tests_XMLRPC_wp_newPost::test_no_content json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1683 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1347 /var/www/tests/phpunit/tests/xmlrpc/wp/newPost.php:25 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 20, 2022
…o non-nullable Not all requests are accompanied by a `$request['email']`. This leads to a PHP 8.1 "passing null to non-nullable" deprecation notice when the `WP_REST_Users_Controller::update_item()` method passes a `null` email address onto `email_exists()`, which eventually reached the `WP_User::get_data_by()` method where things go wrong. In the next condition in the code of the `WP_REST_Users_Controller::update_item()` method - `if ( $owner_id && $owner_id !== $id )` - you can see that the code already takes this into account as it will not throw a `WP_Error` if `$owner_id` is falsey. `WP_User::get_data_by()` returns `false` for a failed field request. The other functions through which the return value is passed through, do the same. So, by setting a default value for `$owner_id` of `false` and only checking `email_exists()` when there is an email to check, the "passing null to non-nullable" deprecation notice is bypassed without breaking BC. Fixes a whole slew of test errors along the lines of: ``` 6) WP_Test_REST_Users_Controller::test_update_item_en_US_locale trim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/class-wp-user.php:211 /var/www/src/wp-includes/pluggable.php:105 /var/www/src/wp-includes/user.php:1953 /var/www/src/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php:728 /var/www/src/wp-includes/rest-api/class-wp-rest-server.php:1143 /var/www/src/wp-includes/rest-api/class-wp-rest-server.php:990 /var/www/tests/phpunit/includes/spy-rest-server.php:67 /var/www/tests/phpunit/tests/rest-api/rest-users-controller.php:1719 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 26, 2022
The `$path` parameter has a default value of `null`, but would be passed onto the `untrailingslashit()` function without any input validation, even though the `untrailingslashit()` function explicitly only expects/supports a string input. Note: I'm explicitly not changing the `untrailingslashit()` function, but fixing this at the point where the invalid input is incorrectly (not) validated. Includes adding a dedicated unit test for this issue. This fix also allows to remove a couple of calls to `expectDeprecation()` in unrelated tests. Fixes: ``` 4) Tests_Dependencies_Scripts::test_wp_external_wp_i18n_print_order rtrim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/formatting.php:2782 /var/www/src/wp-includes/l10n.php:1068 /var/www/src/wp-includes/class.wp-scripts.php:605 /var/www/src/wp-includes/class.wp-scripts.php:320 /var/www/src/wp-includes/class.wp-dependencies.php:136 /var/www/src/wp-includes/functions.wp-scripts.php:109 /var/www/tests/phpunit/tests/dependencies/scripts.php:1505 /var/www/tests/phpunit/includes/utils.php:436 /var/www/tests/phpunit/tests/dependencies/scripts.php:1507 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 26, 2022
…lable and more The `wp_xmlrpc_server::mw_newPost()` method creates a new post via `wp_insert_post()`, but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. For this commit, I've: * Ensured that all arguments are defined before they are `compact()`-ed together to the arguments array. * Verified that the default/fall-back value of the arguments as set within the `wp_xmlrpc_server::mw_newPost()` method are the same as the default/fall-back values used in the `wp_insert_post()` function. * Verified that arguments which do not have a default/fall-back value defined in the `wp_insert_post()` function are handled correctly. - This was not the case for `$post_name`, which would previously already get an empty string default value in the `wp_xmlrpc_server::mw_newPost()` function, but then in the `wp_insert_post()` function, this would prevent the slug generation from being activated. Fixed now by setting the default in the `wp_xmlrpc_server::mw_newPost()` function to `null`.. - The `page_template` argument was handled, but not documented in the `wp_insert_post()` function. I've now documented the argument in the `wp_insert_post()` function docblock. Note: there are more than likely several other potential arguments missing from that list, but verifying the whole list is outside the scope of this particular commit. Includes minor simplifications, such as: * Setting a default ahead of an `if`, instead of in an `else` clause (as long as no function call is needed to set the default). * Remove the unnecessary logic duplication in the `$post_status` switch. * Using a combined concatenation + assignment operator for adding `$post_more`. Fixes various errors along the lines of: ``` 1) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated /var/www/src/wp-includes/formatting.php:2497 /var/www/src/wp-includes/class-wp-hook.php:308 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5616 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 ``` ``` 23) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5615 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 26, 2022
…ullable and more The `wp_xmlrpc_server::_insert_post()` method creates a new post via `wp_insert_post()` or updates an existing one via `wp_update_post()` (which subsequently calls `wp_insert_post()`), but the default/fall-back values used in the function were not in line with the default/fall-back values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments would be `null`, this would overwrite the default value (see: https://3v4l.org/bfVlv ) and will lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. Unfortunately, the conditional logic within the `wp_xmlrpc_server::_insert_post()` function itself often uses an `isset()` to trigger certain code blocks., so syncing the defaults with those used in the `wp_insert_post()` function was not an option. So for this commit, I've: * I've updated the default/fall-back values in the `$defaults` array only for those values where this would not lead to a change in the behaviour of the function. * I've also added a safeguard function, filtering out all remaining `null` values from the `$post_data` array before it is passed on to the `wp_insert_post()` or `wp_update_post()` functions. Removing those values is safe as this means that these array keys will now: - either be set to the default/fall-back value as defined in `wp_insert_post()`. - or not be set and for those values which don't have a default/fall-back value in `wp_insert_post()`, `wp_insert_post()` does an `! empty()` or `isset()` check anyway and those array keys not being defined means that the result of those checks will remain the same. Includes removing a couple of conditions which are now redundant. Includes removing an `expectDeprecation()` in the `Tests_Date_XMLRPC` test class, which is now no longer needed. Fixes various errors along the lines of: ``` 36) Tests_XMLRPC_wp_newPost::test_no_content json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1683 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1347 /var/www/tests/phpunit/tests/xmlrpc/wp/newPost.php:25 /var/www/vendor/bin/phpunit:123 ```
jrfnl
pushed a commit
that referenced
this pull request
Sep 27, 2022
…pc_server::mw_newPost()`. The `wp_xmlrpc_server::mw_newPost()` method creates a new post via `wp_insert_post()`, but the default/fallback values used in the function were not in line with the default/fallback values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments are `null`, this would overwrite the default value, as seen in [https://3v4l.org/bfVlv array_merge() example], and lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. This commit: * Ensures that all arguments are defined before they are `compact()`'ed together to the arguments array. * Verifies that the default/fallback value of the arguments as set within the `wp_xmlrpc_server::mw_newPost()` method are the same as the default/fallback values used in the `wp_insert_post()` function. * Verifies that arguments which do not have a default/fallback value defined in the `wp_insert_post()` function are handled correctly. * This was not the case for `$post_name`, which would previously already get an empty string default value in the `wp_xmlrpc_server::mw_newPost()` function, but then in the `wp_insert_post()` function, this would prevent the slug generation from being activated. Fixed now by setting the default in the `wp_xmlrpc_server::mw_newPost()` function to `null`. * The `page_template` argument was handled, but not documented in the `wp_insert_post()` function. The argument is now documented in the `wp_insert_post()` function DocBlock. Note: There are more than likely several other potential arguments missing from that list, but verifying the whole list is outside the scope of this particular commit. Includes minor simplifications, such as: * Setting a default ahead of an `if`, instead of in an `else` clause (as long as no function call is needed to set the default). * Removing the unnecessary logic duplication in the `$post_status` switch. * Using a combined concatenation + assignment operator for adding `$post_more`. Fixes various errors along the lines of: {{{ 1) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated /var/www/src/wp-includes/formatting.php:2497 /var/www/src/wp-includes/class-wp-hook.php:308 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5616 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 ... 23) Tests_XMLRPC_mw_editPost::test_draft_not_prematurely_published json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:5615 /var/www/tests/phpunit/tests/xmlrpc/mw/editPost.php:315 /var/www/vendor/bin/phpunit:123 }}} Follow-up to [1563], [4793], [7900], [16824], [19848], [40677], [51968]. Props jrf. See #55656. git-svn-id: https://develop.svn.wordpress.org/trunk@54320 602fd350-edb4-49c9-b593-d223f7449a82
jrfnl
pushed a commit
that referenced
this pull request
Sep 27, 2022
…pc_server::_insert_post()`. The `wp_xmlrpc_server::_insert_post()` method creates a new post via `wp_insert_post()` or updates an existing one via `wp_update_post()`, which subsequently calls `wp_insert_post()`. However, the default/fallback values used in the function were not in line with the default/fallback values used in the `wp_insert_post()` function. The `wp_insert_post()` function does a `wp_parse_args()` (array merge) of the received arguments with the defaults. If any of the received arguments are `null`, this would overwrite the default value, as seen in [https://3v4l.org/bfVlv array_merge() example], and lead to "passing null to non-nullable" deprecation notices on PHP 8.1 for certain arguments. Unfortunately, the conditional logic within the `wp_xmlrpc_server::_insert_post()` function itself often uses an `isset()` to trigger certain code blocks, so syncing the defaults with those used in the `wp_insert_post()` function was not an option. This commit: * Updates the default/fallback values in the `$defaults` array only for those values where this would not lead to a change in the behavior of the function. * Adds a safeguard function, filtering out all remaining `null` values from the `$post_data` array before it is passed on to the `wp_insert_post()` or `wp_update_post()` functions. Removing those values is safe as this means that these array keys will now: * either be set to the default/fallback value as defined in `wp_insert_post()`. * or not be set and for those values which don't have a default/fallback value in `wp_insert_post()`, the function does an `! empty()` or `isset()` check anyway and those array keys not being defined means that the result of those checks will remain the same. Includes * Removing a couple of conditions which are now redundant. * Removing an `expectDeprecation()` in the `Tests_Date_XMLRPC` test class, which is now no longer needed. Fixes various errors along the lines of: {{{ 36) Tests_XMLRPC_wp_newPost::test_no_content json_decode(): Passing null to parameter #1 ($json) of type string is deprecated /var/www/src/wp-includes/kses.php:2074 /var/www/src/wp-includes/class-wp-hook.php:307 /var/www/src/wp-includes/plugin.php:205 /var/www/src/wp-includes/post.php:2835 /var/www/src/wp-includes/post.php:2720 /var/www/src/wp-includes/post.php:4066 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1683 /var/www/src/wp-includes/class-wp-xmlrpc-server.php:1347 /var/www/tests/phpunit/tests/xmlrpc/wp/newPost.php:25 /var/www/vendor/bin/phpunit:123 }}} Follow-up to [1563], [4793], [7900], [16824], [19848], [19873], [20632], [40677], [51968], [54320]. Props jrf. See #55656. git-svn-id: https://develop.svn.wordpress.org/trunk@54321 602fd350-edb4-49c9-b593-d223f7449a82
jrfnl
added a commit
that referenced
this pull request
Sep 27, 2022
The `$path` parameter has a default value of `null`, but would be passed onto the `untrailingslashit()` function without any input validation, even though the `untrailingslashit()` function explicitly only expects/supports a string input. Note: I'm explicitly not changing the `untrailingslashit()` function, but fixing this at the point where the invalid input is incorrectly (not) validated. Includes adding a dedicated unit test for this issue. This fix also allows to remove a couple of calls to `expectDeprecation()` in unrelated tests. Fixes: ``` 4) Tests_Dependencies_Scripts::test_wp_external_wp_i18n_print_order rtrim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/formatting.php:2782 /var/www/src/wp-includes/l10n.php:1068 /var/www/src/wp-includes/class.wp-scripts.php:605 /var/www/src/wp-includes/class.wp-scripts.php:320 /var/www/src/wp-includes/class.wp-dependencies.php:136 /var/www/src/wp-includes/functions.wp-scripts.php:109 /var/www/tests/phpunit/tests/dependencies/scripts.php:1505 /var/www/tests/phpunit/includes/utils.php:436 /var/www/tests/phpunit/tests/dependencies/scripts.php:1507 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 28, 2022
The `$path` parameter has a default value of `null`, but would be passed onto the `untrailingslashit()` function without any input validation, even though the `untrailingslashit()` function explicitly only expects/supports a string input. Note: I'm explicitly not changing the `untrailingslashit()` function, but fixing this at the point where the invalid input is incorrectly (not) validated. Includes adding a dedicated unit test for this issue. This fix also allows to remove a couple of calls to `expectDeprecation()` in unrelated tests. Fixes: ``` 4) Tests_Dependencies_Scripts::test_wp_external_wp_i18n_print_order rtrim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/formatting.php:2782 /var/www/src/wp-includes/l10n.php:1068 /var/www/src/wp-includes/class.wp-scripts.php:605 /var/www/src/wp-includes/class.wp-scripts.php:320 /var/www/src/wp-includes/class.wp-dependencies.php:136 /var/www/src/wp-includes/functions.wp-scripts.php:109 /var/www/tests/phpunit/tests/dependencies/scripts.php:1505 /var/www/tests/phpunit/includes/utils.php:436 /var/www/tests/phpunit/tests/dependencies/scripts.php:1507 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 28, 2022
The `$path` parameter has a default value of `null`, but would be passed onto the `untrailingslashit()` function without any input validation, even though the `untrailingslashit()` function explicitly only expects/supports a string input. > 👉 An alternative - and possibly better - solution would be to change the default value of the `$path` parameter to an empty string. > However, such a change would have a wider impact as all function calls which currently pass the `null` default value for `$path` would need to be updated as well. Within WP, this is largely an issue in the tests, but it _could_ potentially have an impact on external calls to the function as well. Note: I'm explicitly not changing the `untrailingslashit()` function, but fixing this at the point where the invalid input is incorrectly (not) validated. Includes adding a dedicated unit test for this issue. This fix also allows to remove a couple of calls to `expectDeprecation()` in unrelated tests. Fixes: ``` 4) Tests_Dependencies_Scripts::test_wp_external_wp_i18n_print_order rtrim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/formatting.php:2782 /var/www/src/wp-includes/l10n.php:1068 /var/www/src/wp-includes/class.wp-scripts.php:605 /var/www/src/wp-includes/class.wp-scripts.php:320 /var/www/src/wp-includes/class.wp-dependencies.php:136 /var/www/src/wp-includes/functions.wp-scripts.php:109 /var/www/tests/phpunit/tests/dependencies/scripts.php:1505 /var/www/tests/phpunit/includes/utils.php:436 /var/www/tests/phpunit/tests/dependencies/scripts.php:1507 /var/www/vendor/bin/phpunit:123 ```
jrfnl
added a commit
that referenced
this pull request
Sep 28, 2022
The `$path` parameter has a default value of `null`, but would be passed onto the `untrailingslashit()` function without any input validation, even though the `untrailingslashit()` function explicitly only expects/supports a string input. > 👉 An alternative - and possibly better - solution would be to change the default value of the `$path` parameter to an empty string. > However, such a change would have a wider impact as all function calls which currently pass the `null` default value for `$path` would need to be updated as well. Within WP, this is largely an issue in the tests, but it _could_ potentially have an impact on external calls to the function as well. Note: I'm explicitly not changing the `untrailingslashit()` function, but fixing this at the point where the invalid input is incorrectly (not) validated. Includes adding a dedicated unit test for this issue. This fix also allows to remove a couple of calls to `expectDeprecation()` in unrelated tests. Fixes: ``` 4) Tests_Dependencies_Scripts::test_wp_external_wp_i18n_print_order rtrim(): Passing null to parameter #1 ($string) of type string is deprecated /var/www/src/wp-includes/formatting.php:2782 /var/www/src/wp-includes/l10n.php:1068 /var/www/src/wp-includes/class.wp-scripts.php:605 /var/www/src/wp-includes/class.wp-scripts.php:320 /var/www/src/wp-includes/class.wp-dependencies.php:136 /var/www/src/wp-includes/functions.wp-scripts.php:109 /var/www/tests/phpunit/tests/dependencies/scripts.php:1505 /var/www/tests/phpunit/includes/utils.php:436 /var/www/tests/phpunit/tests/dependencies/scripts.php:1507 /var/www/vendor/bin/phpunit:123 ```
jrfnl
pushed a commit
that referenced
this pull request
Sep 29, 2022
…ions path.
The `$path` parameter of `load_script_textdomain()` had a default value of `null`, but would be passed onto the `untrailingslashit()` function without any input validation, even though the latter explicitly only expects/supports a string input.
This commit changes the default value for `$path` to an empty string, and adds an `is_string()` check before passing the value to `untrailingslashit()` to fix the issue at the point where the invalid input is incorrectly (not) validated.
Note: Changing the `untrailingslashit()` function is outside the scope of this commit.
Includes:
* Adding a dedicated unit test for this issue.
* Correcting the default value for `$path` from `null` to an empty string in a few related methods and functions:
* `WP_Dependency::set_translations()`
* `WP_Scripts::set_translations()`
* `wp_set_script_translations()`
* `load_script_textdomain()`
This fix also allows to remove a couple of calls to `expectDeprecation()` in unrelated tests.
Fixes an error when running the test suite:
{{{
4) Tests_Dependencies_Scripts::test_wp_external_wp_i18n_print_order
rtrim(): Passing null to parameter #1 ($string) of type string is deprecated
/var/www/src/wp-includes/formatting.php:2782
/var/www/src/wp-includes/l10n.php:1068
/var/www/src/wp-includes/class.wp-scripts.php:605
/var/www/src/wp-includes/class.wp-scripts.php:320
/var/www/src/wp-includes/class.wp-dependencies.php:136
/var/www/src/wp-includes/functions.wp-scripts.php:109
/var/www/tests/phpunit/tests/dependencies/scripts.php:1505
/var/www/tests/phpunit/includes/utils.php:436
/var/www/tests/phpunit/tests/dependencies/scripts.php:1507
/var/www/vendor/bin/phpunit:123
}}}
Follow-up to [44169], [44607], [51968].
Props jrf, ocean90, Chouby, swissspidy, lovor, iviweb, meysamnorouzi, DarkoG, oneearth27, SergeyBiryukov.
Fixes #55967. See #55656.
git-svn-id: https://develop.svn.wordpress.org/trunk@54349 602fd350-edb4-49c9-b593-d223f7449a82
jrfnl
pushed a commit
that referenced
this pull request
Sep 30, 2022
…_JSON::get_property_value()`.
This commit aims to fix errors caused by incorrect usage of the `strncmp()` function inside the `WP_Theme_JSON::get_property_value()` method on PHP 8.1 and above.
Some history of the affected code:
* [50973] introduced the `WP_Theme_JSON::get_property_value()` method.
* [54162] removed the `$default` parameter from the `_wp_array_get()` call in the method.
With the latter change, the default value that is returned if the path does not exist within the array, or if `$array` or `$path` are not arrays, became `null` instead of an empty string. Since `null` would then be unintentionally passed to the `strncmp()` function further in the code, this caused ~35 errors in the test suite along the lines of:
{{{
1) Tests_Blocks_Editor::test_get_block_editor_settings_theme_json_settings
strncmp(): Passing null to parameter #1 ($string1) of type string is deprecated
/var/www/src/wp-includes/class-wp-theme-json.php:1754
/var/www/src/wp-includes/class-wp-theme-json.php:1641
/var/www/src/wp-includes/class-wp-theme-json.php:2066
/var/www/src/wp-includes/class-wp-theme-json.php:1002
/var/www/src/wp-includes/class-wp-theme-json.php:898
/var/www/src/wp-includes/global-styles-and-settings.php:140
/var/www/src/wp-includes/block-editor.php:421
/var/www/tests/phpunit/tests/blocks/editor.php:388
/var/www/vendor/bin/phpunit:123
}}}
This commit includes:
* Restoring the `$default` value for `_wp_array_get()` call.
* Adding an early return if the value is an empty string or `null`.
* Adding a dedicated unit test to ensure that the method returns a string for invalid paths or `null` values.
Follow-up to [50973], [54162].
Props antonvlasenko, jrf, imadarshakshat, SergeyBiryukov.
Fixes #56620.
git-svn-id: https://develop.svn.wordpress.org/trunk@54362 602fd350-edb4-49c9-b593-d223f7449a82
jrfnl
pushed a commit
that referenced
this pull request
Oct 23, 2022
…L10n`.
These three tests for `wp_dashboard_recent_drafts()` would run into a PHP 8.1 "passing null to non-nullable" deprecation for the call to `ltrim()` when the result of `get_edit_post_link()` is passed to `esc_url()`.
Setting a deprecation expectation would not solve this as the returned value would still not match the expected value(s).
The recent drafts list is only displayed on the Dashboard screen for users with the `edit_posts` capability. By setting the current user to Editor, the prerequisites for `wp_dashboard_recent_drafts()` are met, which means the deprecation notice is avoided and the assertions will succeed.
This commit addresses a few errors in the test suite along the lines of:
{{{
1) Tests_L10n::test_length_of_draft_should_be_counted_by_words
ltrim(): Passing null to parameter #1 ($string) of type string is deprecated
/var/www/src/wp-includes/formatting.php:4376
/var/www/src/wp-admin/includes/dashboard.php:657
/var/www/tests/phpunit/tests/l10n.php:449
/var/www/vendor/bin/phpunit:123
}}}
Follow-up to [45505], [52253], [52259].
Props jrf, desrosj, SergeyBiryukov.
See #56681, #55652, #55656.
git-svn-id: https://develop.svn.wordpress.org/trunk@54365 602fd350-edb4-49c9-b593-d223f7449a82
jrfnl
pushed a commit
that referenced
this pull request
Jul 2, 2023
The `$credentials['user_login']` and `$credentials['user_password']` parameters are passed by reference to the `wp_authenticate` action, and are at that point [https://www.php.net/manual/en/language.references.pass.php#124383 created as null] if they don't exist in the array. This commit sets those values to an empty string, resolving two PHP 8.1 deprecation notices: * One from `preg_replace()` in `wp_strip_all_tags()` via `sanitize_user()` in `wp_authenticate()`: {{{ Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated }}} * One from `trim()` in `wp_authenticate()` itself: {{{ Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated }}} Includes documenting the `$credentials` parameter using hash notation. Follow-up to [6643], [37697]. Props lenasterg, TobiasBg, ocean90, afragen, lkraav, SergeyBiryukov. Fixes #56850. git-svn-id: https://develop.svn.wordpress.org/trunk@55301 602fd350-edb4-49c9-b593-d223f7449a82
jrfnl
pushed a commit
that referenced
this pull request
Jul 2, 2023
…air screen.
The table is no longer created by core as of WordPress 3.0, and support for global terms was removed in WordPress 6.1, so `$wpdb->sitecategories` is unset by default.
This commit resolves a "passing null to non-nullable" deprecation notice on PHP 8.1:
{{{
Deprecated: addcslashes(): Passing null to parameter #1 ($string) of type string is deprecated in wp-includes/class-wpdb.php on line 1804
}}}
The `tables_to_repair` filter is available for plugins to readd the table or include any additional tables to repair.
Follow-up to [14854], [14880], [54240].
Props ipajen, chiragrathod103, SergeyBiryukov.
Fixes #57762.
git-svn-id: https://develop.svn.wordpress.org/trunk@55421 602fd350-edb4-49c9-b593-d223f7449a82
jrfnl
pushed a commit
that referenced
this pull request
Oct 5, 2023
…om next_posts(). The `esc_url()` function expects to a string for `$url` parameter. There is no input validation within that function. The function contains a `ltrim()` which also expects a string. Passing `null` to this parameter results in `Deprecated: ltrim(): Passing null to parameter #1 ($string) of type string is deprecated` notice on PHP 8.1+. Tracing the stack back, a `null` is being passed to it within `next_posts()` when `get_next_posts_page_link()` returns `null` (it can return a string or `null`). On PHP 7.0 to PHP 8.x, an empty string is returned from `esc_url()` when `null` is passed to it. The change in this changeset avoids the deprecation notice by not invoking `esc_url()` when `get_next_posts_page_link()` returns `null` and instead sets the `$output` to an empty string, thus maintain the same behavior as before (minus the deprecation notice). Adds a test to validate an empty string is returned and the absence of the deprecation (when running on PHP 8.1+). Follow-up to [11383], [9632]. Props codersantosh, nihar007, hellofromTonya, mukesh27, oglekler, rajinsharwar. Fixes #59154. git-svn-id: https://develop.svn.wordpress.org/trunk@56740 602fd350-edb4-49c9-b593-d223f7449a82
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
/cc @dlh01