Post/Pages: Better handling of local only post.

[aerych]

When creating new post or page we create a local "draft" to save in core data. This presents a few UX challenges dealing with where the local "draft" appears, the features available, how its sorted, and how it behaves in certain failure states (see #3737 for @koke's examples).

• local only posts/pages should show local badge of some sort
• local only posts/pages should appear first in list until there is a remote counterpart
• local only posts/pages should have no "remote" options e.g. stats
• fix issues with deleting a local only post/page that failed to publish

cc @diegoreymendez and @bummytime as I want to make sure this plays nice with all our editor concerns.
cc @mnt to keep in the loop regarding the local UX and appearance.

[aerych]

First pass at improving the appearance of a local post.

[koke]

But, if it's local, Trash won't trash it but delete it, and View will take you to a non-existant post 🐇 ⛳

[aerych]

Trash won't trash it but delete it

This is what we want tho.

View will take you to a non-existant post.

It should just show a local preview.

[aerych]

Trash won't trash it but delete it

I guess we should make the label say "delete"

[aerych]

Sorting is being a little tricky. I'm not seeing any other way to sort accurately with the properties we currently have.

To fix the sorting issue, I think its going to take adding two new fields to the data model, one field to act as a "publish immediately" flag, another field to act as a "local only" flag. NSSortDescriptors can target these properties to make sure post with a nil date (our convention for publish immediately) or that have no remote version appear at the proper place in the list.

I'm thinking we can override the setters for date_created_gmt and remoteStatusNumber (using willChangeValueForKey and didChangeValueForKey) to ensure that the new flags always properly updated.

Thoughts? I'm definitely open to other ideas.

[koke]

In the past, we've used postID != nil as a flag for local posts. Would having different sections in the results controller (instead of using sort descriptors) help?

[aerych]

Would having different sections in the results controller (instead of using sort descriptors) help

Dunno, but that's an idea worth exploring.

In the past, we've used postID != nil as a flag for local posts

I think something changed. postID defaults to -1 for local posts now.

[aerych]

I looked into sections to see if there was a way we could use them but it seems like another dead end.

As best I can tell results need to already be sorted correctly. Sections seem to just group the already sorted items vs change the sort order.

[koke]

As best I can tell results need to already be sorted correctly. Sections seem to just group the already sorted items vs change the sort order.

Correct 😞

If this key path is not the same as that specified by the first sort descriptor in fetchRequest, they must generate the same relative orderings. For example, the first sort descriptor in fetchRequest might specify the key for a persistent property; sectionNameKeyPath might specify a key for a transient property derived from the persistent property.

[aerych]

Closed in #3805