Creating a custom comment_approved value (liveblog) was a good plan and helps keep the liveblog updates segregated from regular comments. The custom comment_approved value, however, poses a bit of a problem on the administrative side.
Our editors would love to have the ability to edit comments. Comment status handling appears to be hardcoded around the standard: approved, unapproved, trash, hold, etc.
Is there a plan to make changes to that functionality? Have those changes begun? Is that something that would be useful for me to work on and submit a patch?
For now, I suppose I can leverage the hooks in wp_transition_comment_status.
Yep, entry editing has been on the feature list since very early on but not an initial priority.
Two important things:
@mjangda: @borkweb just pointed out this trac ticket http://core.trac.wordpress.org/ticket/7532 to add a comment_modified_date_gmt column, but it hasn't had much traction. Does Automattic have a position on that? Real question: do you think is it worth our time to create a patch and try to move that discussion along?
As @mjangda said, the plan was all the management to happen in the front-end, so we didn't really care about having the comments show up in the backend.
In order the user to get the updates, a comment_modified column would be nice, but it's not gonna happen on the short-term, even if the ticket is committed. Schema changes are tricky, especially on WordPress.com.
We have a little-bit different infrastructure for distributing updates. Each change to a comment (update/delete) is a new comment with a comment meta liveblog_replaces, which tells us an update to which entry is this. If the content is empty, we assume the entry is deleted. This approach has the added benefit that we can cache AJAX responses indefinitely, because entries are immutable.
Unfortunately this is one of the abstractions, which aren't that well expressed in the code. See #4 for a suggestion how to make it better.
Now, to the point. In order to implement entry editing, you would need something very similar to liveblog.publisher.delete_entry(), but with the new contents, instead of empty string. I haven't done it because it needed a n hour or two of interface work, which I thought were better spent in other parts of the plugin.
Closing this, because now we have editing on the front end and making it work on the front-end would require some extra work.