Display server-sent Customizer setting validation errors before save is attempted
|Reported by:||westonruter||Owned by:||westonruter|
|Component:||Customize||Keywords:||has-patch has-unit-tests commit|
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 #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.
Change History (22)
11 months ago
- Keywords needs-unit-tests needs-patch added
- Owner set to westonruter
- Status changed from new to accepted