Nodes in panels are not marked as read

This isn't an APK bug. It's just the way panels works that nodes used as context in panels don't get marked as read. I don't know if anything can be done on the panels end to change this so it may get "won't fix'd" but I'll shoot it over there just in case.

Michelle

Marking as duplicate of #306232: When using nodeoverride nodes keep being flagged as having new content

Setting this back. This issue is related to that one but not a duplicate as that one is more narrow in focus. If anything, that should be marked as the duplicate as this issue is older and broader.

Michelle

grmpf... you could have updated the other issue, too, don't you? ;)

I was looking into this issue a bit, since it seems that whenever panels is accessing a node the last viewed timestamp is not updated. I have been looking at the latest release of Panels, and not the dev code, so I am sorry if my info doesn't fit.

In the node module there is a function which updates the timestamp of the node. It is called:

function node_tag_new($nid)

In the content_types/node_content.inc in function panels_content_node_content

Right after

  $node = isset($context->data) ? drupal_clone($context->data) : NULL;line: 49:

Insert the line:

$node->node_tag_new($node->nid);

Not sure is the cloned data actually makes it a node, and has the functions available from the node.module file. And no I haven't had the time to test it yet. I will do as soon as I get the time, unless someone beats me to it.

Okay, I have looked into the issue a little more and I have a patch that at least solves the problem in #306232: When using nodeoverride nodes keep being flagged as having new content. So I would like someone to test it on the original problem.

On line 49 in content_types/node_content.inc insert:

node_tag_new($node->nid);

I have attached a patch file as well. Can I get someone with the original problem to test the patch?

The problem is fixed by updating the 'last viewed' time when a panel includes a node.

/Kristian

I am not all that familier with the advanced profile. Is it including a node as a "node content" in the panel? In that case it really should work.

I don't know how you applied the patch, but one thing I noticed is that I go the path wrong in the .patch file.

If you are sure it is applied correctly, I will take another look at the problem.

Is it including a node as a "node content" in the panel?

Yes, but split up into fieldgroups.

Michelle

Totally OT, but you don't need custom PHP to load individual fields. You can add them the same way you add fieldgroups.

Michelle

My patch only works if you add a "node content" from the panels. If you load the node and then add individual fields as you describe, it will never be flagged as read.

Though if you add

node_tag_new($mynode->nid);

to the custom code, it should get unflagged I think.

I think I see the problem now, and it is a little more than just a code problem. The problem is to answer when the node is viewed. Is it when the body is showed, or is it when one or more of the additional fields are showed. And in that case how many fields should be showed before the node has been viewed.

If there is a way to tell whether or not a panel is a node override, we could flag the node as read whenever we access the node override, but what about additional nodes included in the panel then?

The solution I provided before marks the node as read whenever the body of the node is showed on a panel through adding the "node content" item to a panel, but I can see now that there might be other cases where you would consider a node read.

/Kristian

I have been thinking some more about this, and the problem is that I can't answer the question "When should a node be marked as read?". The problem is that people might want to do it in some cases and not in other, depening on what content they include from the node.

So I have been thinking about a solution, and my proposal is as follows: When you enter a context id and it is a node id, you get the choice "mark node as read when panel is shown". That means the administrator can choose to mark a page read or not depending on situation.

Since I am not all that familiar with drupal and the philosphy, so I could use some feedback this idea, and wheter it would be a viable solution. I should be able to make a patch for this, but I would like feedback first.

Notes:
It requires changes in: arguments/nid.inc, context/nid.inc
Maybe it will require changes in cck as well, since there is an option in the relationship category

Panels should assume that each time a node is successfully loaded, that node will be - partially or not - displayed.

nm me.

It seems to me that the problem may go a little deeper, but perhaps I'm mistaken.

I've set up a view to show me content types by "Page Hits". It seems that when I surf around the website with node override that the node counts do not go up.

I applied the patch in #16, but it seemed to have no effect on this, as I assumed it wouldn't as it was particular to the new issue.
Can someone let me know if the problem is related or if it's just something wrong on my part.

Caching is turned off, and all my content is showing 0 hits. I figure atleast ONE thing should have a hit, concidering I've visited it all myself over the last couple weeks from multiple usernames and browsers. However all were visited with a node override.

Any help would be appreciated as I can't make views based on hits, without it working.

#19 I don't think this is the same problem. Besides my number of views increase whenever I watch an overridden node. Does the count increase if you don't use panels?

/Kristian

Incrementing the node view counter/statistics is a different topic, please open a new issue if you found a bug related to Panels.

Thought about this some more and it's possible that the latest patch will mark too many nodes as read, because there is one certain pane configuration for a node content - an explicit teaser view - that should not mark a node as read.
However, we are not really able to indicate how a node context will be displayed (in advance). Even worse, it may even be possible that the same node context is output as a teaser AND as a full page view in the same panel. While certainly an edge-case, it would be a valid use-case.

Hence, before marking no node as read at all, I'd prefer to mark all loaded nodes as read.

@dtabach: The APK docs are old. The ability to add a single CCK field has been in for a while.

Michelle

I have tested the patch from #16 and it marks the node as read whenever it is loaded through an argument, directly or through cck reference fields.

I am sure you can still write custom code like the code showed in #10 that would avoid marking the node as read.

I think the status can be changed to tested, and be applied to the cvs.

/Kristian

Based on #24

Sorry, but this patch needs rethinking. As it stands, this patch works fine for the more common case of a node/% panel_page, but by hard-coding the mark-as-read functionality into the node context creation, we're enforcing that all cases of node context creation should result in a node being marked as read. There are legitimate cases - node contexts being generated through relationships - where this isn't the desired behavior.

I agree that the call to node_tag_new() needs to be in that function, but it needs to be called only if a configuration parameter is passed in explicitly telling it to do so. That'll mean expanding this patch to add form widgets to argument & relationship forms, as well as anything else that builds a node context.

I agree with sdboyer. Add a checkbox to the config.

Subscribe

With the release of Drupal 7, Drupal 5 is no longer supported.