Build Tools: Don't send Slack notifications for Travis CI pull requests - #3

Okay, so this one takes a little explaining.

Basically, the whole `assertSameIgnoreEOL()` assertion was fundamentally flawed. The assertion contends that it checks that the expected and actual values are of the same type and value, but the reality was very different.

* The function uses `map_deep()` to potentially handle all sorts of inputs.
* `map_deep()` handles arrays and objects with special casing, but will call the callback on everything else without further distinction.
* The callback used passes the expected/actual value on to the `str_replace()` function to remove potential new line differences.
* And the `str_replace()` function will - with a non-array input for the `$subject` - always return a string.
* The output of these calls to `map_deep()` will therefore have "normalized" _all properties_ in objects, _all values_ in arrays and _all non-object, non-array values_ to strings.
* And a call to `assertSame()` will therefore NEVER do a proper type check as the type of all input has already, unintentionally, been "normalized" to string.

Aside from this clear flaw in the design of the assertion, PHP 8.1 now exposes a further issue as a `null` value for an object property, an array value or a plain value, will now yield a ` str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated` notice.

To fix both these issues, the fix in this PR ensures that the call to `str_replace()` will now only be made if the input is a text string.
All other values passed to the callback are left in their original type.

This ensures that a proper value AND type comparison can be done as well as prevents the PHP 8.1 deprecation notices.

Includes adjusting the method documentation for both this method and the `assertEqualsIgnoreEOL()` alias method to document that the `$expected` and `$actual` parameters can be of any type.

Ref:
* https://developer.wordpress.org/reference/functions/map_deep/
* https://www.php.net/manual/en/function.str-replace.php

Okay, so this one takes a little explaining.

Basically, the whole `assertSameIgnoreEOL()` assertion was fundamentally flawed. The assertion contends that it checks that the expected and actual values are of the same type and value, but the reality was very different.

* The function uses `map_deep()` to potentially handle all sorts of inputs.
* `map_deep()` handles arrays and objects with special casing, but will call the callback on everything else without further distinction.
* The callback used passes the expected/actual value on to the `str_replace()` function to remove potential new line differences.
* And the `str_replace()` function will - with a non-array input for the `$subject` - always return a string.
* The output of these calls to `map_deep()` will therefore have "normalized" _all properties_ in objects, _all values_ in arrays and _all non-object, non-array values_ to strings.
* And a call to `assertSame()` will therefore NEVER do a proper type check as the type of all input has already, unintentionally, been "normalized" to string.

Aside from this clear flaw in the design of the assertion, PHP 8.1 now exposes a further issue as a `null` value for an object property, an array value or a plain value, will now yield a ` str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated` notice.

To fix both these issues, the fix in this PR ensures that the call to `str_replace()` will now only be made if the input is a text string.
All other values passed to the callback are left in their original type.

This ensures that a proper value AND type comparison can be done as well as prevents the PHP 8.1 deprecation notices.

Includes adjusting the method documentation for both this method and the `assertEqualsIgnoreEOL()` alias method to document that the `$expected` and `$actual` parameters can be of any type.

Ref:
* https://developer.wordpress.org/reference/functions/map_deep/
* https://www.php.net/manual/en/function.str-replace.php

…itTestCase_Base::assertSameIgnoreEOL()`.

Basically, the whole `assertSameIgnoreEOL()` assertion was fundamentally flawed. The assertion contends that it checks that the expected and actual values are of the same type and value, but the reality was very different.

* The function uses `map_deep()` to potentially handle all sorts of inputs.
* `map_deep()` handles arrays and objects with special casing, but will call the callback on everything else without further distinction.
* The callback used passes the expected/actual value on to the `str_replace()` function to remove potential new line differences.
* And the `str_replace()` function will - with a non-array input for the `$subject` - always return a string.
* The output of these calls to `map_deep()` will therefore have "normalized" _all properties_ in objects, _all values_ in arrays and _all non-object, non-array values_ to strings.
* And a call to `assertSame()` will therefore NEVER do a proper type check as the type of all input has already, unintentionally, been "normalized" to string.

Aside from this clear flaw in the design of the assertion, PHP 8.1 now exposes a further issue as a `null` value for an object property, an array value or a plain value, will now yield a ` str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated` notice.

To fix both these issues, the fix in this PR ensures that the call to `str_replace()` will now only be made if the input is a text string.
All other values passed to the callback are left in their original type.

This ensures that a proper value AND type comparison can be done as well as prevents the PHP 8.1 deprecation notices.

Ref:
* https://developer.wordpress.org/reference/functions/map_deep/
* https://www.php.net/manual/en/function.str-replace.php

This commit:
- Fixes type-casting of non-string values to `string` (the flawed part of this assertion) by invoking `str_replace()` when the value is of string type.
- Fixes the PHP 8.1 `str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated` deprecation notice.
- Micro-optimization: skips `map_deep()` when actual and/or expected are `null` (no need to process).
- Adjusts the method documentation for both this method and the `assertEqualsIgnoreEOL()` alias method to document that the `$expected` and `$actual` parameters can be of any type.

Follow-up to [48937], [51135], [51478].

Props jrf, hellofromTonya.
See #53363, #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51831 602fd350-edb4-49c9-b593-d223f7449a82

…itTestCase_Base::assertSameIgnoreEOL()`.

Basically, the whole `assertSameIgnoreEOL()` assertion was fundamentally flawed. The assertion contends that it checks that the expected and actual values are of the same type and value, but the reality was very different.

* The function uses `map_deep()` to potentially handle all sorts of inputs.
* `map_deep()` handles arrays and objects with special casing, but will call the callback on everything else without further distinction.
* The callback used passes the expected/actual value on to the `str_replace()` function to remove potential new line differences.
* And the `str_replace()` function will - with a non-array input for the `$subject` - always return a string.
* The output of these calls to `map_deep()` will therefore have "normalized" _all properties_ in objects, _all values_ in arrays and _all non-object, non-array values_ to strings.
* And a call to `assertSame()` will therefore NEVER do a proper type check as the type of all input has already, unintentionally, been "normalized" to string.

Aside from this clear flaw in the design of the assertion, PHP 8.1 now exposes a further issue as a `null` value for an object property, an array value or a plain value, will now yield a ` str_replace(): Passing null to parameter WordPress#3 ($subject) of type array|string is deprecated` notice.

To fix both these issues, the fix in this PR ensures that the call to `str_replace()` will now only be made if the input is a text string.
All other values passed to the callback are left in their original type.

This ensures that a proper value AND type comparison can be done as well as prevents the PHP 8.1 deprecation notices.

Ref:
* https://developer.wordpress.org/reference/functions/map_deep/
* https://www.php.net/manual/en/function.str-replace.php

This commit:
- Fixes type-casting of non-string values to `string` (the flawed part of this assertion) by invoking `str_replace()` when the value is of string type.
- Fixes the PHP 8.1 `str_replace(): Passing null to parameter WordPress#3 ($subject) of type array|string is deprecated` deprecation notice.
- Micro-optimization: skips `map_deep()` when actual and/or expected are `null` (no need to process).
- Adjusts the method documentation for both this method and the `assertEqualsIgnoreEOL()` alias method to document that the `$expected` and `$actual` parameters can be of any type.

Follow-up to [48937], [51135], [51478].

Props jrf, hellofromTonya.
See #53363, #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51831 602fd350-edb4-49c9-b593-d223f7449a82

…itTestCase_Base::assertSameIgnoreEOL()`.

Basically, the whole `assertSameIgnoreEOL()` assertion was fundamentally flawed. The assertion contends that it checks that the expected and actual values are of the same type and value, but the reality was very different.

* The function uses `map_deep()` to potentially handle all sorts of inputs.
* `map_deep()` handles arrays and objects with special casing, but will call the callback on everything else without further distinction.
* The callback used passes the expected/actual value on to the `str_replace()` function to remove potential new line differences.
* And the `str_replace()` function will - with a non-array input for the `$subject` - always return a string.
* The output of these calls to `map_deep()` will therefore have "normalized" _all properties_ in objects, _all values_ in arrays and _all non-object, non-array values_ to strings.
* And a call to `assertSame()` will therefore NEVER do a proper type check as the type of all input has already, unintentionally, been "normalized" to string.

Aside from this clear flaw in the design of the assertion, PHP 8.1 now exposes a further issue as a `null` value for an object property, an array value or a plain value, will now yield a ` str_replace(): Passing null to parameter WordPress#3 ($subject) of type array|string is deprecated` notice.

To fix both these issues, the fix in this PR ensures that the call to `str_replace()` will now only be made if the input is a text string.
All other values passed to the callback are left in their original type.

This ensures that a proper value AND type comparison can be done as well as prevents the PHP 8.1 deprecation notices.

Ref:
* https://developer.wordpress.org/reference/functions/map_deep/
* https://www.php.net/manual/en/function.str-replace.php

This commit:
- Fixes type-casting of non-string values to `string` (the flawed part of this assertion) by invoking `str_replace()` when the value is of string type.
- Fixes the PHP 8.1 `str_replace(): Passing null to parameter WordPress#3 ($subject) of type array|string is deprecated` deprecation notice.
- Micro-optimization: skips `map_deep()` when actual and/or expected are `null` (no need to process).
- Adjusts the method documentation for both this method and the `assertEqualsIgnoreEOL()` alias method to document that the `$expected` and `$actual` parameters can be of any type.

Follow-up to [48937], [51135], [51478].

Props jrf, hellofromTonya.
See #53363, #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51831 602fd350-edb4-49c9-b593-d223f7449a82

…itTestCase_Base::assertSameIgnoreEOL()`.

Basically, the whole `assertSameIgnoreEOL()` assertion was fundamentally flawed. The assertion contends that it checks that the expected and actual values are of the same type and value, but the reality was very different.

* The function uses `map_deep()` to potentially handle all sorts of inputs.
* `map_deep()` handles arrays and objects with special casing, but will call the callback on everything else without further distinction.
* The callback used passes the expected/actual value on to the `str_replace()` function to remove potential new line differences.
* And the `str_replace()` function will - with a non-array input for the `$subject` - always return a string.
* The output of these calls to `map_deep()` will therefore have "normalized" _all properties_ in objects, _all values_ in arrays and _all non-object, non-array values_ to strings.
* And a call to `assertSame()` will therefore NEVER do a proper type check as the type of all input has already, unintentionally, been "normalized" to string.

Aside from this clear flaw in the design of the assertion, PHP 8.1 now exposes a further issue as a `null` value for an object property, an array value or a plain value, will now yield a ` str_replace(): Passing null to parameter WordPress#3 ($subject) of type array|string is deprecated` notice.

To fix both these issues, the fix in this PR ensures that the call to `str_replace()` will now only be made if the input is a text string.
All other values passed to the callback are left in their original type.

This ensures that a proper value AND type comparison can be done as well as prevents the PHP 8.1 deprecation notices.

Ref:
* https://developer.wordpress.org/reference/functions/map_deep/
* https://www.php.net/manual/en/function.str-replace.php

This commit:
- Fixes type-casting of non-string values to `string` (the flawed part of this assertion) by invoking `str_replace()` when the value is of string type.
- Fixes the PHP 8.1 `str_replace(): Passing null to parameter WordPress#3 ($subject) of type array|string is deprecated` deprecation notice.
- Micro-optimization: skips `map_deep()` when actual and/or expected are `null` (no need to process).
- Adjusts the method documentation for both this method and the `assertEqualsIgnoreEOL()` alias method to document that the `$expected` and `$actual` parameters can be of any type.

Follow-up to [48937], [51135], [51478].

Props jrf, hellofromTonya.
See #53363, #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51831 602fd350-edb4-49c9-b593-d223f7449a82

Add covers to REST API endpoints props @spacedmonkey

1. Deprecated: preg_replace(): Passing null to parameter WordPress#3 ($subject) of type array|string is deprecated in /src/wp-includes/formatting.php on line 5407
2. Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /src/wp-includes/pluggable.php on line 603

…_postid()`.

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 `PHP_URL_HOST` as `$component`, which returns `null` if the URL only has a path. The return value of `parse_url()` was then passed to `str_replace()`, leading to a notice on PHP 8.1:
{{{
str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated
}}}

Adding validation for the return type value of `parse_url()` prevents that.

This commit addresses a few errors in the test suite along the lines of:
{{{
5) Tests_Rewrite::test_url_to_postid_home_has_path
str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated

/var/www/src/wp-includes/rewrite.php:503
/var/www/tests/phpunit/tests/rewrite.php:271
/var/www/vendor/bin/phpunit:123
}}}

Includes adding a dedicated unit test for a URL that only has a path.

Follow-up to [41786], [51606], [51622], [51626], [51629], [51630], [52799].

Props jrf, aristath, poena, justinahinon, SergeyBiryukov.
See #55656.

git-svn-id: https://develop.svn.wordpress.org/trunk@54364 602fd350-edb4-49c9-b593-d223f7449a82

This brings more consistency with other screens and avoids a PHP warning in `get_plugin_page_hookname()`:
{{{
preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated
}}}

Props ipajen, jrf, SergeyBiryukov.
Fixes #57578.

git-svn-id: https://develop.svn.wordpress.org/trunk@55263 602fd350-edb4-49c9-b593-d223f7449a82

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

…assic themes.

This brings more consistency with other screens and avoids a PHP warning in `get_plugin_page_hookname()`:
{{{
preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated
}}}

Follow-up to [13257], [13366], [55263].

Props nendeb55, costdev, SergeyBiryukov.
Fixes #57918.

git-svn-id: https://develop.svn.wordpress.org/trunk@55552 602fd350-edb4-49c9-b593-d223f7449a82

…assic themes.

This brings more consistency with other screens and avoids a PHP warning in `get_plugin_page_hookname()`:
{{{
preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated
}}}

Follow-up to [13257], [13366], [55263].

Props nendeb55, costdev, SergeyBiryukov.
Merges [55552] to the 6.2 branch.
Fixes #57918.

git-svn-id: https://develop.svn.wordpress.org/branches/6.2@55639 602fd350-edb4-49c9-b593-d223f7449a82

If the `$authordata` global is not set, `get_the_author()` returned `null`, causing a PHP 8.1 "null to non-nullable" deprecation notice in `ent2ncr()` hooked via `the_author` filter:
{{{
str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated
}}}

This commit updates `get_the_author()` to return an empty string if called before `$authordata` is set, bringing consistency with a few other similar functions which also return an empty string in this case:

* `get_the_author_meta()`
* `get_the_author_posts_link()`
* `get_the_modified_author()`

Follow-up to [695/tests], [2858], [11138], [12284], [20575], [34677], [44616], [53187].

Props Soean, jrf, sabernhardt, salvoaranzulla, antpb, ebai4, sajjad67, tijmensmit, SergeyBiryukov.
Fixes #58157.

git-svn-id: https://develop.svn.wordpress.org/trunk@55755 602fd350-edb4-49c9-b593-d223f7449a82

…nitize_option()`.

When saving the settings via the admin UI, the default value for any options not passed in the current `$_POST` request is set to `null` in `wp-admin/options.php`. Some options, e.g. `blog_public`, then rely on `null` being passed to `update_option()` to determine whether the value was changed or not.

This commit resolves a PHP 8.1 deprecation notice when saving the `gmt_offset` option without any changes:
{{{
Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated
}}}

Includes a similar fix for the `blog_charset` option.

Follow-up to [4112], [4329], [5541], [21849].

Props adi3890, dhrupo, hrdelwar, hasanmisbah, oglekler, mukesh27, SergeyBiryukov.
Fixes #57728.

git-svn-id: https://develop.svn.wordpress.org/trunk@56132 602fd350-edb4-49c9-b593-d223f7449a82

…-redundant-default-tax-delete-object-term-relationships-athorne

Bugfix/60052 remove redundant default tax delete object term relationships athorne

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

Fixed two pieces of code that were generating deprecated warnings:
-- Backtrace from warning 'strpos(): Passing null to parameter WordPress#1 ($haystack) of type string is deprecated' at /wp-includes/functions.php 7329:
this was the code causing the error: $scheme_separator = strpos( $path, '://' );

-- Backtrace from warning 'str_replace(): Passing null to parameter WordPress#3 ($subject) of type array|string is deprecated' at /wp-includes/functions.php 2189:
this was the code causing the error: $path = str_replace( '\\', '/', $path );

Update kses.php to fix deprecated warnings:

-- Backtrace from warning 'preg_replace(): Passing null to parameter WordPress#3 ($subject) of type array|string is deprecated' at /wp-includes/kses.php 1805:

This was the line of code causing the error:
$content = preg_replace( '/[\x00-\x08\x0B\x0C\x0E-\x1F]/', '', $content );

Co-authored-by: nimesh-xecurify
Add tests

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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