Add a post autosave lock

[adamsilverstein]

Description

Add a post autosave lock, similar to the post saving lock introduced in #10649. When post autosaving is lock, autosaves will not fire. Note that because autosaves are required for previewing, post previews will also be unavailable when post autosaving is locked.

Use case

In working on developing a block based revision display for Gutenberg, I am temporarily modifying block attributes to track and display changes. I need to prevent autosaves at this point to avoid saving the temporary modifications.

How has this been tested/How to test?

Load gutenberg and make some edits. In the console, type:
wp.data.dispatch( 'core/editor' ).lockPostAutosaving( 'mylock' );
Note: the post will no longer autosave.

Remove the post lock with:
wp.data.dispatch( 'core/editor' ).unlockPostAutosaving( 'mylock' );

Test adding multiple locks: autosaving will remain disabled until all locks are removed.

Types of changes

• Add actions for lock and unlock post autosaving.
• Add an isPostAutosavingLocked selector.
• Check isPostAutosavingLocked before autosaving.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[adamsilverstein]

Documented usage in docs/designers-developers/developers/data/data-core-editor.md do I need to add documentation elsewhere?

[gziolo]

Documented usage in docs/designers-developers/developers/data/data-core-editor.md do I need to add documentation elsewhere?

I'm not aware of any other place where we list such functionalities. However, it looks like we might need tutorial which explains how to have a more grained control over post publishing with custom actions like the one you propose here.

[gziolo]

Unit tests and e2e test are failing:

https://travis-ci.com/WordPress/gutenberg/jobs/210262659#L5610

with a quite similar message:

FAIL packages/editor/src/store/test/selectors.js (9.257s)
  ● selectors › isEditedPostAutosaveable › should return true if there is no autosave
    TypeError: Cannot read property 'postAutosavingLock' of undefined```

[adamsilverstein]

However, it looks like we might need tutorial which explains how to have a more grained control over post publishing with custom actions like the one you propose here.

I will start working on a tutorial, can you suggest which file I should add this to? Also, when I commit this locally, husky complains:

✖ node ./bin/update-readmes found some errors. Please fix them and try committing again.

block-editor
SyntaxError: Unexpected token >

I assume this is because I haven't added or changed a readme. Should that check include other .md files, or do I need to update a README (which one)? or should I instead add --no-verify to make the commit (which is what I did so far)?

[gziolo]

I will start working on a tutorial, can you suggest which file I should add this to? Also, when I commit this locally, husky complains:

✖ node ./bin/update-readmes found some errors. Please fix them and try committing again.

block-editor
SyntaxError: Unexpected token >

@nosolosw any ideas on why this fails?

I will start working on a tutorial, can you suggest which file I should add this to?

This is where we keep all the tutorials:
https://github.com/WordPress/gutenberg/tree/master/docs/designers-developers/developers/tutorials

It seems like we would need a new item there. @nosolosw, @mkaz and @chrisvanpatten should have some good ideas as they shaped together most of our docs :)

[gziolo]

In working on developing a block based revision display for Gutenberg, I am temporarily modifying block attributes to track and display changes. I need to prevent autosaves at this point to avoid saving the temporary modifications.

I'm thinking now that it might be confusing to have both lockPostAutosaving and lockPostSaving. Do you have some thoughts about how this should work together? I have no idea what use cases are on the table. Do you see a case where autosaving should be locked but it's still fine to allow saving?

[adamsilverstein]

I'm thinking now that it might be confusing to have both lockPostAutosaving and lockPostSaving. Do you have some thoughts about how this should work together? I have no idea what use cases are on the table. Do you see a case where autosaving should be locked but it's still fine to allow saving?

For my particular use case it might not be necessary to separate them - another approach would be to have the postSavingLock ALSO prevent post autosaving. One potential issue with that is that because previews rely on autosaves, locking them means preview is unavailable which might not be what you want when you are locking saving.

Typical use case for save locking it to prevent saving until some pre-flight condition has been met: for example, the content must contain at least one image block, or all images in the content must include alt tags.

My use case for autosave locking is for my (experimental) block revisioning plugin which enables browsing thru revision history to see which blocks were added, which blocks were removed and which were changed.

The plugin currently uses the main editor, loading its revision block display when you enter the revision display mode, and then restoring the post to its original content when you leave the revisions mode. As the post content is temporarily changed, I don't want to save this temporary state in any way.

Some alternate approaches I have considered but haven't explored thoroughly:

• Blocking autosaving on the server side - sub optimal as the UI will still appear to run autosaves.
• Setting the autosave interval to a very high time: does not appear to be possible to alter the interval on the fly?
• Use an overlay copy of Gutenberg to display the temporary block revision view: more complex, likely more resource intensive.

[adamsilverstein]

@gziolo this is ready for additional review/feedback whenever you have some time.

[oandregal]

@adamsilverstein is #16249 (comment) still happening (the SyntaxError: Unexpected token > error)?

My first thought is that it is related to the introduction of React Fragment syntax some months ago (<>) that I fixed in ed630e8. Can you try rebasing master?

[adamsilverstein]

Can you try rebasing master?

Yep, thanks.

[gziolo]

We still miss actions which enable and disable lock for autosave. We mostly need them to have a way to expose them in docs and make them easier to use. We have similar actions for regular post saving lock: lockPostSaving & unlockPostSaving.

[gziolo]

What do you think about moving the part which checks whether there is a lock for autosave ! isPostAutosavingLocked() to the isEditedPostAutosaveable selector? It seems like the post can be autosaveable only when there is no lock for autosave.

[adamsilverstein]

I'll give that a try

[adamsilverstein]

Ah, this is already moved: https://github.com/WordPress/gutenberg/pull/16249/files#diff-dfe03f16c813b680115a3b1894eb6d5fR538

[adamsilverstein]

@gziolo This is ready for your re-review.

[gziolo]

All good, thanks for all iterations added 👍

[gziolo]

This branch needs to be rebased now, I should merge after review to avoid it 🙃

[youknowriad]

Question here: why not just lock auto saves and preview when saving is locked as well? (to avoid a new API). I feel these might be related but maybe I'm missing something?

[adamsilverstein]

These are related, but different feature to lock/unlock.

Post save locking is useful for controlling updates or publication - for example a pre-flight check. in this case, you still want autosaves to work so a user does not loose their work

A use case where locking autosaves is useful when you want to avoid temporary saves for some reason, for example if you are showing temporary/staged changes in the editor and you don't want these saved. In this case, you might disable saving as well, or keep it enabled but revert temporary changes before saving. Alos, some users may want disable autosaves entirely, this lock enables that with preventing regular saves.