[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:  westonruter
     Type:  defect (bug)              |      Status:  accepted
 Priority:  normal                    |   Milestone:  4.6
Component:  Customize                 |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by westonruter):

 Replying to [comment:9 NateWr]:
 > I had a quick test with the demo plugin. I really like it. A couple of
 thoughts:

 Thanks for the great feedback!

 > 1. It can be a little bit disorienting the way that the preview falls
 back to the currently saved value. For instance, I title a widget `Hello`
 and then save it. Then I type `Hello World` and see it in the preview.
 Then I add a `!` and the preview goes back to showing `Hello`. I don't
 think it's a critical problem, especially since the error message appears
 there. But can still feel a bit odd. If it could show the last valid value
 that'd be great.

 That's a good idea. And actually, this improvement you describe could be
 something we get for free with transactions (#30937). The problem with
 implementing it right now (before transactions) is that the setting values
 entered do not persist anywhere except in the life of the request. But
 with transactions, each update would get written to the transaction, with
 any invalid values being rejected from being written to the transaction (I
 presume). So yeah, in your example “Hello World” would get written to the
 transaction but then “Hello World!” would get rejected, so the preview
 would remain with “Hello World”.

 > 2. Skimming the code in the diff and the demo plugin, it looks like JS
 `Setting` objects now have a `Notification` object attached, and these are
 passed to a control, which has a `renderNotifications` method. So to
 render a validation error in a custom control we just need to do some work
 in the `renderNotifications` method, correct? That seems pretty
 straightforward if correct, and if I understand the code correctly it
 seems like errors will be announced (`wp.ally.speak`) prior to this,
 meaning we don't need to reproduce that. Very nice.

 Yes, a control can override how notifications are displayed by overriding
 the `renderNotifications` in the `wp.customize.Control` subclass.

 > 3. I'm wondering how I would go about extending a `Notification`
 object's `data` param. For my use case, I have a kind of "uber" `Control`.
 It saves to a single `Setting`, but in the process it compiles a bunch of
 different input fields into a single serialized string. So for me, the
 setting id won't be sufficient for determining where to display the error
 message. I would need additional params attached to the `Notification`. It
 seems to include a `data` param which looks like it is where extra data
 could be attached, but I'm not seeing anything in
 `api._handleSettingValidities` that would allow me to attach extra params.
 Can you point me to what I'm missing?

 This sounds very similar to what is needed for Customize Posts as well.
 For this plugin, a post setting contains the title, content, excerpt, and
 all the other core fields. When an invalid title is supplied, the entire
 setting is marked as invalid. However, there needs to be a way to indicate
 which specific control should receive the notification even though they
 all share the same post setting. The short answer is that the `validate`
 method for the setting needs to do something like this:

 {{{
 return new WP_Error( 'invalid_title', __( 'Invalid title' ), array(
 'post_field' => 'post_title' ) )
 }}}

 And then this `post_field` data will be included in the `Notification`
 object's `data` property, which you can use to determine whether or not
 the error should be displayed for a given control. In the case of
 Customize Posts, it should only get rendered on the Title control. I'm
 going to work on this for Customize Posts and I'll share with you the PR
 so you can review and adapt for your as well.

 Otherwise, a +1 from you for commit?

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