Widget Customizer: Remove/Replace Widget_Customizer_Exception

[ocean90]

Should be replace with WP_Error, if necessary.

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

[westonruter]

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]

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

[westonruter]

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?

[helen]

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.

[westonruter]

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.

[ocean90]

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]

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.

[nacin]

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

[westonruter]

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

[ocean90]

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]

()

[nacin]

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

[ocean90]

In 27854:

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

fixes #27419.