Comment link or form is added to print view mode.

Let's get a test for this.

+++ b/core/modules/comment/comment.module
@@ -543,7 +543,7 @@ function comment_entity_view(EntityInterface $entity, EntityDisplay $display, $v
+      elseif ($view_mode != 'search_index' && $view_mode != 'search_result' && $view_mode != 'print') {

Ouch, this is becoming unwieldy. Can't the comment field just be removed from the display settings on the print view mode by the site builder?

Correct me if I'm wrong but the comment functionality isn't added to the book node type by default (ie when the book module is enabled) so the user would have had to add this field. Isn't setting the correct display settings part of that process?

Related #2114887: Maximum nesting level when attaching comment field to User.

What about 'Can't the comment field just be removed from the display settings on the print view mode by the site builder?'

Is there some way we could make this smarter? Because I'm finding we will need to add yet another exception to that line in comment.module in #1166114: Manage Displays Search Results doesn't manage the display of the search results.

It just seems stupid. We should have a better way to manage it.

Looks as good workaround with test!
Just a minor nitpicks

1. +++ b/core/modules/book/lib/Drupal/book/Tests/BookTest.php
   @@ -207,7 +211,7 @@ function checkBookNode(EntityInterface $node, $nodes, $previous = FALSE, $up = F
   +    $this->assertNoText('Add new comment', '"Add new comment" not found');
   

   Should be t('Add new comment')

2. +++ b/core/modules/comment/comment.module
   @@ -543,11 +543,15 @@ function comment_entity_view(EntityInterface $entity, EntityViewDisplayInterface
   +      elseif ($view_mode == 'search_index' || $view_mode == 'search_result' || $view_mode == 'print') {
   +        // We don't want this link if we're building the entity for:
   

   Suppose better to add 'continue;' here

Andy, what do you mean by "Suppose better to add 'continue;' here"?

Related issue on d.o waiting for this #2139847: Book printer friendly pages has 'Add Comment' all over

The proper fix should remove comment add form too.
@mgifford please check my grammar in comment formatter

PS: Working on test

It is
// We don't want this links if we're building the entity for:

It should be either (if plural links):
// We don't want these links if we're building the entity for:

or (if singular link):
// We don't want this link if we're building the entity for:

Small thing, but:
// display below the entity. Do not show the form for print view mode.

Should be capitalized:
// Display below the entity. Do not show the form for print view mode.

Changed code comments a bit, added test. Suppose RTBC

Assuming bot agrees.
I'm on record above saying I don't like that comment module is aware of search and print view modes, but this is existing in HEAD and this patch solves the issue in the OP, fixing the wider problem is out of scope.
We have existing issues to make the formatter more configurable and I'll try and pick them up again next week.

46: 2141929-comment-print-46.patch queued for re-testing.

46: 2141929-comment-print-46-fail.patch queued for re-testing.

46: 2141929-comment-print-46.patch queued for re-testing.

The comment was saved unpublished so run-tests is less affected leaking from host site, this should be fine after #2171683: Remove all Simpletest overrides and rely on native multi-site functionality instead
So now it works.

Back to RTBC

+1 RTBC as per #47

I noticed that this change:

+++ b/core/modules/comment/lib/Drupal/comment/Plugin/Field/FieldFormatter/CommentDefaultFormatter.php
@@ -143,8 +143,8 @@ public function viewElements(FieldItemListInterface $items) {
       }
 
       // Append comment form if the comments are open and the form is set to
-      // display below the entity.
-      if ($status == COMMENT_OPEN && $comment_settings['form_location'] == COMMENT_FORM_BELOW) {
+      // display below the entity. Do not show the form for the print view mode.
+      if ($status == COMMENT_OPEN && $comment_settings['form_location'] == COMMENT_FORM_BELOW && $this->viewMode != 'print') {

is only being made for print mode. Can't we also make this for search indexing and search results? It shouldn't be there either. See
#1113832: [PP-1] Comment module renders "reply" and other links in search index/results
which has this marked as a related issue. The other changes in this issue were made for all three, such as:

+++ b/core/modules/comment/comment.module
@@ -436,6 +436,13 @@ function comment_entity_view(EntityInterface $entity, EntityViewDisplayInterface
     //   http://drupal.org/node/1901110
     return;
   }
+  if ($view_mode == 'search_index' || $view_mode == 'search_result' || $view_mode == 'print') {

It would be great if this one could be too. Is it too late to revisit the patch?

A suggestion for a test for the search-related behavior:
- enable search module
- make sure anonymous users have permission to post comments (without approval) and search
- make a node on a content type with comments enabled
- run cron to index
- search for the word "reply". If you get a result, then the "reply" link was rendered in the search indexing step and it shouldn't have been.
- search for a word that is in the node body or node title. Verify that the word "reply" is not shown on the screen.

@jhodgdon
1) the formatter already checks search view modes just before the fixed code (see line 122)
!in_array($this->viewMode, array('search_result', 'search_index'))) {
and formatter's purpose to display "comment thread and form", so current patch hides the form

2) this is a fix amd a bit of optimization, suppose this covers the issue #1113832: [PP-1] Comment module renders "reply" and other links in search index/results

So patch does not need any changes, also it makes sense to add the test in following issue

re-order patches

RE #67, oh, right, I see that... well we can work on the test in the other issue and see if it's still a problem after this patch, which I think will not fix the other issue.

The problem on that other issue is actually that the reply link is shown during search indexing and search results display, which is not affected by this patch, I think.

So... Let's step back a moment and think about this really kind of kludgy code.

Field formatters can have settings.

So wouldn't it be more sensible rather than special-casing the search_index, search_results, and print display modes, to have settings in the Comment field formatter that say things like:
- If this setting is FALSE, skip rendering the comment form
- If this other setting is FALSE, skip rendering the "add" and "reply" links

This would allow us to remove the ad-hoc code in both of these places... just a thought, but maybe coming too late.

OK I agree this is messy but also that it's OK to fix it with workaround + tests then follow-up with the refactoring. We likely won't be able to backport the refactoring.

Committed/pushed to 8.x, moving to 7.x for backport.

I've marked [#583576s] as a duplicate.
Patch #61 is a D8-patch and needs backporting.