#25272 closed task (blessed) (fixed)
Refactor/clean up autosave and use heartbeat for transport
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | normal | Version: | 3.8 |
Component: | Autosave | Keywords: | early |
Focuses: | Cc: |
Description
Autosave has lots of "moving parts" and over the years many additional functions were "pinned" to it. In 3.6 most of the additional functionality was moved to heartbeat, like logged out warning, nonces update, etc. It's time to move the saving of post data over to heartbeat as originally planned, and avoid the extra XHR.
Attachments (7)
Change History (41)
comment:2
azaozz
— 7 months ago
25272.2.patch fixes a typo/missing arg in post_preview() in 25272.patch.
comment:4
azaozz
— 7 months ago
In 25272.3.patch:
- Move form submit handling, #title.blur(), etc. from autosave.js to post.js as they are only for that screen.
- Rename 'wp.autosave.remote' to 'wp.autosave.server'.
This patch requires the heartbeat http://core.trac.wordpress.org/attachment/ticket/25073/25073.2.patch and includes the updated tests from 25272-tests.patch.
comment:5
nacin
— 7 months ago
- Keywords early added
- Milestone changed from 3.7 to 3.8
This is huge. Per IRC, early 3.8. See also #23362 for 3.8.
comment:6
westonruter
— 7 months ago
- Cc weston@… added
comment:7
follow-up:
↓ 8
westonruter
— 7 months ago
@azaozz:
In your latest patch, could you make the following tweak:
- $('form#post').attr('target', 'wp-preview').submit().attr('target', ''); + $('form#post').attr('target', $(this).attr('target')).submit().attr('target', '');
Two reasons for this. First, it eliminates redundancy as the wp-preview target is already defined in post_submit_meta_box() as:
<a class="preview button" href="<?php echo $preview_link; ?>" target="wp-preview" id="post-preview"><?php echo $preview_button; ?></a>
Secondly, I'm working on a plugin <https://github.com/x-team/wp-customizer-everywhere> that manipulates the window target for the preview, and the only way to do so at the moment is to override the global doPreview function with one that uses the above change. But if the #post-preview click handler supplies the $('form#post').attr('target') from its own target attribute, then a plugin just has to manipulate the preview link/button target upon jQuery.ready.
comment:8
in reply to:
↑ 7
azaozz
— 6 months ago
Replying to westonruter:
This makes sense. Combined with the suggestion from #20233 about adding the post_id to the form submit target it should remove some confusion.
comment:9
kadamwhite
— 5 months ago
- Cc kadamwhite@… added
comment:10
adamsilverstein
— 5 months ago
- Cc adamsilverstein@… added
comment:11
azaozz
— 5 months ago
In 25272.4.patch: refresh, pass autosave.js through jshint, make few names more specific.
comment:12
azaozz
— 5 months ago
- Milestone changed from 3.8 to Future Release
Moving to 3.9-early as discussed in the dev chat on 2013-11-20
The patch is quite large and could potentially introduce hard to spot bugs. 3.8 is even more condensed than 3.7, better to keep everybody's attention on the main features: MP6, Dashboard, Themes screen, Widgets...
comment:13
azaozz
— 3 months ago
- Milestone changed from Future Release to 3.9
In 25272.5.patch:
- Improvements for wp.autosave.server.
- Catch changes in both editors on beforeunload.
- Refresh post.js.
comment:14
azaozz
— 3 months ago
In 26995:
comment:15
azaozz
— 3 months ago
In 27003:
comment:16
azaozz
— 3 months ago
In 27015:
comment:17
azaozz
— 2 months ago
In 27038:
comment:18
avryl
— 2 months ago
There's a typo in autosave.js on line 352: 'click.autosae-local'.
https://core.trac.wordpress.org/browser/trunk/src/wp-includes/js/autosave.js?rev=27038#L352
comment:19
nacin
— 2 months ago
We should probably set window.autosave = wp.autosave. Not sure if any plugins were using it to force an autosave, but there's little harm in doing so.
comment:20
nacin
— 2 months ago
In 27092:
comment:21
azaozz
— 2 months ago
We should probably set window.autosave = wp.autosave...
Was looking at how many plugins do autosave = function(){} to disable it, may need to add back-compat for that.
comment:22
azaozz
— 2 months ago
In 25272.6.patch: back-compat, before saving check whether the old window.autosave() was overridden by a plugin.
comment:23
azaozz
— 2 months ago
Looks like there are eight plugins that disable autosave by overriding window.autosave(). Four are derivatives of AtD that will have to be updated anyway.
At this point I'm 50/50 on whether we need 25272.6.patch.
comment:24
nacin
— 2 months ago
What was the canonical way in 3.8 to say "whoa there, don't run autosave"? Setting window.autosave to nothing? Maybe it was setting blockSave to true? I'm not sure what kind of back compat is needed here, but it seems like people surely came up with *some* way to block autosaves when necessary.
comment:25
SergeyBiryukov
— 2 months ago
comment:26
azaozz
— 2 months ago
What was the canonical way in 3.8 to say "whoa there, don't run autosave"?
Core used autosave = function(){}; mostly because jquery.schedule.js can't cancel existing schedule properly, it runs one more time. Some plugins picked that up too. Don't see any blockSave = true when searching the github mirror.
Speaking of jquery.schedule.js, it's not used anywhere in core any more. We need a way to deprecate scripts.
.button-disabled and .button-primary-disabled classes were removed from JS...
Thinking they are needed for back-compat.
comment:27
DH-Shredder
— 5 weeks ago
Is there a reason not to include the back-compat for overriding window.autosave()?
Since we're already defining it, it seems like not very much extra to do so.
On the second note, does it look like plugins are using .button-disabled and .button-primary-disabled?
comment:28
nacin
— 5 weeks ago
In 27405:
comment:29
nacin
— 5 weeks ago
- Type changed from enhancement to task (blessed)
comment:30
nacin
— 3 weeks ago
In 27611:
comment:31
nacin
— 3 weeks ago
In 27612:
comment:32
nacin
— 2 weeks ago
- Resolution set to fixed
- Status changed from assigned to closed
In 27713:
comment:33
nacin
— 2 weeks ago
New tickets for new issues. For example, #27503.
comment:34
azaozz
— 4 days ago
In 27981:
In 25272.patch: