[wp-trac] [WordPress Trac] #34893: Improve Customizer setting validation model

WordPress Trac noreply at wordpress.org
Mon May 16 19:40:25 UTC 2016


#34893: Improve Customizer setting validation model
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
     Type:  enhancement                          |  westonruter
 Priority:  high                                 |      Status:  accepted
Component:  Customize                            |   Milestone:  4.6
 Severity:  normal                               |     Version:  3.4
 Keywords:  has-patch needs-testing needs-unit-  |  Resolution:
  tests has-screenshots                          |     Focuses:  javascript
-------------------------------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:32 celloexpressions]:
 > - I think we could probably use the class `.has-notifications` on
 `.customize-control` instead of having both `.customize-control` and
 `.customize-control-has-notifications`.

 I've done this in the latest patches.

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

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


More information about the wp-trac mailing list