HTML link 'Add new comment' should not be display on book printer-friendly page

Cross-linking #754760: "Add new comment" appears directly above comment form / "post comments" does not work without "access comments" permission

This is quite sad. I was just about to report the same issue. Just to find it is already 18 months old.

For those who want to know: retested with Drupal 7.0 on 27.03.11. (Drupal fresh from today).

Actually this was assigned to the wrong module.

The defect is in comment.module in comment_node_view

elseif ($view_mode != 'search_index' && $view_mode != 'search_result') {

Should also exclude the print mode. Actually this would like sabotage ANY attempt to export something using a print view.

elseif ($view_mode != 'search_index' && $view_mode != 'search_result' && $view_mode != 'print') {

did the job for me.

Ok, well ... one result of reading the Drupal Code of Conduct was: don't complain ... collaborate.

I attached a one-line patch that puts the 'print' view-mode to the exclusion-list for displaying links.

My own tests confirmed that this effectively cleans the add-comment link from the print-view export of the book type and likely will fix other print views as well. Such a link is no good in any print-view, right?

I hope I did things right, assigning this thing to me and putting the status to "needs_review", this is my first contribution, please don't flame if I messed or missed something.

Cheers, prefect

Whether this link should be shown in a print output or not actually depends on your use-case.

If you consider a site that renders the "add new comment" link in a special way in the theme, the print layout/design may break if the link is suddenly missing.

I really disagree. Really Really ;-). I hope my engaged argumentation below is not offensive, I am not a native english speaker. After writing this, I thought - funny - how much a simple two sentence disagreeing reply make me - slightly - go ballistic ;-) Don't take it wrong, usually I am quite relaxed ;-). So ...

1. Uselfulness ...

Print-reading: A print layout is for ... printing. As such a link is superfluous. It cannot be clicked on a printout and the imperative presentation of links in general does not add anything to the content, but disturbance. The only thing I could imagine is more useless in a printview than a link would be sound. If the link were functional, like being part of the text for reference or so. But the "add a comment" link is everything but this.

2. Themes ...

A theme that renders links even in a special way, rather than hiding them, would likely not be a print theme or supporting a print view properly.

E.g. the core book module resets the #theme before rendering especially to avoid such a misbehaviour.

Consequentially: either you have a theme-less print-view or a themed screen-view in whatever flavor. A themed print-view would be preferable, but honestly: it is not reflected in the core's book module, so does this exist, yet?

3. Consistency ...

From my point of view the way the book module treats this is core-behaviour and as such a model to adhere and even it it is just a work-around, at least it should be consistent.

While I am not aware of a simple number: how many themes are known to present a "print"-view, e.g. usable for printing a book? And how would the e.g. bypass the #theme reset in the book module?

(I really do not know! I just drilled myself into Drupal's code for this, done a few private modules, but core is new for me.)

4. Counter-test. What if ...

Let me take your side then: the links are disabled for two other view modes: teaser and some other. Wouldn't the same than be true for what you just remarked? Wouldn't then the theme have to decide wether or not to render the links e.g. for teasers. Why not adding comments with teasers, theoretically, this could be a very small button on a teaser, then? What I miss is the consequence of the thought on these things ;-)

5. The fine art?

Let me add one more question: as far as I know: rendering is transformation into HTML, isn't it? While theming is about to present what is (to be) rendered. Now how could a properly written theme fail on something that does not appear?!? Wouldn't a theme that shall cover print views as well have to take the view-mode into account properly? In other words: the theme is responsible for "how to present" and not "what to present", isn't it?

6. A matter of style?

All in all I would like to (admitted - a bit provocative) ask: why should we leave a core-defect untreated to hide a theme-defect? I don't see the sense in this.

7. Self-check

Make it simple:

try writing a book using the book module. One master node is enough. Three lines do the job. Add a comment. Display the print view. Look at the result and then reconsider you comment. 1.) The module is about books. Ever seen a link "please click here to add a comment" in a book you read? 2.) according to what the book-module shows the rendering should/could be done by the themes, but these apparantly seldomly support print-views, so a theme reset is performed. 3.) the ugly link cannot be dealt by the book-module as the comment module renders them.

8. Conclusion

If you still believe this is a good idea to have non-functional links, i.e. Drupal links as opposed to content links, in the print view, I cannot help it. I tried well, I believe. I did not go for this in order to start arguments, I just want to fix a problem. If this change is not finding its way to the core, I'll have to wait for somebody to write a better book-module or simply keep the patch for personal use. To me and the person who raise this issue 18 months ago ... it makes sense. ;-)

Again: I hope to have been insisting but not offending, we're all friends and maybe you smile a bit about this stubborn german ;-).

Kind regards,
Adrian, the prefect ;-)

And after I wrote the reply, I looked up who you are: ;-). Impressive!

If only you'd had written the book module as well, then things would fit again ;-). I still defend the case: Drupal-Links (i.e. non-functional links) in a content-print-view do not make sense.

What do you print out for? Others to read it! What do you want to print? Content, not Drupal! What would others think about me, handing them a printout looking like above attached png 2? "Adrian, you tried, but you messed it!" (Wie gewollt und nicht gekonnt!). And yes if the book module would render better, the theme could have code circumventing this. But I think this work-around in the book module is just displaying a problem in the comment module's behaviour. I really hope you give it a second thought! I understand now, it is "works as designed". My I then beg you to reconsider the design .. please? ;-).

I would not dare to give a printout like this to ... anybody ... sure no customer!

Would this be something for a configuration option of the module? I don't even think this. It would solve my problem, but nobody using book type or alike rendered print views would use it different from me ;-). It is really not depending on the use-case, I believe.

Cheers,
Adrian

I had to do an extra step to reproduce the issue: edit the book content type and disable the "Show reply form on the same page as comments".

It seems hiding the link from the print version should be the default. But as pointed by sun in #28, in some use cases this may not be the case. So why not set it in the css instead of php so a theme could easily override it.

The solution could then be as simple as setting a css properties on the "comment-add" class. Here is a patch for this specific approach.

Also setting it to 8.x version as patches need to go on the last version and are then backported.

Changing title back... stupid spammers.

#31: remove_add_comment_on_print-583576-31.patch queued for re-testing.

This problem is resolved for D8 in #2141929: Comment link or form is added to print view mode..
Apparently, this interesting debate was not noticed over there, and the dispute has been settled in favour of "go with the flow, follow what 'they' did with other view_modes" (See #23)

Although this issue is older and has more followers, I'm setting this one as a duplicate. The other issue is committed to D8, need backport to D7.