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()).
Comment | File | Size | Author |
---|---|---|---|
#35 | mistake.png | 51.44 KB | cptX |
#24 | drupalorg-remove_forum_link_from_top_page-2179705-24.patch | 3.18 KB | Jaypan |
#18 | create-topic-page.png | 89.33 KB | mgifford |
#18 | forum-page.png | 203.39 KB | mgifford |
#7 | no-forum-link-on-top-page.png | 115.57 KB | Jaypan |
Comments
Comment #1
Jaypan CreditAttribution: Jaypan commentedPatch attached
Comment #2
Jaypan CreditAttribution: Jaypan commentedComment #3
Jaypan CreditAttribution: Jaypan commentedComment #4
Jaypan CreditAttribution: Jaypan commentedRe-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.
Comment #5
Jaypan CreditAttribution: Jaypan commentedNote: 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
Comment #6
mgiffordCan 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.
Comment #7
Jaypan CreditAttribution: Jaypan commentedAhh, 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.
Comment #8
drummThe last chunk needs to follow Drupal coding standards, https://drupal.org/coding-standards, for indentation and keeping
{
on the same line.Comment #9
Jaypan CreditAttribution: Jaypan commentedRe-rolled following coding standards.
Comment #10
Jaypan CreditAttribution: Jaypan commentedComment #11
mgiffordNice inline docs!
Comment #12
Jaypan CreditAttribution: Jaypan commentedThanks... any other reviews?
Comment #13
Jaypan CreditAttribution: Jaypan commentedRemoving myself from the assignment in the hope that it will garner some attention for this issue.
Comment #14
mgiffordOk, 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.
Comment #15
Jaypan CreditAttribution: Jaypan commentedThe 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).
Comment #16
mgiffordOk, 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.
Comment #17
Jaypan CreditAttribution: Jaypan commentedWell 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.
Comment #18
mgiffordI 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.
Comment #19
Jaypan CreditAttribution: Jaypan commentedGreat! 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.
Comment #20
Jaypan CreditAttribution: Jaypan commentedIn 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.
Comment #21
Jaypan CreditAttribution: Jaypan commentedRe-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.
Comment #22
drummI 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 todrush cc menu
when changing menu code.Comment #23
Jaypan CreditAttribution: Jaypan commentedThe 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.
Comment #24
Jaypan CreditAttribution: Jaypan commentedAttaching 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
Comment #25
Jaypan CreditAttribution: Jaypan commentedComment #26
drummCommitted http://drupalcode.org/project/drupalorg.git/commit/6118c15.
I made minor changes to the first 2 hunks:
#suffix
to the existingtaxonomy_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 usemenu_get_object('forum_forum')
, which is a bit better thanarg()
.Comment #27
Jaypan CreditAttribution: Jaypan commentedThanks! 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.
Comment #28
drummIt 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.
Comment #29
Jaypan CreditAttribution: Jaypan commentedThanks for the info.
Comment #30
drummNow deployed.
Comment #31
Jaypan CreditAttribution: Jaypan commentedThanks guys!
Comment #32
WorldFallz CreditAttribution: WorldFallz commentedThis is awesome-- and I think will really help. Thanks jay, mike, and neil for pushing this through so quickly!
Comment #35
cptX CreditAttribution: cptX commentedIsn't what I have marked in the picture a mistake?
If should use double ==
UPDATE: Sorry I had misunderstood the code.
Comment #36
Jaypan CreditAttribution: Jaypan commentedNo 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.
Comment #37
cptX CreditAttribution: cptX commentedWill this code work with alias? I'm trying to implement the same functionality for my forum
Comment #38
cptX CreditAttribution: cptX commentedThis is my implementation:
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.
Comment #39
Jaypan CreditAttribution: Jaypan commentedIf 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.