Originally, the idea was to re-use the revision log node property inside nodechanges, alter the UI to make that field more prominent, and use it for the comment body for the auto-generated comment about the revision. However, that wasn't going to work, since revision log is plain text only, and people obviously want/need filtered HTML (e.g. to be able to use [#x] links, etc) in their comments. See #1733658: Inject a comment body text area and input format selector into the node edit form for that.
Now we've got this separate text area for the comment body, but we're asking for the same thing that usually would go in revision log. So we've got 2 fields on the node UI asking for nearly the same thing but supporting different functionality and displayed in different places (revision log on the revisions tab etc, revision comment in the comment history).
A) Hide the revision log property entirely and always leave it blank. Easy, but leaves the revisions tab without any info or context.
B) Hide the revision log property and try to automatically populate it with the first 140(?) characters of the revision comment. We'll any markup will be rendered as plain text, potentially confusing.
C) Hide the revision log property and try to automatically populate it with an html2text version of the first 140(?) characters of the revision comment. Basically, filter on input a bit, not for security, but for legibility.
D) Ignore this entirely and leave the two separate fields (a.k.a. call this "by design").
E) Other?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1979556-3.nodechanges-no-core-revision-log.patch | 2.44 KB | dww |
Comments
Comment #1
tvn commentedDefinitely not D. I thought we could use comment number or link to the comment in the revision log, but, as dww pointed out in IRC, that's not possible since we don't know comment number/id before we actually save the new revision. So from available options in the issue summary, I would go for C.
Comment #2
dwwWorking on this now.
Comment #3
dwwThis seems to work well with local testing.
I think core is doing filter_xss(), but some markup is working. So I don't know if it's worth trying to html2text() or not.
Since {node_revision}.log is type longtext, I'm also not sure we need to truncate the value.
Although, there's no formatting, so long comments will just get mushed together into a semi-illegible mess.
Thoughts?
Thanks,
-Derek
Comment #4
tvn commentedWould be nice to see this in action on some dev site first, but I think we should truncate the value. Some comments are *very* long, what's the use of having all that text in the revision log.
Comment #5
drummLet's keep this without formatting, and truncate it to 140 characters. Then we can try it out and adjust if necessary, maybe waiting until after launch to see if anyone notices.
Comment #6
dwwAdded
drupal_html_to_text()and a check to truncate to 140 chars if the comment is longer than that. Pushed:http://drupalcode.org/project/nodechanges.git/commit/17d5f23
Then got cold feet about this feature and added a field setting to control the behavior in case people don't actually want any of this:
http://drupalcode.org/project/nodechanges.git/commit/156a6e2
And therefore, pushed a change to project_issue to enable this setting (since I decided to have it default to FALSE):
http://drupalcode.org/project/project_issue.git/commit/28a1908
Calling this fixed (although if anyone wants to review the commits, that's lovely).
Thanks,
-Derek