![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Changes between Initial Version and Version 7 of Ticket #33507
- Timestamp:
- 09/16/2015 10:46:23 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #33507
- Property Summary Revamp widgets to be JS-driven → Allow widget controls to be JS-driven
- Property Owner set to
- Property Status new → accepted
-
Ticket #33507 – Description
initial v7 23 23 While the above focuses specifically on making the `WP_Widget::form()` and `WP_Widget::update()` both JS-driven, there may also be an opportunity to allow widgets to opt-in to JS-driven rendering of a given widget (i.e. implementing `WP_Widget::widget()`, in JS). This would make a lot of sense if the widget defined its template in Mustache (or Twig) and then allowed the instance array to be applied to that template either server-side or client-side. The effect for client-side would be postMessage instant previews of changes to widgets in the Customizer. The PHP-driven performant alternative to this would be partial-refresh as outlined in #27355. 24 24 25 By using JS-driven widgets, we will be able to use control templates for the widget controls as opposed to having to include a separate copy of the widget form with each control's params. This can drastically reduce the page weight, since the control template only needs to be included once. 26 25 27 By implementing JS-driven widget controls, the user experience of managing widgets would be vastly improved and the server load would be greatly reduced.
