I originally created a thread in the webmaster's queue for this here, however I realized I should just do it myself. So I'm re-posting here, and posting a new patch (that handles all code in this module, instead of a bluecheese override like I was originally considering).

There is an issue on the forums here on d.o in that posters regularly post threads in incorrect forums. Most of the forums have a thread explaining the purpose of that section of the forum, but posters still regularly post in the incorrect section of the forum.

I'm thinking that part of the problem may be the 'add new topic' link on the forum top page. Users come to the forum with a question, and click this link. In creating their new thread they need to select the forum, and do so with no guidance whatsoever as to what the various forums are for, as there is no indication on the forum taxonomy selector on the node/add/forum page. This of course is likely to leave them unsure as to which forum to choose, and as it happens, they often choose the wrong forum.

If this link were removed from the forum top page, users would then navigate to a forum to post their questions. In doing so, this would increase the likelihood of them reading the forum descriptions on the top page, and/or the forum description thread on the top of the various forum pages, increasing the likelihood of them posting in the correct forum.

Because users would be posting their threads directly from a forum, the forum selector can be hidden on the node/add/page. Instead, we can put a message telling them what forum they are posting in.

Of course, threads will still need to be moved, so the taxonomy selector should be shown when a forum topic is being edited. Just not on the initial creation.

I will attach a patch to the next post. This patch does three things:

1) Removes the 'Add new forum topic' link from the forum top page (in hook_preprocess_menu_local_action())
2) On initial node create, changes the taxonomy selector from #type 'select' to #type 'value' on the forum_node_form form (in hook_form_alter()).
3) On initial node create, creates a display element of #type 'markup', With the text 'Form: [form name]'. (in hook_form_alter()).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jaypan’s picture

Jaypan’s picture

Issue summary: View changes
Jaypan’s picture

Status: Active » Needs review
Jaypan’s picture

Re-rolling the patch with new method to remove add forum link - other method was causing an error when the theme layer was trying to render a non-existent element.

Jaypan’s picture

Note: I've applied the patch here: http://spam-drupal.redesign.devdrupal.org/forum

And you can see the taxonomy selector changes here: http://spam-drupal.redesign.devdrupal.org/node/add/forum/22

mgifford’s picture

Can you provide a screenshot? Also, the latest patch seems to have some of the code I added to improve the accessibility of the "report spam" link.

Jaypan’s picture

Ahh, you applied the patch from this post to my development site, and it got caught up in my patch. I've excluded it in the patch I'm attaching to this post.

Also adding three screenshots:

1) no-forum-link-on-top-page.png - This screenshot shows the now removed 'Add forum topic' link from the forum top page.
2) forum-pre-selected-when-creating-forum-topic.png - This screenshot shows the pre-selected, uneditable forum on the add forum topic page. This is determined by the section of the forum from which 'Add new forum topic' was clicked. Previously, the taxonomy selector was pre-selected, I have changed it to be text only.
3) forum-can-be-changed-when-editing-forum-topic.png - This shows that the forum section can be changed when a topic is edited. This allows for topics to be moved when necessary.

drumm’s picture

Status: Needs review » Needs work

The last chunk needs to follow Drupal coding standards, https://drupal.org/coding-standards, for indentation and keeping { on the same line.

Jaypan’s picture

Jaypan’s picture

Status: Needs work » Needs review
mgifford’s picture

Nice inline docs!

Jaypan’s picture

Thanks... any other reviews?

Jaypan’s picture

Assigned: Jaypan » Unassigned

Removing myself from the assignment in the hope that it will garner some attention for this issue.

mgifford’s picture

Issue tags: +Forum

Ok, I added it here http://search_api-drupal.redesign.devdrupal.org

Still looks the same here:
http://search_api-drupal.redesign.devdrupal.org/forum

Am I missing something?

Oh ya, the patch didn't apply, but that's just because the bottom of that file had changed (that could have been me or this platform). I just added drupalorg_preprocess_menu_local_action() to the bottom.

Jaypan’s picture

Am I missing something?

The missing link is only one part of it. When you create a topic, the forum is 'locked in' as it were and cannot be changed. When the topic is edited, the forum can be changed (see my screenshots that I attached).

mgifford’s picture

Ok, so I should create a forum in both and verify that I can change it with this patch.

We're removing the link right? Send me some URLs to go to on d.o for comparison.

Jaypan’s picture

Well the top link would be http://www.drupal.org/forum (the link exists on d.o. - it shouldn't with this patch)
Forum creation page: https://drupal.org/node/add/forum/22 (creates a page in the post installation forum. The forum is selectable on d.o., it's not selectable with this patch).

I can't give you an edit link, but there will be no difference between d.o. and the patch anyways - the forum should be selectable on both versions.

mgifford’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
203.39 KB
89.33 KB

I didn't change anything, but it seems to look fine now:

http://search_api-drupal.redesign.devdrupal.org/forum

http://search_api-drupal.redesign.devdrupal.org/node/add/forum/22

I'm going to mark this RTBC as it satisfies the ways I can think of testing it.

Jaypan’s picture

Great! We'll see if my hypothesis was correct now, and hopefully there will be a lot less posts needing to be moved to more appropriate forums.

Jaypan’s picture

Assigned: Unassigned » Jaypan
Status: Reviewed & tested by the community » Needs work

In applying this same fix for a client site, I've just realized two issues that need fixing:

1) The hyphens at the start of the forum topic need to be removed.
2) The node/add/forum page is still accessible if directly linked to. Access to this page needs to be revoked. This patch so far only removes the link to the page, but the page itself is still accessible.

I'm going to roll out another patch.

Jaypan’s picture

Status: Needs work » Needs review
FileSize
2.85 KB

Re-rolling patch with following two fixes:

1) Any whitespace and hyphens are removed from the front of the the forum name when creating a new forum topic.
2) Access to the node/add/forum page is denied. Users will need to access node/add/forum/ in order to create a new forum topic. This is inline with the "Add forum topic" links at the top of each forum, and the removed "Add forum topic" from the forum top page.

drumm’s picture

Status: Needs review » Needs work

I think drupalorg_preprocess_menu_local_action() needs to also remove the link when you are on a forum container, like https://drupal.org/node/add/forum/18.

The %@forum placeholder shouldn't have the extra @.

I don't quite understand the drupalorg_menu_alter() addition. SELECT * FROM menu_router WHERE path LIKE 'node/add/forum%'; shows there is only the one menu item for node/add/forum. I think we want to keep the access control on that, and double check that other restrictions are handles in form validation. Be sure to drush cc menu when changing menu code.

Jaypan’s picture

I don't quite understand the drupalorg_menu_alter() addition. SELECT * FROM menu_router WHERE path LIKE 'node/add/forum%'; shows there is only the one menu item for node/add/forum.

The whole point of this patch is to force users to create a forum topic from a forum, which will then preselect the topic. Simply removing the link to node/add/forum on the forum front page removes the link, but anyone directly can still directly access the page by entering the path into their browser.

The problem is that with this patch, the forum selector is disabled when creating a topic. If a user directly accesses node/add/forum, the forum topic is not selectable, and as no forum has been selected it causes issues. Therefore the node/add/forum page is unusable without a topic in addition. Leaving it open to access is bad user experience, as users may try to use the page and not understand why it is working.

That all said, there is a problem in that it entirely removes the ability to create a new forum topic, so I need to add a new menu item path at node/add/forum/% to fix this. I'll re-roll the patch with that change.

Jaypan’s picture

Status: Needs work » Needs review
FileSize
3.18 KB

Attaching new patch:

1) Added menu link for node/add/forum/%
2) Removed add forum link from container pages (nice catch Drumm)
3) Removed the @ symbol from %@forum placeholder

Jaypan’s picture

Assigned: Jaypan » Unassigned
drumm’s picture

Status: Needs review » Fixed
Issue tags: +needs drupal.org deployment

Committed http://drupalcode.org/project/drupalorg.git/commit/6118c15.

I made minor changes to the first 2 hunks:

  • Wrapped comments to 80 chars.
  • Added the text as a #suffix to the existing taxonomy_forums. This should use the weight from the field settings when we move fields around. (I don't think much, if any, thought went into the current field order. A separate issue can get them in a good order, and export as a Feature.)

I rewrote the final hunk to use hook_menu_local_tasks_alter(). This gets at the local action a bit earlier in the process. I also was able to use menu_get_object('forum_forum'), which is a bit better than arg().

Jaypan’s picture

Thanks! So what is the process from here? I know I don't have to do anything, but I'm not clear on what triggers deployment.

drumm’s picture

It will get deployed next time we deploy updated drupalorg code, probably in the next 24 hours. Since there are new functions, this needs a full cache clear. We can handle that, but it does noticeably slow down the site for a few minutes.

Jaypan’s picture

Thanks for the info.

drumm’s picture

Issue tags: -needs drupal.org deployment

Now deployed.

Jaypan’s picture

Thanks guys!

WorldFallz’s picture

This is awesome-- and I think will really help. Thanks jay, mike, and neil for pushing this through so quickly!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

  • Commit 6118c15 on 7.x-3.x, 7.x-3.x-dev authored by Jaypan, committed by drumm:
    [#2179705] Remove 'Add new forum topic' link from Forum top page
    
cptX’s picture

FileSize
51.44 KB

Isn't what I have marked in the picture a mistake?
If should use double ==

UPDATE: Sorry I had misunderstood the code.

Jaypan’s picture

No it’s not a mistake. It’s not doing a comparison. It’s assigning the value of arg(1) to $tid. If the value of $tid is zero or null, the if conditional is not entered. If the value is positive number, the conditional is entered.

cptX’s picture

Will this code work with alias? I'm trying to implement the same functionality for my forum

cptX’s picture

This is my implementation:

    if (arg(0) == 'forum') {
        if ($tid = arg(1)) {
            $forum_term = forum_forum_load($tid);
            if (!empty($forum_term->forums)) $variables['element'] = FALSE;
        }
    }

It's more simple and in my opinion makes more sense. Instead of looking if it is a container, I actually check if there are any more children forums under it. Only the last forum child doesn't have other forums under it at least in my implementation. If I use multiple nested containers and have forums only at the lowest level your implementation makes sense but if you have nested forums instead of nested containers it will not work. Actually in newer Drupal versions (eg 9) as far as I know you cannot nest containers. To my surprise in D7 you can nest them. I don't know what is recommended though.

Jaypan’s picture

If that's working for you, great.

This issue is specific to the codebase running this website (drupal.org), and it's been working for 7 years, so I don't expect there is a need to change the code. This issue wasn't opened up as an issue for the Drupal codebase, but rather as a specific solution on this site.

But you can definitely submit a patch if you'd like, and the infrastructure team will chime in on it.