WordPress.org

Make WordPress Core

Opened 14 months ago

Closed 9 months ago

Last modified 9 months ago

#44809 closed defect (bug) (fixed)

Safeguard `has_errors()` check in extra Customizer validation

Reported by: flixos90 Owned by: flixos90
Milestone: 5.0.3 Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords: has-patch fixed-major
Focuses: Cc:
PR Number:

Description

The customize_validate_{$setting_id} filter is run in both the WP_Customize_Setting class, but then again in WP_Customize_Manager, to account for cases where someone might have overridden that method without maintaining the filter.

I ran into an issue earlier causing a fatal error: While the documentation for customize_validate_{$setting->id} states that the parameter is a WP_Error, several plugins and themes have been returning true in case of success. This is correctly taken care of in WP_Customize_Setting, but not when the filter is executed again in WP_Customize_Manager::validate_setting_values(). has_errors() is called on the filter result, which however (unfortunately) may not always be a WP_Error object. We should add a is_wp_error() check to be safe.

Attachments (1)

44809.diff (690 bytes) - added by flixos90 14 months ago.

Download all attachments as: .zip

Change History (14)

@flixos90
14 months ago

#1 @flixos90
14 months ago

  • Keywords has-patch added; needs-patch removed

44809.diff fixes the issue.

#2 @westonruter
14 months ago

  • Keywords commit added
  • Milestone changed from Awaiting Review to 4.9.9
  • Version set to 4.7

Good change. Feel free to commit!

Introduced in #37638.

#3 @flixos90
14 months ago

  • Owner set to flixos90
  • Resolution set to fixed
  • Status changed from new to closed

In 43578:

Customize: Safeguard a check on the customize_validate_{$setting_id} filter value to ensure it is a WP_Error.

While the filter is documented to only support a WP_Error, it has been a common practice to return true in a validation function if no errors have occurred. This was already caught when the same filter was executed in WP_Customize_Setting, it was however missing in WP_Customize_Manager::validate_setting_values().

Fixes #44809.

#4 @flixos90
14 months ago

  • Keywords fixed-major added; commit removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

This needs to be backported to 4.9.9.

#5 @SergeyBiryukov
14 months ago

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

In 43619:

Customize: Safeguard a check on the customize_validate_{$setting_id} filter value to ensure it is a WP_Error.

While the filter is documented to only support a WP_Error, it has been a common practice to return true in a validation function if no errors have occurred. This was already caught when the same filter was executed in WP_Customize_Setting, it was however missing in WP_Customize_Manager::validate_setting_values().

Props flixos90.
Merges [43578] to the 4.9 branch.
Fixes #44809.

#6 @pento
12 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

[43619] needs to be reverted from the 4.9 branch. This ticket can then be moved to the 5.0.1 milestone.

#7 @SergeyBiryukov
12 months ago

In 43702:

Customize: Revert [43619] from the 4.9 branch.

This change is out of the 4.9.x scope, and will be reintroduced in 5.0.x.

See #44809.

#8 @SergeyBiryukov
12 months ago

  • Milestone changed from 4.9.9 to 5.0.1

#9 @pento
10 months ago

  • Milestone changed from 5.0.1 to 5.0.2

#10 @pento
10 months ago

  • Keywords commit added

#11 @pento
10 months ago

  • Milestone changed from 5.0.2 to 5.0.3

#12 @desrosj
9 months ago

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

In 44392:

Customize: Safeguard a check on the customize_validate_{$setting_id} filter value to ensure it is a WP_Error.

While the filter is documented to only support a WP_Error, it has been a common practice to return true in a validation function if no errors have occurred. This was already caught when the same filter was executed in WP_Customize_Setting, it was however missing in WP_Customize_Manager::validate_setting_values().

Props flixos90.

Merges [43578] to the 5.0 branch.
Fixes #44809.

#13 @desrosj
9 months ago

  • Keywords commit removed
Note: See TracTickets for help on using tickets.