Prevent save if post has no saveable content

[aduth]

Fixes #1201

This pull request seeks to hide the Save button and disable the Publish / Update button if the post does not have sufficient content (title, excerpt, content) to be saved.

Testing instructions:

Repeat testing instructions from #1201, noting that a new post cannot be saved.

Verify also that a post with content can be saved, whether that post is newly created or loaded from save.

[BE-Webdesign]

If you click into the paragraph block on a new post, without adding any text you can save. The title and excerpt detection work well. If you then load that empty post in Gutenberg to edit it, the update button works as expected.

Also maybe unrelated but if you type and click out side the block then delete the content you can still Publish/Update. TinyMCE is storing the content as an empty "", which triggers the blockCount to be greater than 0 ( I think ). Also if you type into the paragraph, it won't update the state. It doesn't seem until you deselect that block in some way that the blockCount will increment itself up, allowing you to save.

Not sure why the behavior is different between Publishing vs. Updating either. Maybe something to do with getBlockCount?

Update: seems like you can add text to the title then delete, and still be able to save, same goes for the excerpt field on already existing empty posts, so maybe not merge as is. This will probably be tricky to get 100% without using some sort of persistent state checking. I don't know how many people would type stuff then delete it and then save so from a use case perspective this is probably fine.

[aduth]

If you click into the paragraph block on a new post, without adding any text you can save.

At this point, the post is technically valid for save, since even though there's no visible content, the comment demarcations are enough to allow the request to complete successfully. And you could go as far as to say that there is meaningful content, since the next time the editor loads it knows that there is a text block within the post, even if the value of that block is currently empty.

More granular consideration is made difficult by the fact that we have no single concept of what it means for a block to be empty (#1181 (comment)). Some blocks with empty serialized content are valid (#1134).

Also if you type into the paragraph, it won't update the state. It doesn't seem until you deselect that block in some way that the blockCount will increment itself up, allowing you to save.

Yeah, not specifically related to the changes, and described in detail at #1166 (comment).

Not sure why the behavior is different between Publishing vs. Updating either. Maybe something to do with getBlockCount?

Can you clarify what you mean here?

Update: seems like you can add text to the title then delete, and still be able to save

I'm not able to reproduce this. I'm correctly barred from saving if the title is ever empty (assuming no other content).

This is what I see: https://cloudup.com/cib07x8M3xI

[BE-Webdesign]

Not sure why the behavior is different between Publishing vs. Updating either. Maybe something to do with getBlockCount?

I'm not able to reproduce this. I'm correctly barred from saving if the title is ever empty (assuming no other content).

The two are related. My misunderstanding is tied to

since even though there's no visible content, the comment demarcations are enough to allow the request to complete successfully

I am assuming that is triggering the blockCount to increment, which would explain the behavior I saw. On new posts the title field and excerpt field work well for me too, as demonstrated in the video, but if you have an already existing post with an "empty" block, you can still update after typing into the title and excerpt, and clearing them out, because there is the "empty" block, which will put the blockCount at 1.

So I think this is good to go.

[aduth]

but if you have an already existing post with an "empty" block, you can still update after typing into the title and excerpt, and clearing them out, because there is the "empty" block, which will put the blockCount at 1.

Part of this might be related to #916, since at the moment we flag a post as having changes regardless even if a field has changed but was then reverted back to its original value.