WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#27419 closed defect (bug) (fixed)

Widget Customizer: Remove/Replace Widget_Customizer_Exception

Reported by: ocean90 Owned by: ocean90
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.9
Component: Widgets Keywords: needs-patch
Focuses: Cc:

Description

Should be replace with WP_Error, if necessary.

See wp-includes/class-wp-customize-widgets.php.

Attachments (3)

27419.patch (9.8 KB) - added by ocean90 7 years ago.
27419.2.patch (9.7 KB) - added by ocean90 7 years ago.
27419.3.patch (2.3 KB) - added by ocean90 7 years ago.
()

Download all attachments as: .zip

Change History (17)

This ticket was mentioned in IRC in #wordpress-dev by ocean90. View the logs.


7 years ago

#2 @westonruter
7 years ago

The majority of situations where Widget_Customizer_Exception is used it's intended to be used internally, so that the methods can throw this exception and handle it appropriately, for example: https://github.com/x-team/wordpress-develop/blob/b6e2bd9f0e8d49026c0b02f869124a749d68aac1/src/wp-includes/class-wp-customize-widgets.php#L1039-L1091

WP_Customize_Widgets::parse_widget_setting_id() throws this exception without catching it, so perhaps it can return a WP_Error, but we'd need to check the return value for is_wp_error() whenever it is used.

WP_Customize_Widgets::call_widget_update() throws this exception, catches it, and then re-throws it after rolling back the options transaction, so in this case a generic Exception would do: https://github.com/x-team/wordpress-develop/blob/b6e2bd9f0e8d49026c0b02f869124a749d68aac1/src/wp-includes/class-wp-customize-widgets.php#L1035

Thoughts?

@ocean90
7 years ago

#3 follow-up: @ocean90
7 years ago

  • Keywords has-patch added; needs-patch removed

27419.patch is a first pass to remove all exception parts. Most exceptions are just rare cases and we can instead simply return false or return via wp_send_json_error().

#4 in reply to: ↑ 3 ; follow-up: @westonruter
7 years ago

Replying to ocean90:

27419.patch is a first pass to remove all exception parts. Most exceptions are just rare cases and we can instead simply return false or return via wp_send_json_error().

Isn't it a bit unfortunate to lose all of the reasons for the errors?

#5 in reply to: ↑ 4 ; follow-up: @helen
7 years ago

Replying to westonruter:

Isn't it a bit unfortunate to lose all of the reasons for the errors?

Only from a developer perspective. From a user perspective, those types of errors can verge on frightening.

#6 in reply to: ↑ 5 ; follow-up: @westonruter
7 years ago

Replying to helen:

Only from a developer perspective. From a user perspective, those types of errors can verge on frightening.

Right, but they wouldn't have to be shown to the user. They can be logged out.

#7 in reply to: ↑ 6 @ocean90
7 years ago

Replying to westonruter:

Right, but they wouldn't have to be shown to the user. They can be logged out.

Sure, but then api.PreviewFrame.login() should be called.

@ocean90
7 years ago

#8 @ocean90
7 years ago

In 27652:

Widget Customizer: Improve error handling. First pass.

  • Replace Widget_Customizer_Exception with WP_Error
  • Call Previewer.cheatin() to show the cheating message if a user can't change widgets
  • Call Previewer.login() to show the login form if a user is logged out
  • Show a generic error message on failures

see #27419.

#9 follow-ups: @nacin
7 years ago

  • Component changed from Appearance to Widgets
  • Type changed from enhancement to defect (bug)

Getting this off the enhancements report.

I was going to comment here a week ago but helen beat me to it — basically, I agree that these errors are only good for developers. One thing we can do is pass debugging information into wp_send_json_error() — but keep in mind we do that nowhere else, so it'd probably be a separate task. Then at that point, you can at least see what the failure is tripping on. We'd also want to make sure what we reveal is not privileged.

FWIW, I read "They can be logged out" as westonruter referring to logging errors out to a file, versus the user actually being logged out. But if it resulted in Previewer.login() being used, that's a funny accident. :-)

#10 in reply to: ↑ 9 @westonruter
7 years ago

Replying to nacin:

FWIW, I read "They can be logged out" as westonruter referring to logging errors out to a file, versus the user actually being logged out. But if it resulted in Previewer.login() being used, that's a funny accident. :-)

Yes :-) "[Errors] can be logged out."

#11 in reply to: ↑ 9 @ocean90
7 years ago

  • Keywords needs-patch added; has-patch removed

Replying to nacin:

One thing we can do is pass debugging information into wp_send_json_error() — but keep in mind we do that nowhere else, so it'd probably be a separate task.

That's correct and the reason why I haven't pass the content of WP_Error to wp_send_json_error(). I have reserved message for public visible messages. The message of WP_Error can be passed as internal_message or just debug.

Before the ticket can be closed we have to add the translation functions.

that's a funny accident. :-)

It is. :-)

@ocean90
7 years ago

()

This ticket was mentioned in IRC in #wordpress-dev by ocean90. View the logs.


7 years ago

#13 @nacin
7 years ago

Let's not bother with the strings at all here and just use WP_Error with a code only. Here are my suggestions:

widget_setting_invalid, widget_setting_malformed, widget_setting_unsanitized, widget_setting_too_many, widget_setting_unexpected

#14 @ocean90
7 years ago

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

In 27854:

Widget Customizer: Remove strings from WP_Error returns and go with just IDs.

fixes #27419.

Note: See TracTickets for help on using tickets.