Opened 6 years ago
Closed 6 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: |
|
Owned by: |
|
|---|---|---|---|
| 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
@
6 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
@
6 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).