Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update class class-pclzip.php #1

Closed
wants to merge 1 commit into from

Conversation

mybesttools
Copy link

@mybesttools mybesttools commented Mar 29, 2017

Installing a plugin results in a warning because a 0 filesize is passed to fread()
Changed to read the filesize before passing to fread()
Tested on :
System Linux ubuntu 4.4.0-66-generic #87-Ubuntu SMP Fri Mar 3 15:29:05 UTC 2017 x86_64
PHP Version 7.0.15-0ubuntu0.16.04.4
MySQL Version 5.7.17-0ubuntu0.16.04.1

Installing a plugin results in a warning because a 0 filesize is passed to fread()
Changed to read the filesize before passing to fread()
@ntwb
Copy link
Member

ntwb commented May 11, 2017

@mikesmth thanks for the pull request though this repo here is a mirror only, patches should be submitted to our bug tracker at https://core.trac.wordpress.org/ instead please

@westonruter westonruter closed this Aug 2, 2017
@mybesttools mybesttools deleted the patch-1 branch February 2, 2018 11:07
dd32 referenced this pull request in dd32/wordpress-develop Mar 8, 2019
…opment and will be replaced at a later date.
dd32 referenced this pull request in dd32/wordpress-develop Mar 8, 2019
…opment and will be replaced at a later date.
dd32 referenced this pull request in dd32/wordpress-develop Mar 12, 2019
…opment and will be replaced at a later date.
dd32 referenced this pull request in dd32/wordpress-develop Mar 19, 2019
…opment and will be replaced at a later date.
dd32 referenced this pull request in dd32/wordpress-develop Mar 19, 2019
Ayesh pushed a commit to Ayesh/wordpress-develop that referenced this pull request Apr 17, 2020
Ayesh added a commit to Ayesh/wordpress-develop that referenced this pull request May 1, 2020
desrosj referenced this pull request in desrosj/wordpress-develop Jul 2, 2020
jrfnl referenced this pull request in jrfnl/wordpress-develop Aug 11, 2020
This fixes the following unit test failures:
```
1) Tests_Admin_includesListTable::test_filter_button_should_be_shown_if_there_are_comments

get_comment(): Argument #1 ($comment) must be passed by reference, value given

2) Tests_Admin_includesListTable::test_filter_comment_status_dropdown_should_be_shown_if_there_are_comments

get_comment(): Argument #1 ($comment) must be passed by reference, value given

14) WP_Test_Block_Render::test_render_latest_comments_on_password_protected_post

get_comment(): Argument #1 ($comment) must be passed by reference, value given
```
jrfnl referenced this pull request in jrfnl/wordpress-develop Oct 17, 2020
WordPress should not throw any notices.

`array_map()` passes by value, while `array_walk()` passes by reference.

The use of `array_map()` on line 52 within the `export_entries()` method will cause a "Warning: PO::export_entry(): Argument #1 ($entry) must be passed by reference, value given" warning on PHP 8.0 because the `export_entry()` method is declared to expect the `$entry` object to be passed by reference.

Since PHP 5.0, objects are passed by reference by default and this does not have to be declared in the function signature of a method expecting this anymore.

Also, the code within the method doesn't even try to change `$entry` and return a value.

So, all in all, the reference in the function declaration is redundant, old-school and should be removed.

While this could be considered a BC-break, I have done a search for use of this method in plugins and reviewed a significant number of the returned results. None of these would run into trouble with the change now made. Rather this change fixes the same issue for a number of plugins also using `array_map()`.

All the same, this change should be mentioned in a dev-note as it is a very small and insignificant BC-break.

Search results: https://wpdirectory.net/search/01EMWBEKAM2B6ECSTCTEDAZGQW
kebbet referenced this pull request in kebbet/wordpress-develop Jan 25, 2021
pento pushed a commit that referenced this pull request Aug 3, 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
pento pushed a commit that referenced this pull request Aug 12, 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
pento pushed a commit that referenced this pull request Aug 16, 2021
…rse_request()`.

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.

git-svn-id: https://develop.svn.wordpress.org/trunk@51622 602fd350-edb4-49c9-b593-d223f7449a82
pento pushed a commit that referenced this pull request Aug 16, 2021
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.

git-svn-id: https://develop.svn.wordpress.org/trunk@51624 602fd350-edb4-49c9-b593-d223f7449a82
pento pushed a commit that referenced this pull request Aug 17, 2021
…ad_url()`.

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.

git-svn-id: https://develop.svn.wordpress.org/trunk@51626 602fd350-edb4-49c9-b593-d223f7449a82
pento pushed a commit that referenced this pull request Aug 17, 2021
…Theme Editor screens.

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.

git-svn-id: https://develop.svn.wordpress.org/trunk@51629 602fd350-edb4-49c9-b593-d223f7449a82
pento pushed a commit that referenced this pull request Aug 17, 2021
…kie_constants()`.

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.

git-svn-id: https://develop.svn.wordpress.org/trunk@51630 602fd350-edb4-49c9-b593-d223f7449a82
pento pushed a commit that referenced this pull request Sep 9, 2021
…cy_anonymize_ip()`.

The `wp_privacy_anonymize_ip()` function expects a string for the `$ip_addr` parameter, but did not do any input validation.

One of the pre-existing test cases, passed `null` to the function, leading to a `substr_count(): Passing null to parameter #1 ($haystack) of type string is deprecated` notice on PHP 8.1.

Fixed now by doing a cursory check on the variable at the start of the function and bowing out early for a number of cases (`null`, `false`, `0`, `''`) which would all result in the same `0.0.0.0` output anyway.

Follow-up [42971].

Props jrf, hellofromTonya.
See #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51793 602fd350-edb4-49c9-b593-d223f7449a82
pento pushed a commit that referenced this pull request Sep 10, 2021
…sts()`.

The `term_exists()` function expects a string or an integer for the `$term` parameter. It validates for integer, but not for string or `null`.

One of the pre-existing test cases, passed `null` to the function, leading to a `trim(): Passing null to parameter #1 ($string) of type string is deprecated` notice on PHP 8.1.

Fixed now by doing a cursory check on the variable at the start of the function and bowing out early in case the `$term` is `null`.

The issue was discovered via and is already covered by the `Tests_TermExists::test_term_exists_unknown()` test method.

Follow-up to [15220]. [38716].

Props jrf, hellofromTonya.
See #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51796 602fd350-edb4-49c9-b593-d223f7449a82
pento pushed a commit that referenced this pull request Sep 26, 2022
…Users_Controller::update_item()`.

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
}}}

Follow-up to [44641], [38832].

Props jrf.
See #55656.

git-svn-id: https://develop.svn.wordpress.org/trunk@54317 602fd350-edb4-49c9-b593-d223f7449a82
markjaquith pushed a commit to markjaquith/WordPress that referenced this pull request Sep 26, 2022
…Users_Controller::update_item()`.

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 WordPress/wordpress-develop#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
}}}

Follow-up to [44641], [38832].

Props jrf.
See #55656.
Built from https://develop.svn.wordpress.org/trunk@54317


git-svn-id: http://core.svn.wordpress.org/trunk@53876 1a063a9b-81f0-0310-95a4-ce76da25c4cd
github-actions bot pushed a commit to platformsh/wordpress-performance that referenced this pull request Sep 26, 2022
…Users_Controller::update_item()`.

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 WordPress/wordpress-develop#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
}}}

Follow-up to [44641], [38832].

Props jrf.
See #55656.
Built from https://develop.svn.wordpress.org/trunk@54317


git-svn-id: https://core.svn.wordpress.org/trunk@53876 1a063a9b-81f0-0310-95a4-ce76da25c4cd
pento 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
pento 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
creedally-dev added a commit to creedally-dev/wordpress-develop that referenced this pull request Sep 28, 2022
…ted in wp-includes\formatting.php on line 2789
creedally-dev added a commit to creedally-dev/wordpress-develop that referenced this pull request Sep 28, 2022
…ted in wp-includes\formatting.php on line 2789
pento pushed a commit that referenced this pull request Sep 28, 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
pento 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
pento pushed a commit that referenced this pull request Oct 1, 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
lenasterg added a commit to lenasterg/wordpress-develop that referenced this pull request Oct 19, 2022
Fix for PHP Deprecated:  trim(): Passing null to parameter WordPress#1 ($string) of type string is deprecated in \wp-includes\pluggable.php on line 598
lenasterg added a commit to lenasterg/wordpress-develop that referenced this pull request Oct 19, 2022
Fix for PHP Deprecated:  trim(): Passing null to parameter WordPress#1 ($string) of type string is deprecated in app\wp-includes\pluggable.php on line 598
ootwch pushed a commit to ootwch/wordpress-develop that referenced this pull request Nov 4, 2022
…Users_Controller::update_item()`.

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 WordPress#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
}}}

Follow-up to [44641], [38832].

Props jrf.
See #55656.

git-svn-id: https://develop.svn.wordpress.org/trunk@54317 602fd350-edb4-49c9-b593-d223f7449a82
yusuke-omae referenced this pull request in yusuke-omae/wordpress-develop Nov 17, 2022
pento pushed a commit that referenced this pull request Feb 9, 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
pento pushed a commit that referenced this pull request Feb 24, 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
jeherve added a commit to jeherve/wordpress-develop that referenced this pull request Apr 6, 2023
This avoids the following warning on pages where a title is not defined:

```
PHP Deprecated:  strip_tags(): Passing null to parameter WordPress#1 ($string) of type string is deprecated in /wp-admin/admin-header.php on line 36
```

This should not normally happen, but some folks may pass null to `add_submenu_page()` when creating new pages, to hide that page from the admin menu. This may not be the best approach, but it is one that is documented in the codex and used in the wild:
https://developer.wordpress.org/reference/functions/add_submenu_page/#comment-445

- Related Core trac ticket: https://core.trac.wordpress.org/ticket/57579
- Related PR: WordPress#4084
misfist referenced this pull request in misfist/wordpress-develop Aug 24, 2023
Fix incompatible declarations PHP War
nings - patch.diff​ (1.9 KB) - added by davidbawiec 3 years ago.
patching file wp-includes/class-wp-image-editor-gd.php
Hunk #1 FAILED at 154.
Hunk #2 FAILED at 218.
2 out of 2 hunks FAILED
patching file wp-includes/class-wp-image-editor-imagick.php
Hunk #1 FAILED at 251.
Hunk #2 succeeded at 364 (offset 75 lines).
1 out of 2 hunks FAILED
misfist referenced this pull request in misfist/wordpress-develop Aug 24, 2023
40370.diff​ (4.7 KB) - added by thema
ttroyal 5 years ago.
patching file src/wp-includes/class-wp-image-editor-gd.php
Hunk #1 succeeded at 153 with fuzz 1 (offset 17 lines).
Hunk #2 FAILED at 225.
Hunk #3 FAILED at 256.
Hunk WordPress#4 succeeded at 557 with fuzz 2 (offset 105 lines).
2 out of 4 hunks FAILED
patching file src/wp-includes/class-wp-image-editor-imagick.php
Hunk #1 succeeded at 309 with fuzz 1 (offset 72 lines).
Hunk #2 succeeded at 364 (offset 80 lines).
Hunk #3 succeeded at 859 with fuzz 2 (offset 191 lines).
patching file src/wp-includes/class-wp-image-editor.php
Hunk #1 succeeded at 15 with fuzz 2 (offset 1 line).
Hunk #2 succeeded at 222 (offset 26 lines).
Hunk #3 succeeded at 512 (offset 108 lines).
Krinkle added a commit to Krinkle/wordpress-develop that referenced this pull request Sep 16, 2023
…ntains()`

This prevents URLs like `/wp-login.php?redirect_to[x]=y` from
triggering a HTTP 500 response as result of

> PHP Fatal error: Uncaught TypeError: str_contains():
> Argument WordPress#1 ($haystack) must be of type string, array given

See https://core.trac.wordpress.org/ticket/59373

I considered changing the case for "authorize-application.php" to
re-use the `$requested_redirect_to` variable but left it as-is because
this case reads from _GET whereas the variable also considers POST
parameters (via _REQUEST), which might be intentional. This case
was introduced in [49109] for #42790.

* change 49109: WordPress@1856d0f
* issue 42790: https://core.trac.wordpress.org/ticket/42790
pento pushed a commit that referenced this pull request Sep 28, 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
pento pushed a commit that referenced this pull request Aug 4, 2024
…Info screen.

This resolves a fatal error if `strict_types` PHP setting is enabled:
{{{
Argument #1 ($num) must be of type float, string given
}}}

Since the goal of the Site Health Info screen is to display raw values where possible, the `number_format()` call here does not seem to provide any benefit.

Props krishneup, sabernhardt, audrasjb, SergeyBiryukov.
Fixes #60364.

git-svn-id: https://develop.svn.wordpress.org/trunk@58847 602fd350-edb4-49c9-b593-d223f7449a82
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants