I wonder whether D6 still accepts this sort of thing or not...

What I want to do: Remove the "Add new comment" link from node-teasers. Because I know that some would dislike such change, i propose to make it configurable.

Why I want it: The link to add a new comment directly from teaser is no-good for me (speaking of my real site) in both the cases:
--- Anonymous user see the notice "Login or register to post comments" on every teaser. Given that my frontpage shows 10 promoted teasers, and the notice in Czech translation is even longer than original ("Přihlašte se nebo zaregistrujte, abyste mohl psát komentáře"), it's spamming the frontpage a lot and looks silly. From theming perspective, there's also quite too much in the links area.
--- Authenticated user (with matching role obviously) see the "add new comment" link, which is senseless in my opinion: There's no point to encourage users to comment on nodes they didn't fully read yet. Commenting after reading only just the teaser is not a good thing, for quality of the posts. Additionaly, also this link is a little long, and might be considered as kind of spamming the frontpage (which I always prefer to keep clean of unnecessary items).

My patch: I just added the necessary condition, along with matching variable, and admin-settings form subpart, being careful to keep the style of already existing code. It removes only just the "add" link, other links (like comment counts) are not affected.

Additionally, I changed one comment, where it said "Main page: display the number of comments that have been posted." Actually that code-segment also handles the "add new comment" link, and applies to all teasers (including Category & Views lists and more), not only just "Main page".

CommentFileSizeAuthor
comment-add-link.patch1.88 KBJirkaRybka
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JirkaRybka’s picture

Version: 6.x-dev » 7.x-dev
Assigned: Unassigned » JirkaRybka
Status: Needs review » Needs work

Moving to 7.x, which is more adequate, setting "needs work" as the current patch is against 6.x and needs update as soon as some 7.x code exist, and assigning to myself, willing to do that update.

momper’s picture

hello

is this working for drupal 5.2 too? i have the same problem ... or is there a forum-thread to do this - i didn't find something ...

thanks and greetings
momper

JirkaRybka’s picture

Off-topic - Re: support question

The patch is basically not likely to apply on 5.x (I didn't try, though), but as far as I remember, the code is very similar in that branch, so the patch above might tell you what to do. As a quick hack, you don't even need to add variable and admin-setting, just remove the bit of code inside (here changed) condition (delete or comment-out). In the file modules/comment/comment.module, find the place where is if($teaser) followed by a comment about 'Main page', and half a screen down, remove the code:

       else {
          if ($node->comment == COMMENT_NODE_READ_WRITE) {
            if (user_access('post comments')) {
              $links['comment_add'] = array(
                'title' => t('Add new comment'),
                'href' => "comment/reply/$node->nid",
                'attributes' => array('title' => t('Add a new comment to this page.')),
                'fragment' => 'comment-form'
              );
            }
            else {
              $links['comment_forbidden']['title'] = theme('comment_post_forbidden', $node->nid);
            }
          }
        }

That should work, I've the same on my site currently. Don't forget to back-up the original file.

webchick’s picture

I'm pretty -1 to this change... it opens up a whole ball of wax of adding dozens of UI widgets here and there to do tiny things like this. Those node type settings screens are scary enough right now as it is...

This is basically what hook_link_alter is intended for. In fact, you could probably make a "hide_comment_links.module" that anyone interested in such a thing could download and use. Unless I'm missing something?

JirkaRybka’s picture

I would better like to get rid of that link completely, because it makes absolutely no sense IMO, and I believe most people would like to disable it (Just my opinion). This is usability issue (preventing Drupal from looking weird and confusing to end-user in general), not some "rarely needed override", and so it shouldn't require the user to seek contribs just to fix core issues. Also making a new module for every tiny UI improvement would be scary for maintenance/support/performance.

The proposed setting is NOT a node-type setting. It's a general setting for comment module, added to a page already containing a lot of other "choose then forget" settings (like comment controls above/below/above+below/nowhere, comment form below/extra page and so on), so it fits nicely there, I believe.

But however, I welcome discussion about whether the comment link on teasers is useful/nonsense, so we can then agree on where this issue will go: Remove link completely (my favorite), make it configurable (won't break anything, this is the current patch), or 'won't fix' (would force me to make that ridiculous module probably, although I'm inclined to say that I'll not for time matters support-wise).

More general note: Drupal IMO needs several UI (defaults) improvements for better look&feel out-of-box, the comment and forum modules being most affected. I think I even read somewhere recently, that the focus of D7 should be "improving user facing features" or like that. That's really necessary IMO, it'll be lots of tiny issues, and it's basically the way this issue was intended to go.

webchick’s picture

What is your alternative proposal as to how users add comments to a post, if the link is not in the teaser? Would all sites need to put the link in their node-X.tpl.php files, or..?

And actually, a "hide_links.module" would probably be very useful and pretty easy to do. I'd do it myself, but I'm notoriously bad at maintaining modules. :)

JirkaRybka’s picture

TEASER is the short two-sentences (or so) preview on frontpage, in category-overview and so on. Users should NOT comment after reading only these two sentences. They should click the title or "read more" link (or "xx new comments" or the like) to see full contents of the node first. I believe most users do so anyway.

FULL NODE is where users should comment, and my proposal/patch makes no change there, the link on full node is still there of course (or the comment form itself, if configured so).

The only questionable use case IMO is, whether some site uses so short node bodies, that the teaser shows the same as full node view. I think this is rare, but then (and only then) such a site might want to have the link even on teaser - that's why I propose it configurable (on site-wide level).

JirkaRybka’s picture

Thinking of it, I see that the 'questionable use case' mentioned above makes no sense, because the link in question only shows if there's no comment on the node yet; otherwise it's replaced with the comments count linked to the first existing comment. So, to sum it up:

- Current code floods the anonymously seen frontpage (first experience of a newcomer) with multiple occurences of the 'Login or register to post comments' notice under some (commonly seen) coditions. Ugly IMO.

- For authenticated users, it sometimes (but not always!) provides a shortcut link to post comments without actually visiting the node to be commented. That's wrong IMO and should be at least configurable (just like madatory preview is).

- If there are already comments on the node, the link (POSTING option) is replaced with comments count (VIEWING option), which is inconsistent IMO. This also makes it impossible to rely on this posting-link (if there is such use case, which I believe is rare), denying it's usability in common workflow anyway.

- If the link was meant just to encourage users to start commenting on uncommented-yet nodes (as the logic suggest), then it's wrong IMO again, because the node-viewing step should be mandatory BEFORE deciding to post a comment.

- This whole issue is ONLY about the frontpage and similar screens, and doesn't affect the usability of full-page node views in any way.

The solutions I propose (to choose one of):

- Remove the link completely, making node-view mandatory before commenting (plus cleaning up the frontpage)

- Make it configurable (current patch), means the above, plus possibility to keep previous behavior if wanted for some reason.

- (Adding new idea) Replace the link with a plain-text notice 'No comments yet' - so it'll show either a comments count linked to the first comment (already works), OR 'No comments yet' if that's the case. This would be consistent I believe.

Hope to hear more comments now.

JirkaRybka’s picture

Cross-linking another problem with comment-related links on nodes: http://drupal.org/node/137100 ("You can't post comments").

salvis’s picture

+1 to your proposal to completely remove the "Add new comment" link from teasers-only views.

I also agree with your comment about the UGLY 'Login or register to post comments' links. OTOH, some people seem intent to spam their front page, so it may be difficult to reach a consensus.

See also http://drupal.org/node/195161.

catch’s picture

I'd go for "no comments yet" then the link (as now) if there are any. Overall I agree with JirkaRybka's views on this.

misty3’s picture

@salvis ... many sites do have teaser=full node ( with no 'read more'), so add comment link is needed in such cases ... imho if it has to be there the configurable option is the best.

salvis’s picture

@misty3: yes, JirkaRybka is proposing to remove those links from node-teasers (see OP), and I'm supporting removing them from teasers-only views — two slightly different ways to say essentially the same thing.

I don't know how to activate teaser=full node, but it seems to be the exact opposite, and neither JirkaRybka nor I have suggested to remove the link in that case (at least not in this thread).

JirkaRybka’s picture

I think that #12 refers to some use case, which seems to me like a site full of *very* short nodes (with high teaser-length set), so that frontpage actually shows the whole text of exposed nodes, and users are not supposed to really click to visit the full nodes (which will show the same anyway). In this case, the links to post comments from such a full-featured frontpage make a bit of sense (although I might argue that people still need to visit the node, to read previously posted comments already in there - it all depends on the exact site/workflow, really). So this basically supports the originally proposed way of configurable behavior (unless I misunderstood something).

Richard Vallejo’s picture

I stumbled upon this looking for something sort of similar, and thought I'd throw a suggestion out...

I would really like to have greater control over the items generated by $links. On a site that I've been working on, we've got post information, taxonomy, comments, read more, spam links and view count (many of which are only visible specific user roles). It would be great if there was a way to rearrange these, drop them to the next line or hide altogether on the front page and similar pages.

Pancho’s picture

I fully agree with a variant of catch's proposal following this logic:

if teaser != full node ('Read more' link present):
* replace the "Add new comment" link by "No comments yet" on teaser-only views
* leave the "Add new comment" link on full page views

if teaser == full node ('Read more' link absent):
* if user may post a comment right now:
  > leave the "Add new comment" link on all views
* if user may not post a comment right now:
  > if authenticated user may post a comment:
    - leave "Login or register to post comments" link on all views.
  > if authenticated user may not post a comment:
    - replace the "Add new comment" link by "No comments yet" on all views

Though this might sound complicated, it is the most meaningful and intuitive solution for every case.

For now we should solve this issue for D6 (see #10).

JirkaRybka’s picture

#16: This sounds good :) I'm going to look into this again, after 7.x opens for development.

Sutharsan’s picture

Component: comment.module » usability

Moving all usability issues to Drupal - component usability.

ericjam’s picture

I'm a noob but I'm frustrated right now with how to selectively change how a node appears on different pages like Frontpage, different taxonomy sections, etc. Some might want a Comment field, some might want the Summary, some should not have the Author (Submitted). Views does not solve this and I have no idea how to use CCK. The "newspaper" example of the New Yorker Magazine is REALLY UNHELPFUL because they're like "oh look at us we just used CCK to do a whole bunch of crazy .php editing to achieve what we want" Great except its not that easy. The example makes it sound as if the entire site had to be hacked in order to achieve a "newspaper" functioning website as opposed to using the current conventions. There needs to be more options attached to editing content that doesn't exist today. I'm searching the boards endlessly for solutions that are not really helpful. It seems anytime I do one thing on one page, it opens a Pandora Box on another page. And the CSS also gets mixed in there.

JirkaRybka’s picture

Component: usability » comment.module
Assigned: JirkaRybka » Unassigned

Unassigning myself, there's no progress for long time, and my time is way too limited to provide any progress myself. Sorry about that.

ericjam’s picture

Status: Needs work » Postponed

Okay, back after six months, pretty expertized now. The comment display issue is rather solved by themeing with a proper knowledge of CSS and PHP. It's also helpful to start with a customized Theme that might already solve some of these issues for you. The Comment module shouldn't necessarily change, there's really nothing more it can do. I think what you are proposing (original poster) is for multiple options applied to different Comment views (in a sense). That's a bit of work so we should just leave this open as a potential feature.

My suggestion is to hire someone to customize to your specifications.

JirkaRybka’s picture

I know I can customize nearly anything (actually I did already on my site, seeing no progress here) - but that's exactly the downside of Drupal, that you need to do so where it shouldn't be required. It's all too easy to say "where the default behavior makes no sense, just go and customize", and leave the root of the problem unfixed, but this is why Drupal is so much difficult for newcomers, and time-consuming for the rest (especially when more such issues build up on the same page/site).

So I said - let's fix the default behavior, so that it makes more sense, and so needs less customizations. Of course, I got multiple replies along the lines "go customizing, go to contrib, go anywhere else than patching core" - I should've expected that. But that's not really about my point.

But all the same, I'm out of 7.x development now (I can't even install 7.x on my testing environment, as it's primarily a testing environment for live site changes, being kept in sync with the (hired) production server versions-wise, and so not satisfying the high requirements of 7.x. There's also lack of time in that etc.) So there's not much I can do for this anyway (so accepting 'postponed' unless someone else chip in).

salvis’s picture

Status: Postponed » Active

@fluidicmethod: why are you setting this to postponed?

We're not talking about theming and fine-tuning a specific site, but about fixing core so that an out-of-the-box teaser list can be made to look less embarrassing without hiring a consultant.

lindsayo’s picture

I completely agree. It should be easy to turn on and off the components of teasers.

So far, I just use Views to output a clean teaser list. I shouldn't have to, though. Should just be able to tick and untick teaser components in the edit content type page.

sun.core’s picture

Version: 7.x-dev » 8.x-dev
peterx’s picture

http://petermoulding.com/pet_remove_login_or_register_to_post_comments contains a Drupal 6 module to do what webchick suggested in #4.

salvis’s picture

@peterx: Please post your module on d.o.

Jay_Katari’s picture

Hi,

My name is Jay Katari & I'm agree with the quote of @amanuel, I think he say right, I had read all the comment but I noticed there is only few comment is relavent..

Thanks,
Jay katari

spineless’s picture

I would love to be able to turn off the comments on the teaser. I just want to advertise the node on the teaser. I do not want people to see the comment box until they read the entire node.

Can this be implemented in D7?

andypost’s picture

Suppose this kind of settings should be implemented in contrib so better to change branch to 9.x

andypost’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.