[wp-trac] [WordPress Trac] #36944: Display server-sent Customizer setting validation errors before save is attempted

[WordPress Trac]

#36944: Display server-sent Customizer setting validation errors before save is
attempted
--------------------------+-------------------
 Reporter:  westonruter   |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  4.6
Component:  Customize     |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-------------------
 Following up on #34893.

 At the moment, the setting validation errors that are returned by
 `WP_Customize_Setting::validate()` are only displayed when a save is
 attempted. This is the only situation where these errors are sent back
 from the server, as part of the `customize_save_response`. However, now
 that there is strict validation available in the Customizer, if a
 validation error does happen when editing a setting, then the behavior is
 for the Customizer preview to act as if the supplied setting does not
 exist at all. This is a bad user experience because then their changes in
 the preview just disappear. In this case, I should think it is unlikely
 that the user would try to save their changes since they don't appear
 properly in the preview, and thus the validation errors would never get
 displayed to the user.

 With transactions, this issue would be addressed by continually sending
 the setting values to the server to amend the transaction, and in the
 response the validation errors could be included, as noted in
 [https://core.trac.wordpress.org/ticket/34893#comment:42 #34893 (comment
 42)]:

 > > - Selective refresh seems to revert to the previous setting value when
 a setting is invalid. Perhaps we should do this but also keep it faded/in
 an updating state to indicate that there is a problem with the current
 setting (hence the previous value being used)?
 >
 > Yeah, the revert to the previous setting is a result of the invalid
 settings now being (properly) rejected, and so they are treated as if they
 weren't supplied at all. This would be true in both selective refresh and
 full-page refresh. At the moment, it would be up to the control to display
 the notification using JS to give feedback for why an update isn't
 appearing, as currently PHP-supplied error notifications are currently
 only being sent back upon attempted Save. However, with '''transactions'''
 (#30937) each change to a setting would get submitted to the server via a
 `PATCH` request, and so ''this'' is where I think we'd need to ultimately
 provide this feedback for why a setting change isn't appearing in the
 preview. I don't know if we should display any invalidity state inside the
 preview itself.

 In the mean time, without transactions in core, there needs to be an
 alternate mechanism for giving early feedback on validation errors. I
 suggest that we can send back the setting validation states whenever the
 preview is refreshed or whenever a selecting refresh occurs.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36944>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform