remove "you can't post comments"

This isn't a bug, it's by design. If you want to change this, just apply some theming. You can find enough information about that in the handbooks.

Hello Wim,

Your answer looks like a RTFM one... I have the same concern as Joachim. Can you give us more information on the book we are supposed to find solutions in.
For me it looks more like a setup aspect than a theme one...

Daniel

Could you please pastebin a rendered page where this happens? I cannot reproduce this in Garland. (I just need to know WHERE exactly this phrase shows up, though I think I know where, I want to be sure before posting an incorrect reply.)
Alternatively, you could just post the relevant element here, that would probably be sufficient too.

Any links provided by hook_link() can be overridden by implementing hook_link_alter(). If this isn't a link, you might have to do some theming/hacking as comment stuff is a bit hardcoded in D5-.

I don't know if this is your issue, but I ran into this too. I discovered that this "con't post comments" shows up when you remove permissions, rather than when you disable comments.

However, A combination of conflicting settings will give you this too, and it can be removed (in my circumstances). You a) need permission to administer comments, b) you need to edit and disable comments on all existing nodes that were created before you disabled comments for the content type in general.

In my case, what led me here was:
* I created a story node (say, node/15)
* I disabled comments on all content types, incl story (afterwards).
* I removed comment permissions on all users in access control
* I saw "can't post comments" on node/15, but nothing on other story nodes.

I had to give admin administer cmment permissions, go into node/15, and disable comments. As I said, all my subsequent story nodes did not have that "can't post comments" line, because they were created after commented was automatically disabled.

Again - your mileage may vary. But no hacking required on my site. :-)

G

Please forgive me, but I can't believe that this is by design.

This phrase shows up in place of the "Add new comment" link, when a content type has comments enabled but the logged in user does not have any comment permissions.

smokinggoat's solution in #5 may work if you disable comments, but I don't want to do that. Some specific roles should be able to use comments, and others shouldn't. But those others don't need to have the "you can't post comments" in their face all of the time, reminding them that they're lower class members.

It's inside

  <div class="links">
    <ul class="links inline">
      <li class="first last comment_forbidden">
        <span class="comment_forbidden">

Let's at least fix it for D6...

Just cross-linking issues, a little bit related: http://drupal.org/node/169938 Links on frontpage-teasers make no sense, somewhere. I think we need a cleanup in these links, rather than advanced theming required from everyone.

I think I'm beginning to understand the reason for putting the "you can't post comments" string where it is — it's a bad kludge implemented to fix a mis-feature.

Drupal puts up "Login or register to post comments" links in many places, even when it knows that logging in may not allow to post comments after all, because the authenticated user doesn't have the 'post comments' permission (see http://drupal.org/node/195161).

So, first we lie to the user, and when they go to the trouble to register (entrusting us their email address) and log in, we add "you can't post comments" at the bottom of every post to really rub it in that they fell into our trap.

What a way to treat your users...

Critical issues are only for those that result in completely broken functionality or that cause data loss. This particular functionality has been standard in Drupal since the dawn of time, therefore it's not critical.

subscribing to this. Would be better to disable the text completely rather than this message.

Well, as someone who searched on this because it is a critical issue, I couldn't disagree more with illogical statements like webchick's comment that the "functionality" has been standard in Drupal since the dawn of time...so it must be a good thing. That's the kind of attitude you see in the worst program managers at big software companies. I guess I will have to hack whatever it is that needs hacking to get this removed from the sites I'm working on. I'm reluctant to do that since part of the reason to use a CMS like Drupal is to have a code base that anyone can pick up and use.

@jonoMT - I didn't read any of this into webchick's reply. She gave the definition of a critical issue (which this doesn't meet) and marked the issue appropriately. Also, nowhere does she say that because this behavior has existed in multiple versions of Drupal, that it is a good thing.

If you're working on a solution for this issue, you should consider posting a patch back here for review and possible inclusion into the core. Then everyone benefits. That's also part of the reason to use a CMS like Drupal, community contributions.

Im tired of trying to work with wincvs, all i get is error after error and it doesn't work like i think it should. Someone is going to have to help me with cvs, because I just can't get it to work correctly. This is my idea to fix this module, someone create a patch for it, please.

Starting at line 1594 and ending on line 1615 in comment.module, replace function theme_comment_post_forbidden($node) with the following.

function theme_comment_post_forbidden($node) {
  global $user;
  if (!$user->uid) {
    // we cannot use drupal_get_destination() because these links sometimes appear on /node and taxo listing pages
    if (variable_get('comment_form_location_'. $node->type, COMMENT_FORM_SEPARATE_PAGE) == COMMENT_FORM_SEPARATE_PAGE) {
      $destination = "destination=". drupal_urlencode("comment/reply/$node->nid#comment-form");
    }
    else {
      $destination = "destination=". drupal_urlencode("node/$node->nid#comment-form");
    }

    // Need to retrieve post comment permissions for authenticated-user (rid = 2)
    $perm = db_result(db_query("SELECT p.perm FROM {role} r INNER JOIN {permission} p ON p.rid = r.rid WHERE r.rid = 2"));
    if (strpos($perm, 'post comments')) {
      if (variable_get('user_register', 1)) {
        return t('<a href="@login">Login</a> or <a href="@register">register</a> to post comments', array('@login' => url('user/login', array('query' => $destination)), '@register' => url('user/register', array('query' => $destination))));
      }
      else {
        return t('<a href="@login">Login</a> to post comments', array('@login' => url('user/login', array('query' => $destination))));
      }
    }
  }
}

This will get rid of the phrase "you can't post comments", no reason to let the person know that in my mind. Plus, this will check if authenticated-users can post comments. If so, it will show the phrase Login or register to post comments. If not, nothing will be returned, because they can't post comments by simply registering. Create an else if you believe something should still be returned.
The one drawback, is if there is any reason to leave 'post comments without approval' checked while 'post comments' is unchecked for the authenticated user, then this will still show the login or register to post comments.

Ok, here's your patch — works great for me, thanks!

(Your line numbers were a little off...)

I just realized a mistake I made, I took the query from another module, but I didn't need to keep the JOIN is the query. That line should actually be:

    $perm = db_result(db_query("SELECT perm FROM {permission} WHERE rid = 2"));

This will minimize the query. Sorry, kind of feel dumb that I left that line like that.

Plus, I am wondering if there is a reason that we should explode the result into an array, and then run the search through the array for the value "post comments". This will make the 'post comments without approval' unimportant for the query, however I believe it will cause a slight increase in memory usage. Hopefully, someone has a better idea to handle that permission in a more efficient matter.

It might we worth to examine, whether we should improve the permission-check for performance - a query inside theme function used multiple times on a typical frontpage is not nice. Perhaps store the check-result in a static variable?

That does make the most sense, then we could run the whole check outside the theme function, and just make a simple if inside the theme function. Don't really have time at the moment to look for the best possible location outside the theme, though.

This is also being discussed at http://drupal.org/node/195161

Not sure if you wanna just mark this as duplicate, since the other issue is much further along.

now committed. Marking this as duplicate http://drupal.org/node/195161