#41488: Fix handling of backslashes encoded in in partial placement context data by westonruter · Pull Request #2 · WordPress/wordpress-develop

westonruter · 2017-08-02T04:06:17Z

https://core.trac.wordpress.org/ticket/41488

(This pull request will not be merged. The patch from the patch is being committed and pushed to GitHub for the sake of the pull request, both for review and for the Travis build.)

…emails-1 50448-auto-update-failure-emails

No input validation was done. Covered by existing `Tests_Functions::test_validate_file()` test (well, the `null` and string part is). Error fixed: `preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated` QUESTION: should we add tests for other scalar input types ?

This fixes a `preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated` notice on PHP 8.1. The behavior for `null` and `string` input is covered by the existing `Tests_Functions::test_validate_file()` test. Effect: Errors down by 238, assertions up by 1920, failures down by 1. Props jrf, hellofromTonya, SergeyBiryukov. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51625 602fd350-edb4-49c9-b593-d223f7449a82

…` in `WP_Sitemaps_Provider::get_sitemap_url()`. The `WP_Sitemaps_Provider::get_sitemap_url()` method calls the PHP native `http_build_query()` function, the second parameter of which is the ''optional'' `$numeric_prefix` parameter which expects a `string`. A parameter being optional, however, does not automatically make it nullable. As of PHP 8.1, passing `null` to a non-nullable PHP native function will generate a deprecation notice. In this case, this function call yielded a `http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated` notice. Changing the `null` to an empty string fixes this without a backward compatibility break. This change is already covered by tests as 14 of the existing tests failed on these function calls when running the tests on PHP 8.1. References: * [https://www.php.net/manual/en/function.http-build-query.php PHP Manual: http_build_query()] * [https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg PHP RFC: Deprecate passing null to non-nullable arguments of internal functions] Follow-up to [48470]. Props jrf. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51652 602fd350-edb4-49c9-b593-d223f7449a82

…precation notices The PHP native `mysqli_real_escape_string()` function expects to be passed a string as the second parameter and this is not a nullable parameter. Passing `null` to it will result in a `mysqli_real_escape_string(): Passing null to parameter #2 ($string) of type string is deprecated` notice on PHP 8.1. Previously, an input type check was put in place to prevent fatal errors on PHP 8.0 when an array, object or resource was passed. Changeset [48980]. A `null` value was explicitly excluded from that check, even though a `null` value being passed would only ever result in an empty string anyway. This commit changes the previous input type check to also bow out early for `null` values and to automatically return an empty string for those. Refs: * https://www.php.net/manual/en/mysqli.real-escape-string.php * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg

…cation On PHP 8.1, the `_mb_substr()` function would throw a `preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated` notice when passed `null`. To maintain the same behaviour as before, let's just bow out early when `$str` is passed as `null` as the outcome will, in that case, only ever be an empty string. Note: this does mean that the `_mb_substr()` function now has a subtle difference in behaviour compared to the PHP native `mb_substr()` function as the latter *will* throw the deprecation notice. The existing tests for the compat function already cover this issue.

…precation notices The PHP native `mysqli_real_escape_string()` function expects to be passed a string as the second parameter and this is not a nullable parameter. Passing `null` to it will result in a `mysqli_real_escape_string(): Passing null to parameter #2 ($string) of type string is deprecated` notice on PHP 8.1. Previously, an input type check was put in place to prevent fatal errors on PHP 8.0 when an array, object or resource was passed. Changeset [48980]. A `null` value was explicitly excluded from that check, even though a `null` value being passed would only ever result in an empty string anyway. This commit changes the previous input type check to also bow out early for `null` values and to automatically return an empty string for those. Refs: * https://www.php.net/manual/en/mysqli.real-escape-string.php * https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg

… `wpdb::_real_escape()`. The PHP native `mysqli_real_escape_string()` function expects to be passed a string as the second parameter and this is not a nullable parameter. Passing `null` to it will result in a `mysqli_real_escape_string(): Passing null to parameter #2 ($string) of type string is deprecated` notice on PHP 8.1. Previously, an input type check was put in place to prevent fatal errors on PHP 8.0 when an array, object or resource was passed. Changeset [48980]. A `null` value was explicitly excluded from that check, even though a `null` value being passed would only ever result in an empty string anyway. This commit changes the previous input type check to also bow out early for `null` values and to automatically return an empty string for those. Refs: - https://www.php.net/manual/en/mysqli.real-escape-string.php - https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg Follow-up to [48980]. Props jrf, hellofromTonya. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51799 602fd350-edb4-49c9-b593-d223f7449a82

…IncludesPlugin::test_get_plugin_files_folder()`. The `Tests_Admin_IncludesPlugin::_create_plugin()` expects the first parameter to be a text string to be written to a plugin file using `fwrite()`. Passing null causes a `fwrite(): Passing null to parameter #2 ($data) of type string is deprecated` notice. Ref: https://www.php.net/manual/en/function.fwrite Follow-up to [31002]. [41806]. Props jrf, hellofromTonya. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51800 602fd350-edb4-49c9-b593-d223f7449a82

… `_mb_substr()`. The `_mb_substr()` function expects a string for the `$str` parameter, but does not do input validation. This function contains a `preg_match_all()` which also expects a string type for the given subject (i.e. `$str`). Passing `null` to this parameter results in `preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated` notice on PHP 8.1. To maintain the same behaviour as before, a guard clause is added to bail out early when `$str` is passed as `null`. The outcome will, in that case, only ever be an empty string. Note: this does mean that the `_mb_substr()` function now has a subtle difference in behaviour compared to the PHP native `mb_substr()` function as the latter ''will'' throw the deprecation notice. The existing tests already cover this issue. Follow-up to [17621], [36017], [32364]. Props jrf, hellofromTonya. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51853 602fd350-edb4-49c9-b593-d223f7449a82

… `wpdb::_real_escape()`. The PHP native `mysqli_real_escape_string()` function expects to be passed a string as the second parameter and this is not a nullable parameter. Passing `null` to it will result in a `mysqli_real_escape_string(): Passing null to parameter WordPress#2 ($string) of type string is deprecated` notice on PHP 8.1. Previously, an input type check was put in place to prevent fatal errors on PHP 8.0 when an array, object or resource was passed. Changeset [48980]. A `null` value was explicitly excluded from that check, even though a `null` value being passed would only ever result in an empty string anyway. This commit changes the previous input type check to also bow out early for `null` values and to automatically return an empty string for those. Refs: - https://www.php.net/manual/en/mysqli.real-escape-string.php - https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg Follow-up to [48980]. Props jrf, hellofromTonya. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51799 602fd350-edb4-49c9-b593-d223f7449a82

…IncludesPlugin::test_get_plugin_files_folder()`. The `Tests_Admin_IncludesPlugin::_create_plugin()` expects the first parameter to be a text string to be written to a plugin file using `fwrite()`. Passing null causes a `fwrite(): Passing null to parameter WordPress#2 ($data) of type string is deprecated` notice. Ref: https://www.php.net/manual/en/function.fwrite Follow-up to [31002]. [41806]. Props jrf, hellofromTonya. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51800 602fd350-edb4-49c9-b593-d223f7449a82

… `_mb_substr()`. The `_mb_substr()` function expects a string for the `$str` parameter, but does not do input validation. This function contains a `preg_match_all()` which also expects a string type for the given subject (i.e. `$str`). Passing `null` to this parameter results in `preg_match_all(): Passing null to parameter WordPress#2 ($subject) of type string is deprecated` notice on PHP 8.1. To maintain the same behaviour as before, a guard clause is added to bail out early when `$str` is passed as `null`. The outcome will, in that case, only ever be an empty string. Note: this does mean that the `_mb_substr()` function now has a subtle difference in behaviour compared to the PHP native `mb_substr()` function as the latter ''will'' throw the deprecation notice. The existing tests already cover this issue. Follow-up to [17621], [36017], [32364]. Props jrf, hellofromTonya. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51853 602fd350-edb4-49c9-b593-d223f7449a82

… `wpdb::_real_escape()`. The PHP native `mysqli_real_escape_string()` function expects to be passed a string as the second parameter and this is not a nullable parameter. Passing `null` to it will result in a `mysqli_real_escape_string(): Passing null to parameter WordPress#2 ($string) of type string is deprecated` notice on PHP 8.1. Previously, an input type check was put in place to prevent fatal errors on PHP 8.0 when an array, object or resource was passed. Changeset [48980]. A `null` value was explicitly excluded from that check, even though a `null` value being passed would only ever result in an empty string anyway. This commit changes the previous input type check to also bow out early for `null` values and to automatically return an empty string for those. Refs: - https://www.php.net/manual/en/mysqli.real-escape-string.php - https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg Follow-up to [48980]. Props jrf, hellofromTonya. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51799 602fd350-edb4-49c9-b593-d223f7449a82

…IncludesPlugin::test_get_plugin_files_folder()`. The `Tests_Admin_IncludesPlugin::_create_plugin()` expects the first parameter to be a text string to be written to a plugin file using `fwrite()`. Passing null causes a `fwrite(): Passing null to parameter WordPress#2 ($data) of type string is deprecated` notice. Ref: https://www.php.net/manual/en/function.fwrite Follow-up to [31002]. [41806]. Props jrf, hellofromTonya. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51800 602fd350-edb4-49c9-b593-d223f7449a82

… `_mb_substr()`. The `_mb_substr()` function expects a string for the `$str` parameter, but does not do input validation. This function contains a `preg_match_all()` which also expects a string type for the given subject (i.e. `$str`). Passing `null` to this parameter results in `preg_match_all(): Passing null to parameter WordPress#2 ($subject) of type string is deprecated` notice on PHP 8.1. To maintain the same behaviour as before, a guard clause is added to bail out early when `$str` is passed as `null`. The outcome will, in that case, only ever be an empty string. Note: this does mean that the `_mb_substr()` function now has a subtle difference in behaviour compared to the PHP native `mb_substr()` function as the latter ''will'' throw the deprecation notice. The existing tests already cover this issue. Follow-up to [17621], [36017], [32364]. Props jrf, hellofromTonya. See #53635. git-svn-id: https://develop.svn.wordpress.org/trunk@51853 602fd350-edb4-49c9-b593-d223f7449a82

…query()` This fixes the "Deprecated: http_build_query(): Passing null to parameter WordPress#2 ($numeric_prefix) of type string is deprecated" warning on PHP 8.1. PHP has started requiring that built-in method arguments that are not explicitly declared as nullable may no longer be passed null. The correct value for the `$numeric_prefix` parameter to `http_build_query()` is an empty string. Trac ticket: https://core.trac.wordpress.org/ticket/53635

…` in `get_core_checksums()` and `wp_version_check()`. The `get_core_checksums()` and `wp_version_check()` functions call the PHP native `http_build_query()` function, the second parameter of which is the ''optional'' `$numeric_prefix` parameter which expects a non-nullable `string`. A parameter being optional, however, does not automatically make it nullable. As of PHP 8.1, passing `null` to a non-nullable PHP native function will generate a deprecation notice. In this case, this function call yielded a `http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated` notice. Changing the `null` to an empty string fixes this without a backward compatibility break. References: * [https://www.php.net/manual/en/function.http-build-query.php PHP Manual: http_build_query()] * [https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg PHP RFC: Deprecate passing null to non-nullable arguments of internal functions] Follow-up to [18697], [25540]. Props bjorsch, kraftbj, hellofromTonya, jrf. See #54229. git-svn-id: https://develop.svn.wordpress.org/trunk@52019 602fd350-edb4-49c9-b593-d223f7449a82

…pgrade_690()`. This resolves an error on Multisite networks where an individual site doesn't have plugins active: {{{ array_search(): Argument #2 ($haystack) must be of type array, string given }}} Follow-up to [60666], [60721]. Props dd32. See #53323. git-svn-id: https://develop.svn.wordpress.org/trunk@60725 602fd350-edb4-49c9-b593-d223f7449a82

…cross-reference Addresses 2 MINOR documentation-accuracy findings from the QA report: Issue #1 (findings-config-a.json, Finding 10): The description claimed the weak PRNG fallback lived inside wp_generate_password (defined at L2960), but the code at the cited line 3056 is actually inside wp_rand (defined at L3005). Updated the description to name wp_rand as the containing function while preserving wp_generate_password as the security-relevant caller. New description (187 chars, still within 200-char cap): 'Weak PRNG: wp_rand fallback (reached by wp_generate_password) uses md5 uniqid microtime mt_rand seed: ...' Issue #2 (decisions.md, CWE tie-breaking row): The Risks column carried a stale parenthetical pointing to Row 22 for a tie-break of CWE-1275 vs CWE-1004 that does not actually appear in Row 22. Additionally, CWE-1004 (Sensitive Cookie Without HttpOnly Flag) does not apply to the cited setcookie at pluggable.php:1195 because the 7th positional argument 'true' sets HttpOnly. Removed the misleading parenthetical so the row's policy statement stands on its own. Both fixes are documentation-only; the underlying security findings remain defensible at the same file/line/severity/cwe. Single-line minified JSON shape, 28-finding count, 5-field schema, and cross- artifact consistency between decisions.md and findings-config-a.json all preserved. Source tree (src/, tests/, tools/, .github/, configs, docs) byte-identical.

Only the `name` member was type-checked, so a client could still send a struct for `type` or `bits` and get a non-string through: - `bits` reached `fwrite()` by way of `wp_upload_bits()`, which throws `TypeError: fwrite(): Argument WordPress#2 ($data) must be of type string, array given` on PHP 8. - `type` survived `sanitize_mime_type()` — `preg_replace()` returns an array for an array subject — and reached the database as the attachment's post MIME type. Both are the same class of bug as the reported one, just behind an authenticated request that can `upload_files`. Reject them alongside `name`. Values arriving over XML-RPC are unaffected: `IXR_Message` decodes `base64` and `string` values to strings, and an empty `<value/>` omits the member entirely, so the `??` fallbacks still apply. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

trac: https://core.trac.wordpress.org/ticket/65914 When `$button` has a structure like `%a`, a PHP parser error can cause Pods or other similar custom metadata blocks to fail to display, resulting in a serious problem. This often disrupts the normal management and use of WordPress. This patch corrects this issue in a way that has been verified to be effective! It's worth noting that, whether we like it or not, this solution is generated by AI combined with internet data retrieval. This solution is very simple and therefore involves no human creativity; I must admit, it was generated by AI. Hopefully, it can be merged quickly to resolve the issue as much as possible. It aims to fix the following bugs: ``` thrown in /var/www/wordpress/wp-includes/general-template.php on line 533" while reading response header from upstream, client: 10.20.245.1, server: www.qhjack.top, request: "GET /wp-admin/post.php?post=582&action=edit HTTP/1.0", upstream: "fastcgi://unix:///run/php/php8.5-fpm.sock:", host: "www.qhjack.top", referrer: "https://www.qhjack.top/wp-admin/edit.php?post_type=services" 2026/08/30 16:25:15 [error] 289643#289643: *106436 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught ValueError: Unknown format specifier "a" in /var/www/wordpress/wp-includes/general-template.php:533 Stack trace: #0 /var/www/wordpress/wp-includes/general-template.php(533): sprintf() WordPress#1 /var/www/wordpress/wp-includes/general-template.php(400): wp_get_tooltip_helper() WordPress#2 /var/www/wordpress/wp-admin/includes/template.php(1410): wp_get_tooltip() WordPress#3 /var/www/wordpress/wp-admin/includes/post.php(2392): do_meta_boxes() WordPress#4 /var/www/wordpress/wp-admin/edit-form-blocks.php(401): the_block_editor_meta_boxes() WordPress#5 /var/www/wordpress/wp-admin/post.php(199): require('...') WordPress#6 {main} ```

The short-circuit for an empty object ID or taxonomy list reads `fields` straight off the `$args` parameter, but that parameter is documented as `array|string` and the query string form is in use, including in this test class. Passing one fatals on PHP 8: wp_get_object_terms( 0, 'wptests_tax', 'fields=count' ); TypeError: array_key_exists(): Argument WordPress#2 ($array) must be of type array, string given Parsing `$args` up front fixes it. The later parse against the defaults is unaffected: re-parsing an array is just the defaults merge. `isset()` replaces `array_key_exists()` now that the check reads in the positive; a null `fields` fails the comparison either way. Also gives the taxonomy name property a `@var`, matching the sibling property, so the calls that pass it are no longer typed as mixed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

A taxonomy registered with a non-empty 'args' array is queried by a recursive call rather than alongside the others, and for a count that call returns a numeric string. Merging it fatals on PHP 8: register_taxonomy( 'wptests_tax', 'post', array( 'args' => array( 0 ) ) ); wp_get_object_terms( $post_id, array( 'wptests_tax', 'wptests_tax_2' ), array( 'fields' => 'count' ) ); TypeError: array_merge(): Argument WordPress#2 must be of type array, string given This is the same defect as the one already fixed for the terms from the remaining taxonomies a few lines below, so it takes the same cast. The counts collected here are summed into a single numeric string further down. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The short-circuit for an empty object ID or taxonomy list reads `fields` straight off the `$args` parameter, but that parameter is documented as `array|string` and the query string form is in use, including in this test class. Passing one fatals on PHP 8: wp_get_object_terms( 0, 'wptests_tax', 'fields=count' ); TypeError: array_key_exists(): Argument WordPress#2 ($array) must be of type array, string given Parsing `$args` up front fixes it. The later parse against the defaults is unaffected: re-parsing an array is just the defaults merge. `isset()` replaces `array_key_exists()` now that the check reads in the positive; a null `fields` fails the comparison either way. Also gives the taxonomy name property a `@var`, matching the sibling property, so the calls that pass it are no longer typed as mixed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

A taxonomy registered with a non-empty 'args' array is queried by a recursive call rather than alongside the others, and for a count that call returns a numeric string. Merging it fatals on PHP 8: register_taxonomy( 'wptests_tax', 'post', array( 'args' => array( 0 ) ) ); wp_get_object_terms( $post_id, array( 'wptests_tax', 'wptests_tax_2' ), array( 'fields' => 'count' ) ); TypeError: array_merge(): Argument WordPress#2 must be of type array, string given This is the same defect as the one already fixed for the terms from the remaining taxonomies a few lines below, so it takes the same cast. The counts collected here are summed into a single numeric string further down. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

trac: https://core.trac.wordpress.org/ticket/65914 When `$button` has a structure like `%a`, a PHP parser error can cause Pods or other similar custom metadata blocks to fail to display, resulting in a serious problem. This often disrupts the normal management and use of WordPress. This patch corrects this issue in a way that has been verified to be effective! It's worth noting that, whether we like it or not, this solution is generated by AI combined with internet data retrieval. This solution is very simple and therefore involves no human creativity; I must admit, it was generated by AI. Hopefully, it can be merged quickly to resolve the issue as much as possible. It aims to fix the following bugs: ``` thrown in /var/www/wordpress/wp-includes/general-template.php on line 533" while reading response header from upstream, client: 10.20.245.1, server: www.qhjack.top, request: "GET /wp-admin/post.php?post=582&action=edit HTTP/1.0", upstream: "fastcgi://unix:///run/php/php8.5-fpm.sock:", host: "www.qhjack.top", referrer: "https://www.qhjack.top/wp-admin/edit.php?post_type=services" 2026/08/30 16:25:15 [error] 289643#289643: *106436 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught ValueError: Unknown format specifier "a" in /var/www/wordpress/wp-includes/general-template.php:533 Stack trace: #0 /var/www/wordpress/wp-includes/general-template.php(533): sprintf() WordPress#1 /var/www/wordpress/wp-includes/general-template.php(400): wp_get_tooltip_helper() WordPress#2 /var/www/wordpress/wp-admin/includes/template.php(1410): wp_get_tooltip() WordPress#3 /var/www/wordpress/wp-admin/includes/post.php(2392): do_meta_boxes() WordPress#4 /var/www/wordpress/wp-admin/edit-form-blocks.php(401): the_block_editor_meta_boxes() WordPress#5 /var/www/wordpress/wp-admin/post.php(199): require('...') WordPress#6 {main} ```

westonruter added 3 commits August 1, 2017 21:04

Fix handling of backslashes encoded in in partial placement context data

a1a8216

Fix test compat with 5.2

b0577fc

Fix phpunit compat for PHP 5.2

845d2a1

westonruter closed this Aug 2, 2017

pento deleted the trac-41488 branch August 2, 2017 05:11

desrosj referenced this pull request in desrosj/wordpress-develop Jul 2, 2020

Merge pull request #2 from helloarpitgshah/50448-auto-update-failure-…

47fe8b1

…emails-1 50448-auto-update-failure-emails

hellofromtonya mentioned this pull request Nov 24, 2020

51423: wp_privacy_generate_personal_data_export_file fixes type match for array_merge (PHP 8) #758

Closed

anomiex mentioned this pull request Nov 2, 2021

Code Modernization: Avoid passing null to parameter 2 of http_build_query() #1800

Closed

costdev mentioned this pull request Nov 4, 2021

Coding Standards: Add visibility to methods in tests/phpunit/tests/ A-B-C-D files. #1717

Closed

westonruter mentioned this pull request May 12, 2026

Support for testing unmerged upstream changes. #11809

Closed

westonruter mentioned this pull request Jul 6, 2026

Build/Test Tools: Honor @global tags on global statement docblocks in PHPStan analysis #12407

Closed

1 task

masteradhoc mentioned this pull request Jul 8, 2026

Implemented documentation for privacy-tools.js #6690

Open

itzmekhokan mentioned this pull request Jul 11, 2026

Administration: Fix Tags screen UI inconsistencies on add/delete #8761

Open

This was referenced Jul 29, 2026

Build/Test Tools: Statically verify that hook documentation and arguments stay in sync #12022

Closed

XML-RPC: wp.getUsersBlogs, enforce arg string requirements #12462

Open

dugyen mentioned this pull request Aug 20, 2026

Adds support for simple Ability versioning #10593

Open

Navigation Menu

Uh oh!

#41488: Fix handling of backslashes encoded in in partial placement context data - #2

#41488: Fix handling of backslashes encoded in in partial placement context data#2
westonruter wants to merge 3 commits into
masterfrom
trac-41488

westonruter commented Aug 2, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

westonruter commented Aug 2, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant