Needed to prevent showing the last comment time when there wasn't any comments posted on the node. Drupal core adds the last_comment_time() as the node created time. So wrote a handler that adds in the comment_count field and checks it, and if there is no comments returns and empty string for the last comment time.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Scott Reynolds’s picture

sorry for the mix of source control. Couldn't for the life of me find a nice way to patch a new file against CVS without two checkouts. But both are unified patch format so they should apply

neclimdul’s picture

Makes some sense. Maybe the string could be an option defaulting to something like N/A or an empty string.

Also, adding new files is goofy with CVS. I've always done it by manually adding the lines to the Entries file.

merlinofchaos’s picture

Status: Needs review » Closed (won't fix)

I think this should be checkboxable. If for no other reason than it will change behavior that people have come to expect. It should be easy to add a checkbox to this (and the matching patches too)

Scott Reynolds’s picture

? afraid your going to have to convince me on that one. People expect a timestamp to be shown when no comment is posted?
Seems backwards to me.

Not sure that makes any sense. Usually show "last comment posted: 12/23/08" right next to "0 comments posted".

I can't think of a use case where that would line up? When would you want to show "last comment posted: 12/23/08" when there hasn't been any comments....

enlighten me.

merlinofchaos’s picture

Status: Closed (won't fix) » Needs work

Whoops I somehow set the wrong status earlier.

In forums, and some other systems, the distinction between the post and comments on the post is much less...well, distinct. In that case, it's thought of as a thread, and the post is just the first post in the thread...

This is why I'd prefer to allow the current behavior to continue. I feel quite sure (and this is partly instinct, partly experience) that if this change goes out, at least one person is going to complain that it broke their site somehow.

neclimdul’s picture

Without thinking to hard I know of one site I've worked on in the past that relied on this feature. +1 to the checkbox.

Scott Reynolds’s picture

Isn't that what: Node: Updated/commented date is for? That specific use case

Call me crazy :-D

Equ’s picture

Any progress?

welly’s picture

Just giving this a bump and adding my view on this one. It absolutely makes no sense at all to show a "last comment time" if there are no comments. I'm with Scott on this one. It's logically incorrect.

If there are no comments, there simply is no "last comment time". I'd wager that people who are relying on this functionality are probably misusing this.

I'm going to use Scott's patch for my site.

rschr’s picture

I second the question for any progress. Just tried to get last_comment_timestamp in a view for commented (and uncommented) articles using 6.x-2.8, but still no luck. I don't actually need it, but I would even use a checkbox ;-) Since the field is the node created time I can neither use "If the field contains the number zero, display the empty text instead" nor "Count the number 0 as empty - Hide if empty".

dawehner’s picture

Status: Needs work » Needs review
FileSize
2.01 KB

Here is a updated patch.

merlinofchaos’s picture

No need for the TODO. The "empty text" should allow the user to put in whatever text they like there.

rschr’s picture

Thanks merlinofchaos, I agree, that would be pretty cool. Of course there's always a good chance, that I'm missing something here, but since the field is not empty but filled with "created time" I can't use the "empty text", can't I?

Scott Reynolds’s picture

FileSize
2.35 KB

Removed the TODO.

Scott Reynolds’s picture

Status: Needs review » Needs work

ugg thats what i get for applying that blindly.

options_form() needs to call parent::options_form()

Scott Reynolds’s picture

It also do declare the additional fields in the $definition of the handler instead of in the construct method. I find that more declarative and leads to quicker understanding by other coders.

dawehner’s picture

Status: Needs work » Needs review
FileSize
1.57 KB
It also do declare the additional fields in the $definition of the handler instead of in the construct method. I find that more declarative and leads to quicker understanding by other coders.

I'm not sure about this one, but this propably be true.

I removed the extra setting, we have already: count zero as empty. This does exactly what we need, we just have to use it :)

merlinofchaos’s picture

Version: 6.x-2.x-dev » 7.x-3.x-dev
Status: Needs review » Patch (to be ported)

Committed to 6.x -- needs porting to 7.x

dawehner’s picture

Status: Patch (to be ported) » Fixed

And commited.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

rhymeswithcamera’s picture

This is the fix I was looking for. I see that this patch was committed in October, but is the code included in 6.x-2.12? If so, I don't see the patch's modifications. As a workaround, can I safely apply this patch to 6.x-2.12 or do I need to bump up to 6.x-2.x-dev? Thanks for your help.

DigitalFrontiersMedia’s picture

Issue summary: View changes

Just ran into this and while I respect Merlinofchaos' opinions in #5, I have to agree with others here that it's a lot of logical hoop-jumping to expect most people to understand that last_comment_timestamp is the same as node creation date unless you check a "count 0 as empty" checkbox....huh? o_O

I think Scott had this basically correct in his first patch. Not re-opening this issue but curious if someone wants to comment or act on if this should just be an issue posted against Comment module since it seems like that's where the issue really lies. (How did Views get saddled with this in the first place?) I mean, if it were fixed in comment, there wouldn't have been any discussion here of breaking people's sites and checkboxes.

If comment had an option to maintain the legacy behavior but provided a new default that actually made sense, wouldn't this be preferable? Is this worthy of posting (or better yet) re-assigning this discussion to the Core comment module?