'Login to post new content in the forum' button assumes auth users have permission to post

I am experiencing the same thing. I'd like to know how to remove those words. I have a view only forums that I don't want visitors trying to login to. Is there a simple solution that I'm missing here?

In file advanced_forum/includes/core-overrides.inc you must commented lines 411–422

/* if (empty($forum_types)) {
// The user is logged-in; but denied access to create any new forum content type.
if ($user->uid) {
$forum_types['disallowed'] = array('title' => t('You are not allowed to post new content in forum.'));
}
// The user is not logged-in; and denied access to create any new forum content type.
else {
$forum_types['login'] = array(
'title' => t('Login to post new content in forum.', array('@login' => url('user/login', array('query' => drupal_get_destination())))),
'html' => TRUE);
}
} */

This is the trick for your request.

Thanks for the reply. First thing I noticed was your reference to "advanced_forum" which I'm not using. But I took your idea and looked for the code that would be putting that text in there with the hopes of following the same principle. However, I couldn't find anything like it. Thus, not sure here. I next installed advanced_forum (and the other necessary modules that goes along with it), but turns out that the advanced_forum didn't give me any look that i wanted for the site. Thus, I removed those modules. Where in the "core"??? forum module would I change it so that annony users wouldn't have the invitation to log-in and post comments? thanks in advance.

I am sorry. I was solving the same problem in advanced forum and I didn't realise you think just core forum module.

So in file forum/forum.module look for lines 679–688 and comment them like above.

"if (empty($forum_types)) {..."

Just a note: in Drupal 7 (version 7.8) the "Log in to post new content in the forum." message is on line #201 of modules/forum/forum.module

of course that could always change so just search for it.

This to get fixed in 8.x then backported

The permissions for the forum module are not granular enough to allow this functionality. This is unfortunate because it is clearly misleading.

I am marking this issue closed.

What happens if it's more complicated than just the authenticated user? Eg a specific role is required?

The core forum module doesn't allow you to set a forum as 'read-only'. As a result you can't be sure whether a user could post to the forum.

You need to display the link in case the user (when logged in) is able to post to the forum. Otherwise they will be looking for a way to log in.

I see Pat Redmond's point in #11 though as it related to #9. Let's say that only users with role foo can post to the forum. There's no way to know if an anonymous user is going to have the foo role when they log in, so its impossible to tell if logging in will or will not give an anonymous user the right to post.

For the specific case of authenticated users not being allowed to post, we probably should drop the the log in link since all users won't be able to post, regardless of any other roles. Right?

I'll put together a patch.

Not sure if this is the best approach. Is the authenticated user role always 2? Are there other permissions to check besides 'create forum content'? Is there a faster or simpler way of determining if authenticated users have the forum creation permission?

Please review.

With core forum there are the following configurations:

a) Anonymous users can post in the forum
or
b) Users must login to post in the forum
there is no
c) Anonymous users and authenticated users cannot post in the forum - if so what's the point of a forum - no-one can post in it!

Yes I know you can have a role that does allow posting (eg 'Forum user') but before the user logs in you can't ascertain whether or not they have this role and hence can't decide whether or not to show the link.

If the issue here is with other contrib modules that control forum access then we should be approaching this from a theming/override angle to ensure that themers/contrib modules can remove these links on a site-by-site specific use case - the kind of places where the role configuration is pre-known.

The link itself is added in hook_menu_local_tasks_alter which any other module is welcome to override and remove.
The said module would also have to implement hook_module_implements_alter to ensure it ran after forum module or hook_install to set it's module weight in the system table lower than that of forum or worst case scenario, give it a machine name that comes after 'forum' in the alphabet!

I think we can close this once and for all. The default behaviour meets most use cases and the specific behaviour requested can be achieved with a contrib/custom module.

I agree with #17 and #18, if a module wants to remove the link, its not a difficult thing to do using hook_menu_local_tasks_alter or through any number of theme-layer ways of hiding it. And if we're 100% sure that no one can post to a forum, then we shouldn't say that logging in will allow them to. This is a fix up of the patch from #14 that failed.

In this patch:
If authenticated users don't have permissions to add forum posts, no "login to post" link is shown.
If authenticated users in general don't have permissions to add forum posts, but a specific role does, no "login to post" link is shown. This may be the only option as there's no way to tell if the user will have the role that allows them to post once they've logged in. We could have it display something like "logging in MAY allow you to post on this forum" in this case.

Thanks @mkadin. #19 looks like a reasonable solution to me, although it sounds like not everyone is convinced this is a desirable change?

Few minor points for code style cleanup:

1. +++ b/core/modules/forum/forum.moduleundefined
   @@ -195,15 +195,19 @@ function forum_menu_local_tasks_alter(&$data, $router_item, $root_path) {
   +          // Check if Authenticated users do have access.  If they do,
   +          // provide a message suggesting login.
   

   Couple minor things here; the comment is wrapping a little too early, there's an extra space after the period, and "Authenticated" does not need to be capitalized. I'd suggest:
   // If authenticated users may post new topic, provide a login link.

2. +++ b/core/modules/forum/forum.moduleundefined
   @@ -195,15 +195,19 @@ function forum_menu_local_tasks_alter(&$data, $router_item, $root_path) {
   +          $authenticated_perms=user_role_permissions(array('2'=>'authenticated user'));
   +          if (array_key_exists('create forum content',$authenticated_perms[2])) {
   +            $links['login'] = array(
   

   We should have spaces around = and after , generally. Reference: http://drupal.org/coding-standards#functcall

   Also, we should be using the constant DRUPAL_AUTHENTICATED_RID rather than the magic-numbery 2.

Also, we should add an automated test for this if we do add it. Finally, I'm on the fence as to whether this change is backportable... it does change the behavior a bit, and existing modules or themes might expect the link to be there for some reason.

Thanks for the review xjm, I've made the style changes, but am holding off on writing the test until we're sure this is what we want to implement. Style-corrected-patch attached.

Thanks for the cleanup! Easier to read now. :)

Tagging (since any fix will need tests). Not sure how I missed it earlier.

Adding tag "dlatino" for reference of the Drupal Latino community.

This patch works for me. Let's move on.

As per comment at #26

Thanks! However, this still needs tests. See #23.

I've rerolled the patch with the DRUPAL_AUTHENTICATED_RID references and added the tests.

I added the test in its own file since I wasn't quite sure if it belongs in one of the existing test files. I couldn't create a forum topic without creating a user either so that is part of the test.

I meant to upload the test-only patch first as described here http://drupal.org/node/1468170#steps

Uploading both into same comment with updated file names.

Ok, wondering if setting this to needs review will trigger the automated tests.

I tested it out and it looks great.

Looks good to me. The patch accomplishes its stated purpose and all Forum tests still pass after it is applied.

Don't want to muddy the waters but at Capital Camp in DC and backported this patch and test into Drupal 7. Attached as a zip for now.

Rerolled to fix the indentation. No non-space characters were changed by this.

Updated the following:
In forum.module - updated array_key_exists to use isset. This was brought up at MWDS.
In ForumAnonymousTest.php - made changes to adhere to coding standards and updated documentation.
I've attached an interdiff for more details.

Steps to reproduce/confirm that patch is working:
1. Fresh-install d8-standard
2. Enable forum module
3. Create test user with authenticated role
4. As anonymous user, go to forum/1 - Prompt to login is in place, which is incorrect (by default, there's no permission to create new topics
5. Apply patch
6. As anonymous user, go to forum/1 - Prompt has gone
7. Give create forum content permission to authenticated user
8. As anonymous user, go to forum/1 - Prompt is back

I RTBC that, since patch is pretty straightforward

We have a similar check in comment module, but it's done differently:

  // Since this is expensive to compute, we cache it so that a page with many
  // comments only has to query the database once for all the links.
  $authenticated_post_comments = &drupal_static(__FUNCTION__, NULL);

  if (!$user->uid) {
    if (!isset($authenticated_post_comments)) {
      // We only output a link if we are certain that users will get permission
      // to post comments by logging in.
      $comment_roles = user_roles(TRUE, 'post comments');
      $authenticated_post_comments = isset($comment_roles[DRUPAL_AUTHENTICATED_RID]);
    }

It'd be good to do the following:

- find out which of these is the most performant, we could possibly even remove one of the ways of getting this information.
- move this logic to a helper in user module so that other modules can use it. Something like user_role_has_permission($role, $permission)?

#38: drupal-953214-38.patch queued for re-testing.

#38: drupal-953214-38.patch queued for re-testing.

Applied patch #38: drupal-953214-38.patch using steps from comment 39 and patch worked as expected.

#45: well, test bot apparently thinks different :)

I just tested it manually, and it worked. Failures found by test bot should be addressed. :)

Hi there,

first, there was a problem with the anonymous test. in d8 the setUp method does not need the modules, they are given in a static variable
second, I implemented the stuff mention in post #40 by catch

writing the user_role_has_permission method I realized 2 things:

• just to pass the rid is enough, although the user_role_permissions method asks for rid => name it never uses the name
• would it make sense to take as first parameter an array of rids?

greets ifux

grrr, revert problem

If the patch in http://drupal.org/node/1853072#comment-6813072 is applied this patch will not apply cleanly. Without the other issue patch applied this patch does apply cleanly. I think these issues are somewhat related because they deal with the same button and how it reacts to anonymous users.

I tried to apply this patch, but it did not work on a recent core.
I tried rebasing, but had to solve some conflicts manually.
This might need some testing/review as it is my first reroll.

Got merge conflict out of file that caused fail.

Updated issue summary

1. +++ b/core/modules/forum/forum.install
   @@ -13,10 +13,33 @@
   +  variable_set('node_options_forum', array('status'));
   

   variable_set() function was deprricated.
   The correct function now is \Drupal\Core\Config::set()

2. +++ b/core/modules/forum/forum.module
   @@ -555,6 +498,135 @@ function forum_form_node_form_alter(&$form, &$form_state, $form_id) {
   +      global $user;
   

   The global $user was deprecated.
   Please use Drupal::currentUser().

We have found lines with much more char than 80 character limit.

#56: forum_access_messages-1853072-18-953214-56.patch queued for re-testing.

This patch resolves Login link issue for Forums.

I used @catch suggestion at #40 and added user_role_has_permission($rid, $permission) in user module.

I also made changes in comment module to use user_role_has_permission instead of user_roles which IMO seems more performant then user_roles which is currently being used in comment module. user_roles uses join query while user_role_permissions uses query without join.

cheers

Updated issue summary.

Attached are screenshots. Even though #1853072: Remove forum_menu_local_tasks_alter() hack and instead add links in ForumController::build is still in progress, so this should be RTBC.

Anonymous

Authenticated

Adding information about submitted patch based on #40 proposed resolution.

+++ b/core/modules/user/user.module
@@ -2026,3 +2026,20 @@ function user_logout() {
+function user_role_has_permission($rid, $permission) {
+  // Get permissions of role given by ID.
+  $perms = user_role_permissions(array($rid => $rid));
+  // Returns TRUE if the role has the requested permission.
+  return in_array($permission, $perms[$rid]);
+}

I think we should just replace calls to this function with

user_role_load(DRUPAL_AUTHENTICATED_RID)->hasPermission('WHATEVER THE PERMISSION')

Addressing comments in #68

+++ b/core/modules/comment/comment.module
@@ -1536,8 +1536,7 @@ function theme_comment_post_forbidden($variables) {
+      $authenticated_post_comments = user_role_has_permission(DRUPAL_AUTHENTICATED_RID, 'post comments');

Need to change this to - this now references an function that does not exist

Plus where are the tests

So I just did a thorough review of the entire issue. I don't think that the solution proposed will actually work. What if authenticated user role doesn't have permission to post to a forum or post a comment? What if that is reserved to a power user role? We'd effectively remove a login link. This really should be resolved, either through contrib theming or post user login and give an appropriate message. I haven't checked, is such a message currently available?

And if we agree that the link should remain visible, then we should make sure that comment and forum are in sync. Currently comment checks that the authenticated role has the permission while forum always prints the login link.

Hmm, I see your logic. What if we don't display a login URL at all, ever? And leave it to contrib modules/themes to add as they see fit? Most sites I build these days have a handy login link in the top right corner of the site making the additional login link semi-redundant.

C. Provide a message to users that they do not have access to post.

Can someone briefly summarize the best way to remove this "Login to post new content in the forum." link?

I need to make my site static, and that link is interfering with making a static copy (see https://www.drupal.org/node/27882 for steps that normally work, only the Forum module is a problem).

Since I'm doing this to create a static copy, any simple method, even if it is hacking code, would work, and I suspect one of the comments above has the answer, just wondering if there is something very simple possible here.

hook_menu_local_actions_alter would be my guess

[deleted - wrong post]
Moved to Comment: Creating a static archive

I don't understand "option C". If the theory was to display a message (drupal_set_message-style) after logging in saying, "oh, sorry, you still can't post", I don't see how that works. Just because a person logs in from a page where comments exist does not mean they logged in "with the intention" of posting a comment.

Insofar as standard basic behaviour is concerned, I'd be inclined to remove this message from forum and comment, or make its presence configurable on the admin side so that it can be enabled on sites where that makes logical sense but turned off on sites where it does not. In the majority of my development sites, "does not" has fit the bill, but there are exceptions.

The reality is that neither module could know in advance whether logging in will be sufficient to do the job. Even relying on the "authenticated user" role might not be enough, given the possibility of that being overridden somewhere along the way.

Fundamentally, I can't imagine that on MOST sites, this would be "the only way" or the only "obvious" way to log in in the first place. This is particularly true if only 'super users' have the permission in any event. Those 'super users' probably don't desperately need the handy login link.

I am removing the Novice tag from this issue because:

Avoid issues that are:
...
long, because they can be overwhelming
contentious or lacking consensus

I’m using this documentation as a source: https://www.drupal.org/core-mentoring/novice-tasks#avoid

Been thinking about this and I agree with #73 that this should just be removed. Core doesn't have any other specific calls to action like this for anonymous users, and I can see why it existed, but it just doesn't make sense anymore.

If you want to add a call to action to your site you can do it in any number of ways - just did it with a custom block in about 30 seconds:

Even with the permissions check there is no reason for this to be in core.

Forum is approved for removal. See #1898812: [policy] Deprecate forum module 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.

Just updating to say this can be moved once the removal of forum is committed to 11.x. It has not yet been done.