WordPress.org

Make WordPress Core

Opened 5 months ago

Closed 5 months 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)

htmlspecialchars.patch (1.2 KB) - added by rob006 5 months ago.
no-encode.patch (1.1 KB) - added by rob006 5 months ago.

Download all attachments as: .zip

Change History (10)

#1 @johnbillion
5 months ago

  • Keywords needs-patch added

@rob006
5 months ago

#2 @rob006
5 months ago

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).

#3 follow-up: @SergeyBiryukov
5 months 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 @SergeyBiryukov
5 months 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.

Last edited 5 months ago by SergeyBiryukov (previous) (diff)

#5 @SergeyBiryukov
5 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 47515:

Site Health: Remove esc_url() used on "Debugging in WordPress" article URL in WP_Fatal_Error_Handler::display_default_error_template().

The function may not be available in some contexts, for example if a fatal error happens in advanced-cache.php drop-in.

Props rob006.
Fixes #49709.

#6 @SergeyBiryukov
5 months ago

  • Keywords commit fixed-major dev-feedback added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for backporting to the 5.4 branch after a second committer's review.

#7 @jorgefilipecosta
5 months ago

  • Keywords dev-reviewed added; dev-feedback removed

#8 @SergeyBiryukov
5 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 47523:

Site Health: Remove esc_url() used on "Debugging in WordPress" article URL in WP_Fatal_Error_Handler::display_default_error_template().

The function may not be available in some contexts, for example if a fatal error happens in advanced-cache.php drop-in.

Props rob006.
Reviewed by jorgefilipecosta, SergeyBiryukov.
Merges [47515] to the 5.4 branch.
Fixes #49709.

Note: See TracTickets for help on using tickets.