Opened 5 years ago
Closed 5 years ago
#49709 closed defect (bug) (fixed)
Call to undefined function esc_url() in wp-includes/class-wp-fatal-error-handler.php:190
Reported by: | rob006 | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | 5.4 | Priority: | normal |
Severity: | normal | Version: | 5.3.2 |
Component: | Site Health | Keywords: | has-patch commit fixed-major dev-reviewed |
Focuses: | Cc: |
Description
This bug was introduced in #47681. esc_url()
is used for generating error message, but without ensuring that this function is available. In case of using advanced-cache
drop-in, this function is not available, so you will get fatal error while handling original error:
PHP Fatal error: Uncaught Error: Call to undefined function esc_url() in .../wp-includes/class-wp-fatal-error-handler.php:190 Stack trace: #0 .../wp-includes/class-wp-fatal-error-handler.php(147): WP_Fatal_Error_Handler->display_default_error_template(Array, false) #1 .../wp-includes/class-wp-fatal-error-handler.php(52): WP_Fatal_Error_Handler->display_error_template(Array, false) #2 [internal function]: WP_Fatal_Error_Handler->handle() #3 {main} thrown in .../wp-includes/class-wp-fatal-error-handler.php on line 190
Attachments (2)
Change History (10)
#3
follow-up:
↓ 4
@
5 years ago
- Keywords has-patch added; needs-patch removed
- Milestone changed from Awaiting Review to 5.4
- Owner set to SergeyBiryukov
- Status changed from new to reviewing
Hi there, welcome back to WordPress Trac! Thanks for the report.
Moving to 5.4, as this is a regression in the previous release.
I think no-encode.patch would be preferable here, for consistency with _doing_it_wrong()
.
#4
in reply to:
↑ 3
@
5 years ago
Replying to SergeyBiryukov:
I think no-encode.patch would be preferable here, for consistency with
_doing_it_wrong()
.
For some more context, as previously noted in comment:1:ticket:47385# WordPress core translations are considered safe because we have a review process for them. esc_url()
was just used as a best practice precaution here, rather than a requirement.
I attached two possible patches. First uses
htmlspecialchars()
for encoding URL, second skips encoding entirely (it is already done in that way in_doing_it_wrong()
: 1 2).