AJAX saving method instead of reloading the page

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

this would help decrease the load on the server and enhance the user experience.

[AaronCampbell]

+1 to this, I would think this could be implemented in a similar fashion to the auto-save.

I'm not sure it'll reduce server load much (stuff should be cached, etc), but it would definitely enhance the user experience.

[DD32]

On the other hand, Seeing the page reload upon save tells some users that it -has- saved, those who do not trust javascriptyness... (which should be few i admit)

[Denis-de-Bernardy]

+1 for ajaxing it, personally.

[mintindeed]

+1. It would make updating a post so much faster. It also seems to fit with the recent ajaxifications to the admin section (3.1+).

[MikeSchinkel]

Replying to DD32:

On the other hand, Seeing the page reload upon save tells some users that it -has- saved, those who do not trust javascriptyness... (which should be few i admit)

There are techniques to address this, such at the now tired old yellow fade technique, but something like that could be used to provide user feedback.

[jbkkd]

Just to add to what should be done, upon first saving, JS should add the post ID to the Query String using the window.history object.

[iseulde]

#22412 was marked as a duplicate.

[iseulde]

• The hooks in post.php and post-new.php are slightly different, so this could mean the page needs to be refreshed when transitioning between the two. Some plugin also add or remove fields from the page depending on the status of the post. For example, a plugin may remove the permalink field and date field from the page once the post has been published, to prevent the user from changing those. Lots of things can happen here. Plugins rely on the page being refreshed and actions and filters being rerun, so it's going to be really hard to change this.
• Nonces expire after 24 hours. Since the introduction of the heartbeat API some nonces are refreshed if the user is active. Currently though, if you're inactive for more than 24 hours, you will get an AYS message if you try to save. All nonces that are not refreshed with the Heartbeat API will expire if you don't save the post (page refresh) within 24 hours of the last save. This is something that needs to be fixed regardless, but with ajax saving it becomes more pronounced if it remains unfixed.

[westonruter]

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

[adamsilverstein]

Replying to westonruter:

Auto-save doesn't handle postmeta, right?

not yet, see #20564; this is in wp-post-meta-revisioning plugin - ​https://github.com/adamsilverstein/wp-post-meta-revisions/blob/master/wp-post-meta-revisions.php#L57

[dantewaters]

Replying to DD32:

On the other hand, Seeing the page reload upon save tells some users that it -has- saved, those who do not trust javascriptyness... (which should be few i admit)

Yea there should be a indicator that tells the user it has been saved (one that's quite clear).

[SergeyBiryukov]

#39585 was marked as a duplicate.

[bradadams]

Replying to dantewaters:

Yea there should be a indicator that tells the user it has been saved (one that's quite clear).

I'd suggest something like a fade out of the editor metaboxes and display a spinner. Once saved, fade back in (scrolled to the very top of page) with the standard "Page published/updated"/"Draft saved" notice.

Also a timeout on those notices would be nice, a little countdown on the right-hand side (15 seconds or so), beside the current close icon.

[louisJJ]

+1 for this feature. Super painful to get back to the scroll position and to reload the whole page :)

[johnbillion]

Now that we have the block editor which saves via Ajax requests to the REST API, the classic editor won't be seeing enhancements such as this.