[wp-trac] [WordPress Trac] #7756: AJAX saving method instead of reloading the page

[WordPress Trac]

#7756: AJAX saving method instead of reloading the page
-------------------------+-----------------------------
 Reporter:  jdingman     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Editor       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  javascript
-------------------------+-----------------------------

Comment (by westonruter):

 Replying to [ticket:7756 jdingman]:
 > Instead of using a traditional page refresh after saving a post, utilize
 AJAX, similar to how auto-saving already functions, to save the post.

 Auto-save doesn't handle postmeta, right? This is the great difficulty I
 see attempting to implement Ajax saving of all the fields on an edit post
 screen: the metaboxes. Every save will require fetching new HTML contents
 of all metaboxes to ensure that they have the latest rendered content and
 populated fields, and to ensure that any JS initialization happens and
 that event handlers don't get lost on elements inside of the metaboxes.

 By the way, the work required here seems similar to what had to be
 implemented to add backwards-compatible support for widgets in the
 Customizer. The Widgets UI in Core are very PHP-centric, but the
 Customizer UI is JS-centric. In order to update a widget in the Customizer
 and ensure that the form refreshes as expected, each change to a widget
 includes an Ajax request to re-render the widget form with the latest
 widget instance state, and the newly-rendered form (in the Ajax response)
 then gets synced to the existing form (in the Customizer DOM). This is the
 `widget-synced` event. JS initialization happens at `widget-added` and
 `widget-updated` events. It is backwards compatible, but it is also
 brittle when widgets do have JS-driven forms, e.g. with repeating fields
 and dynamic fields. See #33507 for a proposal to allow widgets to opt-in
 to be JS-driven, which would solve a lot of headaches.

 I'm concerned that implementing Ajax saving and dynamic refresh of
 metaboxes will be a magnitude more complicated than what was implemented
 for widgets, if the metaboxes aren't written in a way to be JS-driven to
 begin with. On the other hand, if metaboxes were written in a way to be
 driven (“reactive”) by Backbone models (or another REST API-driven JS
 model), then the Ajax save of the post could just update the underlying
 Backbone models and the metaboxes could just re-render their Backbone
 views. The response for doing an Ajax save of the posts could include the
 updated REST resources for the post, postmeta, and related data and this
 data could then get pushed into any related models instantiated. It's
 probably too early for this, however.

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