WordPress.org

Make WordPress Core

Opened 11 years ago

Last modified 6 months ago

#7756 new enhancement

AJAX saving method instead of reloading the page

Reported by: jdingman Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Editor Keywords: needs-patch
Focuses: javascript Cc:
PR Number:

Description

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.

Change History (25)

#1 @AaronCampbell
11 years ago

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

#2 @FFEMTcJ
11 years ago

  • Keywords needs-patch added
  • Milestone changed from 2.8 to Future Release

#3 follow-ups: @DD32
11 years ago

  • Component changed from General to Administration

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)

#4 @Denis-de-Bernardy
10 years ago

+1 for ajaxing it, personally.

#5 @ericmann
9 years ago

  • Cc eric@… added

#6 @mintindeed
9 years ago

  • Cc gabriel.koen@… added
  • Keywords changed from ajax, saving, admin needs-patch to ajax saving, admin needs-patch

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

#7 @Backie
9 years ago

  • Cc Backie added
  • Keywords changed from ajax saving, admin needs-patch to ajax saving admin needs-patch

#8 @tillkruess
8 years ago

  • Cc me@… added

#9 @TheAdityaJain
7 years ago

  • Cc mail@… added

#10 in reply to: ↑ 3 @MikeSchinkel
7 years ago

  • Cc mike@… added

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.

#11 @ocean90
6 years ago

  • Focuses javascript added
  • Keywords ajax saving admin removed

#12 @jbkkd
6 years ago

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.

#13 @iseulde
5 years ago

#22412 was marked as a duplicate.

#14 @iseulde
5 years ago

  • Component changed from Administration to Editor

This ticket was mentioned in Slack in #core-flow by iseulde. View the logs.


5 years ago

#16 @iseulde
5 years ago

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

This ticket was mentioned in Slack in #core-editor by iseulde. View the logs.


5 years ago

#18 in reply to: ↑ description ; follow-up: @westonruter
4 years ago

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.

#19 in reply to: ↑ 18 @adamsilverstein
4 years ago

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

This ticket was mentioned in Slack in #core by michaelarestad. View the logs.


4 years ago

#21 in reply to: ↑ 3 ; follow-up: @dantewaters
4 years ago

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

#22 @SergeyBiryukov
3 years ago

#39585 was marked as a duplicate.

This ticket was mentioned in Slack in #core-editor by sergey. View the logs.


3 years ago

#24 in reply to: ↑ 21 @bradadams
3 years ago

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.

#25 @louisJJ
18 months ago

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

Note: See TracTickets for help on using tickets.