New comments link is not being displayed on activity pages

What do you mean by Recent Content?

Bugfixes should be fixed against 8.0.x, IMHO

digging in

Not sure we can test this without JavaScript testing.
This bring tracker-history.js into line with node-new-comment-links.js

The bug is in tracker module code

Also history module related

I think the history callback should validate the arguments it gets too. Can't find it right now but there's a similar issue open for the nid being out of range.

You could manually trigger the PHP error here which isn't great (especially if load balancers take 5* errors as a sign to take nodes out of rotation).

I can't reproduce that on /activity/1 anymore
maybe something was fixed already? or that was some caching issue

Anyway something like the patch is needed with test coverage

Needs work for test coverage then.

Also if you convert this to do a loadMultiple($nids) as $node then you've solved the problem too. A node that can't be loaded will never go into the loop. And performance is better.

@Berdir I wanna to convert that to load multiple long ago, but each time that out of scope ;)

There's actually 3 problems here:
1) JS passed only node Ids - manager call will be broken (no idea how reproduce) so @larowlan patch makes sense but that's a front side
2) Nodes could have different comment fields (names of fields) so $node->{wrong_field_name} will throw this exception too
3) no check for access/existence of nodes (my patch) should be refactored to load multiple call.

+++ b/core/modules/tracker/js/tracker-history.js
@@ -105,7 +107,7 @@
-      data: {'node_ids[]': nodeIDs},
+      data: {'node_ids[]': nodeIDs, 'field_name': 'comment'},

request should carry field name for each node or group them

I think we need replace 'comment' with name of last comment field, but we have empty value last_comment_name in $node in tracker.pages.inc

+++ b/core/modules/comment/src/Controller/CommentController.php
@@ -325,7 +325,11 @@ public function renderNewCommentsNodeLinks(Request $request) {
     $field_name = $request->request->get('field_name');
+
     if (!isset($nids)) {
       throw new NotFoundHttpException();

+++ b/core/modules/tracker/js/tracker-history.js
@@ -105,7 +105,7 @@
+      data: {'node_ids[]': nodeIDs,'field_name': fieldName},

the field name could be different for each node and not only one

The proper controller code, JS side should be fixed like #14

1. +++ b/core/modules/tracker/js/tracker-history.js
   @@ -105,7 +105,7 @@
   -      data: {'node_ids[]': nodeIDs},
   +      data: {'node_ids[]': nodeIDs,'field_name': fieldName},
   

   pass a field_name is a requirement

2. +++ b/core/modules/tracker/tracker.pages.inc
   @@ -104,6 +105,7 @@ function tracker_page($account = NULL) {
   +          'data-history-node-last-comment-name' => 'comment',
   

   yep! but needs to check a views plugins as well, to properly fix all over

The comments on this issue confuse me because they almost seem to be about different bugs; can we update the issue summary with steps to reproduce this issue?

A similar issue with a similar patch is on #2915993: Adjust render_new_comments_node_links to fix issues. That covers another thing too which is related to the traversing of the siblings not coping very nicely with other themes. I think I'll try to make the other issue more into the traversing and leave this one for the missing field_name which is indeed a bug.

After further looking at this, the real reason behind this is actually what was first described on #2915993: Adjust render_new_comments_node_links to fix issues, at first I was going to keep both separated, but they are the same thing. I am gonna mark the other one duplicate and improve this one.

This will likely go to needs work quick enough, but at least to prompt for some reviews.

This fixes this issue as well as #2915993: Adjust render_new_comments_node_links to fix issues.

It's simple in a way. The one thing that it's not really looking for is for the odd case of a node having more than one comment field. The tracker pages take that into consideration to displaying the total comments, but gets a lot trickier fi we want to support that and the "new comment link". It's likely a bug larger and broader issue.

I'd say we try to get this in in the best shape possible and work on the wider issue further along the way, as this will at least make most installs actually work. I am surprised this hasn't come up more often. I guess the tracker module is not widely used?

Patch is for 8.6.x

jurgenhaas that did #2915993: Adjust render_new_comments_node_links to fix issues deserves credit too if this one moves forward.

This one is for D85, I need it on a project. The 8.6 doesn't apply because some code was moved from the bottom of the file to the top (or viceversa)

So, both patches applies to both branches. It's odd. I can't apply #31 to 8.5.x with patch -p1 but I do with git apply and I guess that's what jenkins is doing. composer-patches doesn't work though so I'll leave #34 for reference for the time being.

Thanks @hanoii for coordinating this with the what's now a duplicate issue #2915993: Adjust render_new_comments_node_links to fix issues. I will give this patch a try and report back on the success.

@hanoii I've tested the patch from #34 with Drupal 8.5.2 and can confirm that it is working just fine. Giving it a RTBC.

It still needs tests

patch #31 re-rolled for 8.6.x (da56eaa0ab40)

for tests

@andypost
(Sorry, my english is bad.)
So, Drupal 8 use two comment types by default: "Default comments" (comment) and "Comment_forum" (comment_forum), and use two comment field with the same name.
Article content type use "comment" comment type and forum topic content type use "comment_forum" comment type.
Therefore, if there are articles and forum posts in the tracker activity page, none of the solutions work.

See "Steps to reproduce" from the issue.

Drupal 8.8.x rerolled patch.

This extension is deprecated and scheduled for removal in Drupal 11.

This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

It will be moved to the contributed extension once the Drupal 11 branch is open.