Gutenberg: Autosave not saving Categories and tags

[JavonDavis]

There's an issue with Autosaving of Categories and Tags. If the post isn't saved via Save Draft or Update Tags and Categories are not saved. Navigating away from the page will also let you know there are still unsaved changes after the Autosaving completes.

Steps to reproduce

1. Starting at dotcom site with Gutenberg opted in
2. Create a new post
3. Assign either tags or categories or both
4. Wait for Autosave and then load preview

What I expected

Expected the tags and Categories to be present on the post in the Preview

What happened instead

• Tags and Categories not present in Preview
• Attempting to leave page prompts you to be sure you want to leave the page with unsaved work(this is not the same behavior if you create a new post without Categories or Tags)
• No errors in the console

Browser / OS version

Mac OS Mojave, Chrome v70

[gwwar]

Thanks @JavonDavis I verified the behavior 👍

[Copons]

I gave this a quick look: apparently there is a slight difference between Gutenberg in Core and in WPCOM when it comes to autosaves and previews.

In both cases, the autosave does not include categories and tags, while the normal save does.

Upon clicking the Preview button, Core always saves (not "autosaves"!) the post first, but WPCOM doesn't.
So, on WPCOM, we'd need a manual save to see categories and tags in the preview.

[Copons]

As it happens, I got the Gutenberg versions wrong.

Core Gutenberg started saving the post when clicking "Preview" only on version 4.5 (WordPress/gutenberg#12097), but the version of Gutenberg on WPCOM is currently the 4.4.0 (D21226-code updates to 4.5.1).

I've tried applying that patch, and it started saving categories and tags before opening the preview.

I'll close this for now because the fix is scheduled to land very soon.

[Copons]

Just FYI, 4.5.1 got merged yesterday (p7DVsv-5In-p2), and I can't reproduce this anymore. 🙂

[JavonDavis]

Awesome! @Copons do you know when it will be live? or how are you testing it right now? I've tried on dotcom and the latest version of calypso from master and not seeing the fix

[Copons]

The update is live, but you are right @JavonDavis, it's not fixed.
It's a bit tricky because there is a very tiny difference between Core and WPCOM, and I've yet to figure out the cause.

Basically we need to observe the isAutosaveable and isSaveable props of the Preview button. The post is fully saved only when it's autosaveable:

https://github.com/WordPress/gutenberg/blob/e4fd51cb535e8300b415973d7022b16c742c0d40/packages/editor/src/components/post-preview-button/index.js#L141-L158

In Core, this is what happens:

• Start new post. { isAutosaveable: true, isSaveable: false }
• Set some tags and categories. (No props changes)
• Set the title and/or the content. { isAutosaveable: true, isSaveable: true }
• After a bit, the post starts autosaving. { isAutosaveable: true, isSaveable: false }
• Once the autosave is complete: { isAutosaveable: true, isSaveable: true } for good.

In WPCOM, instead:

• Start new post. { isAutosaveable: false, isSaveable: false }
• Set some tags and categories. (No props changes)
• Set the title and/or the content. { isAutosaveable: true, isSaveable: true }
• After a bit, the post starts autosaving. { isAutosaveable: false, isSaveable: false }
• Once the autosave is complete: { isAutosaveable: false, isSaveable: true } for good.

The difference is that isAutosaveable is true by default in Core, and false in WPCOM.
I don't know the reason, but this is what's preventing it to save the post when previewing.

My previous comment failed in repro because I was in fact Previewing between the set-title and the autosave, which is indeed the only moment when isAutosaveable is true in WPCOM.

I'll reopen this and also involve other folks that might be more familiar than me on this flow.
cc @youknowriad @aduth @gziolo @brandonpayton

[aduth]

An autosave is only intended to store a couple fields, which does not include terms:

By default, WP keeps track of the changes to title, author, content, excerpt.

https://codex.wordpress.org/Revisions#Revision_Storage_Method

In fact, I'd be more intrigued if these are saved in core.

[aduth]

To expand, the behavior of "autosave" varies between drafts and published posts, only using revisions for the latter. Autosaving a draft post would incur a full save, which arguably could (?) include terms.

https://core.trac.wordpress.org/ticket/43316#comment:89

[Copons]

@aduth Indeed the autosave doesn't save tags and categories.
Though, previewing a new post, triggers a full save:

https://github.com/WordPress/gutenberg/blob/e4fd51cb535e8300b415973d7022b16c742c0d40/packages/editor/src/components/post-preview-button/index.js#L150-L151

The side effect is that tags and categories show up correctly in the preview.

Problem is that in WPCOM this full save does not happen, as the isAutosaveable prop is (almost) always false and therefore the openPreviewWindow function returns early and never gets to the save:

https://github.com/WordPress/gutenberg/blob/e4fd51cb535e8300b415973d7022b16c742c0d40/packages/editor/src/components/post-preview-button/index.js#L143-L154

What I didn't get around to figure out is why isAutosaveable is mostly true on Core, and mostly false on WPCOM. 🤔

[aduth]

Based on your previous debugging, I think it'd have to be the result of this check:

https://github.com/WordPress/gutenberg/blob/e4fd51cb535e8300b415973d7022b16c742c0d40/packages/editor/src/store/selectors.js#L510-L514

Do we receive into state an autosave in Calypso?

[Copons]

@aduth I've tried again with a load of live expressions monitoring all the checks of the isEditedPostAutosaveable selector, to figure out what causes it to return false.
Turns out, it's not its fault... 🤦‍♂️

There is a cute little prop that I wasn't paying attention to:

https://github.com/WordPress/gutenberg/blob/c446d069fdea0e3a848bbfa5b35a33b7ff9a3317/packages/editor/src/components/post-preview-button/index.js#L214

That forceIsAutosaveable is set in the header:

https://github.com/WordPress/gutenberg/blob/c446d069fdea0e3a848bbfa5b35a33b7ff9a3317/packages/edit-post/src/components/header/index.js#L55

And... yeah. My sandbox doesn't use meta boxes, while my local install of Gutenberg does.

So basically the fact that my Core Guten saved tags and categories on preview, was for unrelated reasons, and in fact WPCOM Guten is behaving as expected (aka: like Core Guten).

Though, I think @JavonDavis's issue is still valid, but it should be opened in Core instead.
I'll take care of it ASAP. 🙂

[alisterscott]

Possibly related: #28974

[Copons]

Opened a Core Guten issue, but it might be working as expected: WordPress/gutenberg#12472

Possibly related: #28974

@alisterscott most likely unrelated, but I've left some comments on both that issue and the Core Guten equivalent. 👍

[Copons]

I'm closing this because I think everything is working as expected, and changing the autosave behaviour is a Core thing (WordPress/gutenberg#12472, also already discussed plenty of times before).