[wp-trac] [WordPress Trac] #27491: Widget Customizer: Dynamically-created inputs cause from to replace itself without event to trigger re-initialization

[WordPress Trac]

#27491: Widget Customizer: Dynamically-created inputs cause from to replace itself
without event to trigger re-initialization
--------------------------+-------------------------
 Reporter:  westonruter   |       Owner:  ocean90
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  3.9
Component:  Widgets       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  javascript
--------------------------+-------------------------

Comment (by westonruter):

 > So, I think what should be done is we should stop rendering out the
 widget template as HTML and instead include it on the page in an unparsed
 form (e.g. in a `data` attribute). Then when the widget is added apply
 trigger a `widget-added` event (or `widget-form-rendered` to also be used
 when updates happen) so that any event handlers and dynamic fields can be
 initialized. This should be done on both the Customizer and the Widgets
 Admin page to handle setup for newly added widgets.

 Well, abandoning the old widget templating method would break plugins
 which manipulate the template via the DOM upon document ready. For example
 Jetpack's Widget Visibility injects the "Visibility" button before the
 "Save" button when the page first loads:
 https://github.com/Automattic/jetpack/blob/e9a1fe859cdbd3b2c8869de4a6dbd6cbe85fb526/modules
 /widget-visibility/widget-conditions/widget-conditions.js#L31-L45

 So instead, when adding a widget I think we should use `jQuery.clone( deep
 )` to copy the widget template for the new instance, then trigger a
 `widget-added` event. Then when the form gets replaced as result of a save
 or update action, then a `widget-updated` event can fire and at this point
 the same widget form initialization routines can be run which were done
 initially upon document ready.

 Disregard Chosen from this discussion because it seems to be fundamentally
 broken in this regard.

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