I've a view of blog posts with the "Node: Has new content" field, set to output as a link.
In some cases this is output as a link to "node" instead of "node/nid".

I'm finding this hard to reproduce, as on my site it's intermittent -- seems to be showing for registered users but not the admin user, which makes no sense.

The code that makes the link is in views_handler_field_node.inc render_link():

      $this->options['alter']['path'] = "node/" . $values->{$this->aliases['nid']};

Debug output shows that:
- $this->aliases['nid'] is history_user_nid, which is correct
- $values->history_user_nid is empty.

history_user_timestamp is also empty, which suggests looking at the query that the join to history_user got no results:

	

SELECT node.nid AS nid,
   node.title AS node_title,
   node_revisions.teaser AS node_revisions_teaser,
   node_revisions.format AS node_revisions_format,
   history_user.timestamp AS history_user_timestamp,
   history_user.nid AS history_user_nid,
   node.created AS node_created,
   node.changed AS node_changed,
   node_comment_statistics.last_comment_timestamp AS node_comment_statistics_last_comment_timestamp,
   node.sticky AS node_sticky
 FROM node node 
 LEFT JOIN node_revisions node_revisions ON node.vid = node_revisions.vid
 LEFT JOIN history history_user ON node.nid = history_user.nid AND history_user.uid = ***CURRENT_USER***
 LEFT JOIN node_comment_statistics node_comment_statistics ON node.nid = node_comment_statistics.nid
 WHERE (node.status <> 0) AND (node.type in ('blog'))
   ORDER BY node_sticky DESC, node_created DESC

So if there's no history for the current user, why is the field showing?
I wondered if this might be the same problem as http://drupal.org/node/408414, but changing the order of the nodes in the view so the one with the updated mark came first instead of last didn't change the outcome.

CommentFileSizeAuthor
#2 views_418230-2.patch702 bytesScott Reynolds
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joachim’s picture

OK, I suspect this is the problem in views_handler_field_history_user_timestamp:

      elseif ($last_comment > $last_read && $last_comment > NODE_NEW_LIMIT) {
        $mark = MARK_UPDATED;
      }

Suppose the user has not yet looked at the node: $last_read will be NULL.
Suppose that there is a comment on the node: $last_comment will be a timestamp.
Suppose also that $last_comment is greater than NODE_NEW_LIMIT.

The condition thus succeeds, because any timestamp is greater than NULL. $mark is set. However, when we get to the render link stage, there is no history_user_nid value, since there was nothing in the history table to join onto, because the current user has not read the node.

I am not sure how to suggest fixing this.

option 1:
Check the user has actually read the node before, and if not, skip it like this:

      elseif ($last_read && $last_comment > $last_read && $last_comment > NODE_NEW_LIMIT) {
        $mark = MARK_UPDATED;
      }

This is technically correct, as if the user has never looked at the node, it's not been updated from their POV even if there are new comments.
I can confirm that this works on my case -- the updated field is not shown for the registered user who has not yet looked at that node.

option 2:
spoof in the nid in $values->history_user_nid. The problem though is getting it -- in my view I have $values->nid, but if this field were added via a relationship I suspect that might be different.

Scott Reynolds’s picture

Version: 6.x-2.3 » 6.x-3.x-dev
Status: Active » Needs review
FileSize
702 bytes

way easier then that. This is rolled against Views 3. Should work on Views2 as well.

It does try to add the alias, the problem is views_handler_field_node expects itself to only be applied to the node Views data table but in this case its applied to history_user.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Patch makes sense

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

Committed to all branches. Thanks!

Status: Fixed » Closed (fixed)

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