Feature request: Autosave editorial comment field before submission

[jerclarke]

Currently if you type up an editorial comment but don't submit it, then save the post, the comment text is lost. This is natural in a way and users correctly "blame themselves" but still, it's not ideal.

My request is that the value in the editorial comment field be saved for each user while they are editing the post, even if they don't submit.

Here's the use case where it's important:

• Editor is reviewing a post and working up a detailed reply for author.
• They want to craft their reply carefully with an overall narrative based on reviewing the whole post.
• They are writing detailed notes about what they changed.
• They have changed enough about the post that doing a manual save is sensible even though the comment isn't ready.
• They only want to send the author 1 email as a result of their comments.

In this scenario, which comes up al the time for us, the editor ends up very likely to hit "save" on the post, trusting WP to autosave everything, only to come back and find their "draft" comment is gone and there's no way to get it back. They can work around this by e.g. typing the comment in an external editor, copying the comment before saving and immediately pasting it back in after saving, writing the comment in the post body etc. but none of these are elegant.

If EF just saved the text and re-inserted it after the post save users wouldn't even have to think about this aspect. They would have their comment text waiting after post save and find it totally normal because that's how all the other forms on this page work.

Not sure how hard it would be to implement, but I imagine there are some quick solutions that could reap large rewards. Ideally it would have a whole ajax-based autosave system like the post body, but IMHO that's not really necessary compared to a bare-bones solution that just ensures manually saving (in which case we should already have the partial form data while saving) passes the comment text around and gets it back in the form for that user.

Thanks and looking forward to any feedback.

[cojennin]

Currently if you type up an editorial comment but don't submit it, then save the post, the comment text is lost. This is natural in a way and users correctly "blame themselves" but still, it's not ideal.

Yea, that sounds pretty annoying.

If EF just saved the text and re-inserted it after the post save users wouldn't even have to think about this aspect. They would have their comment text waiting after post save and find it totally normal because that's how all the other forms on this page work.

Yea, makes sense. Though we'll have to think through the two points you mentioned

• They have changed enough about the post that doing a manual save is sensible even though the comment isn't ready.
• They only want to send the author 1 email as a result of their comments.

Would need to add a Save as Draft button to a comment and figure out how to save a comment with a status like draft to make sure we don't trigger an email.

Just something I was thinking about on the train this morning after reading your comment: Have you explored using localstorage to save the comment text being worked on? I think Twitter.com uses it when creating a tweet in the browser (as you type it'll store the tweet text in localstorage and if you navigate away from Twitter while working on a tweet it will restore the tweet text from local storage when you navigate back to Twitter). Might be an interesting proof of concept that could be built into a plugin on top of Edit Flow. Avoids triggering notifications accidentally and having to manage different comment statuses.

[jerclarke]

Thanks for thinking about it!

The localstorage option is interesting, but could get really tricky if users have multiple posts open (a real scenario in our case) and I have no experience at all with those kinds of browser APIs.

My idea of implementation was a lot simpler, but maybe it was too simple and implementing "comment statuses" would actually be the MVP to fix the problem. My idea roughly:

• User hits save, sending the huge form that makes up the post.
• EF intercepts the $_POST and fishes out any text in the Editorial Comments textbox (which will always be a "draft"/unsent comment).
• If text is found EF stores it in a postmeta field with a name like ef_ec_draft_$USERID
• When the form is reloaded we look for ef_ec_draft_$USERID and insert it if found then remove the postmeta.

A simple system with little flexibility but also relatively easy to imlement without modifying tables and stuff. Main thing I'm not sure about is comment threading. If there's a way to pull out the "intended parent" of the unsaved comment (in cases where the editor used "reply" on a specific other comment), then the postmeta could be an array with the text and parent so it could be re-inserted at the right place. If the parent info couldn't be found then IMHO just putting the comment in the box would still be a huge improvement. I know my editors would rather accidentally add a new comment rather than a reply if it meant not re-typing the whole response.

_UPDATE_

Inspecting _POST I found everything we need when a post is submitted (checked during wp_insert_post:

_POST[replycontent] => TEXT OF COMMENT
_POST[ef-comment_parent] => COMMENT PARENT ID
_POST[ef-post_id] => POST ID

[jerclarke]

Got it working! Maybe it's just a proof-of-concept, but so far it solves my problems and it only requires two functions that could easily be integrated just about anywhere.

See this gist for my working code:
https://gist.github.com/jerclarke/08800924bafee5e948769df2013b7949

This could be it's own WP plugin but IMHO that's way overkill.

Not sure how it would best be integrated into EF itself, but if no one objects to the premise it should be pretty easy to slot in.

It DOES support parentage and will automatically insert the text as a reply to the correct parent comment.

To get it working I had to have jQuery "click" the appropriate button (to make the textarea show) before inserting the text. Not sure if this is too hacky or not, let me know :)

[cojennin]

Nice work! Seems like solid way to solve your use case!

Not sure how it would best be integrated into EF itself, but if no one objects to the premise it should be pretty easy to slot in.

Definitely has me curious about how this could benefit newsrooms. Was thinking of some questions I'd want to ask on the train this morning once we started storing this kind of data:

• Who's currently editing (commenting) on this story? (we'd probably need to store who created the draft comment and when it was created)
• How long have they been editing it? (we'd need to store last update on the comment)
• What's being edited and what's just finished and ready for moving to the next stage of our workflow (might get a bit funky. If we kept the data in post meta I think we'd need to do a get_comments and a WP_Meta_Query?)

I've wandered outside the scope of what you originally intended, but I think this could provide real interesting insights and information for newsrooms. Curious to hear your thoughts!

[jerclarke]

Yeah, I think you wandered pretty far outside the core core usability problem with all that.

My solution does track who saved the comment because their user ID is in the postmeta label.

Personally I don't think adding a ton of metadata and long-term tracking of editorial comment drafts should be a big priority for Edit Flow at this point. They will rarely exist and will often become "submitted" in short order. If you wanted to create an editorial comments dashboard or something then only showing submitted comments would almost definitely be the right solution (otherwise you might expose unfinished comments that embarass/confuse people).

My solution is intentionally light and self-destructive so that the data is as temporary as possbile.

[cojennin]

Yea, all solid points!

If you wanted to create an editorial comments dashboard or something then only showing submitted comments would almost definitely be the right solution (otherwise you might expose unfinished comments that embarass/confuse people).

Yes, good point. Much less interested in the content of the edits. More interested in giving transparency into the editing process. What's being worked on, what's undergoing editing, etc.

Yeah, I think you wandered pretty far outside the core usability problem with all that.

Yea, most definitely. Just seems the core usability problem is kind of interesting (i.e., why do people feel the need to have "draft" editorial comments?) When you hit Save Draft on a post, other content you've typed into form fields (tags, categories, excerpt, etc) is immediately committed.

I see editorial comments as a place for quick hits and short remarks. So Save Draft should either commit them and send a notification or discard (since they're not meant to be edited and refined at a later date).

But if folks expectations are editorial comments should live independently of a post and they should be able to revisit them and rework them, might be worth investing some time into rethinking them.

[cojennin]

The code you wrote definitely solves your usability problem, and is exactly how I would have done it to solve your issue. I'm just always curious to hear about how other newsrooms use Edit Flow, and the usability problem you have seems like it might indicate an interesting use case. Or maybe not. But I'm always curious!

[WPprodigy]

Noting that Gutenberg does avoid this issue. Saving/changing post statuses doesn't force the full page to refresh, so any content in metaboxes and other fields is not lost.

Given the low activity on this, I'm thinking maybe we could close this out? The snippet you've made is a good option for those that absolutely need this in the classic editor, but I'm not super convinced it's something that needs to be in the core plugin - given that this same behavior would happen for any other metabox out there.

Will await a second opinion before closing this though.