Better method of showing forum containers in form

Next patch does it for whole taxonomy: http://drupal.org/node/18647
It solves problem for 4.5-forum module also.

Do you think so? I haven't seen it. This feature would make a lot of sense.

We don't do this because optgroups cannot be nested.

How about using the HTML "disabled" attribute for the options when they are containers?

Let's try this title then.

See attached screenshot. It's not at all clear until I've already submitted the form and get a big lousy error that "General" is not one of the forums I can post to in the attached screenshot (and actually, it ought to only highlight the forum container selection too, but that's another thing :P).

Steven's right that it's invalid XHTML to nest <optgroup>s, and it's fully possible (and desired) to have the ability to have nested containers. So that's not a catch-all solution. However, they'd certainly work for forum vocabularies with an un-nested hierarchy, which is what we've got at drupal.org.

PHPBB handles this by only showing you the "New topic" link when you're in a forum context, not when you're in a forum container (or "other") context. I'm not sure if that would really work with Drupal, since it would run counter to the way that the node system blurts out all of the node types at node/add, but it would certainly do a lot to eliminate confusion if the select box was removed entirely.

Or, perhaps there's an even better solution someone can come up with that remains XHTML compliant but yet prevents users from selecting forum containers accidentally. I've made this into a DROP task in the hopes that someone might take a look at this long-buried but hugely important usability issue with our forums.

Guess it's assigned to me now, because I claimed the task through the DROP tracker.

OK, here are two mockups I created. They're mockups because I'm not sure how to implement them using the forms API. To view them, simply extract the archive, click "mockups.html", and you'll get a page where you can select one of two mockups (or, you can just go into the mockups directory and click either mockup1.html or mockup2.html). You'll get a bit more info about what they do and how it's done. Because they're just mockups, they may have a couple of bugs.

Here's what the mockups do in a nutshell:

Mockup 1 simply uses the "disabled" attribute for options when they are containers, like spydor suggested above.

Mockup 2 (completely my idea) uses JavaScript to display an error message when a user selects an option that is a container. It also disables the submit buttons (so the user has to select a forum before he can continue).

A third idea I have is a "column view" kind of thing, kind of like in Mac OS X's finder (screenshot: http://upload.wikimedia.org/wikipedia/en/3/33/ColumnBrowseInOSX10.2.8.jpg), where containers could be the "folders". You'd have to use JavaScript for this one; if somebody could somehow extract the forum hierarchy from the existing drop-down box, it could degrade gracefully into the regular drop-down box if JavaScript were not available. I couldn't really mock it up by myself, though.

Holy cow!! And the best mockup of the year award goes to... :)

My only complaint is that I can't tell what either of these do (particularly the first one) when JS is disabled, nor can I view the source of the pages to see what the markup looks like.

How do these examples degrade? Do they basically just look like the screenshot above?

Even though that swooshy error thing is pretty awesome, I still am personally more +1 for the simple one that just prevents you from selecting containers altogether. The only catch is, how does it deal with nested containers?

Yeah the disabled thing (mockup 1) works nice. I'm also not sure how this'll work for nested containers (you can have containers within forums within containers ad infinitum).

Mockup 1 seems to be the more elegant of the two.

Although with nested containers it's a little disconcerting to have your selection skip more than one entry at a time when you have a structure like this:

Container
-Forum
Container
-Container
--Forum

The Finder style drill-down interface was investigated for core http://drupal.org/node/191360, and it looks like DVessel took a different approach with his Lumen theme http://drupal.org/project/lumen and the way it handles navigation http://si-lumen.us/api

You may also wish to look at Wim Leers Hiearchical Select module http://drupal.org/project/hierarchical_select

Mockup 1 is the better one IMO, although it should be made semantically accurate. A container is better described in HTML as an optgroup than with classes and disabled elements, thus:

<option selected="selected" value="">- Please choose -</option>
<optgroup label="This is a container">
<option value="1">-This is a forum</option>
</optgroup>
<optgroup label="Food">
<option value="2">-Fruit</option>
<option value="3">-More fruit</option>
</optgroup>
</select>

Amazing mockups by the way. Excellent work!

*** EDIT ***
Although, as brightloudnoise mentioned above the problem with any approach of this type is nested containers. Doing this with optgroups is a problem as the optgroup tag cannot be nested. :(

Wow, so many responses. I'm working on improving the mockups right now.

I think Hierarchical Select is a perfect fit for this. You would enable the "enforce_deepest" option and that's that: all finished. You can try this in Drupal 5 right now: just download & install HS, enable it for your forum vocabulary and configure it as I just described.
Since a container always contains forums (I'm not sure this is enforced, but an empty container should not be displayed as an option anyway), by enforcing the user to select an item from the deepest level obviously also enforces the user to select a forum.

For the Drupal 6 version of HS (not yet available), I'll implement those scalability improvements as well (chx contacted me to make sure I knew about it).

However, I *think* that HS is out-of-scope for Drupal core? It's quite big internally and the only way the amount of code can be reduced, is to limit the number of supported features. Nobody wants that, so I doubt HS will qualify anytime soon.

Wim Leers: 'Enforce deepest' wouldn't work in this case - you can have a forum within a forum within a forum, and you'd never be able to select the parent forum. Unless I've misunderstood?

There's a few similar hierarchical select forms in core where HS would be an applicable solution. If it can fix all those places then it might well be worth the lines of code.

* hierarchical taxonomy vocabularies (forums are a subset of this), on the node/add and term edit screens. These have performance implications at the moment in addition to usability woes with large vocabularies.
* menu parent chooser on node/add and individual menu item edit (performance and usability woes again)
* book parent chooser (much nicer than the above in D6, but might be possible to re-use the code and unify the interface between them).

Something which can then be applied to non-core forms in the same way as tabledrag.js has been in D6 would be a nice solution, so although I've not checked out the 2.x version of hierarchical select yet (other than trying it out on Michelle's site), I reckon it's worth consideration here.

link for anyone who's confused by this conversation.

catch: you're absolutely right. I overlooked that.

So HS would still be suitable on the condition that it could give live feedback to the user, but with enforce_deepest disabled of course. Would that be correct?

Live feedback sounds good. Could it also deal with the node/add/forum/123 situation you reckon?

Yep, that would be the primary use case, at least in this issue. It would of course be useful in other HS implementations too.

Side note:
I already wrote a custom HS implementation for a client in which the root level (the first level) is a list of all vocabularies and the subsequent levels are the trees of those vocabularies. Actually selecting a vocabulary is of course invalid, so if you'd select that, you'd get a validation error.
This is another example in which live feedback would be a major improvement.

Sorry I don't think I worded that well. How would HS deal with the situation where terms are pre-filled by the "post new topic links" for specific forums?

All right, since Hierarchal Select is being discussed at this moment, and because this is still technically my task (I think :P), I think I'll do a writeup in place of coding more mockups:

Hierarchal Select seems like a great solution, and I did look at a bit of the code before. I have a few qualms about it, however:

1. There is still the issue of graceful degradation. If the user doesn't have JavaScript enabled, it'll revert to the same old system. I guess you could combine the disabling attribute solution with HS (as any options for containers could be "disabled" via the server-side), and I guess that'll be the best option.

2. Is there any way for HS to not use AHAH (i.e. is there any way for HS to extract the menu structure from the "regular" select field)? Or is there any way for Drupal to provide HS with a hierarchy inside the page?

3. Minor issue, but HS uses the Interface plugin for jQuery. Couldn't it just use regular jQuery effects, or does Interface do something else here that I'm not aware of?

1. That's what will be worked on for HS3. If there's enough interest – and it seems there is – I will start working on that after my exams, in 4 weeks. See this issue: http://drupal.org/node/226067

2. That's butt-ugly, unreliable and doesn't scale well. See #1.

3. Interface is used *only* for the left slidein/out. But that effect is by far the best fit usability-wise for HS. It completely makes sense. There's an issue for that too: http://drupal.org/node/203055.

What you did not yet take into account, is RTL support. I think HS makes no sense at all for RTL languages ATM. I just created an issue for that too: http://drupal.org/node/226183.

Setting this back to active.

What is really the need to allow nested containers? afaik there isn't a valid use case of using a container other than at the root parent level.. but I can be wrong..

We need nested containers because we've had nested containers in the past. Alternatively, we could drop support for nested containers, but that would break lots of forums being upgraded.

That's fine, we'll need to find some workaround to fix websites upgrading to this change.

Fixing containers for just the root level would mean opening up large number possible features and changes to the interface, also giving the ability to actually "beat" other dedicated forum software.

Let's keep upgrading aside, is there any valid reason anyone would need a container somewhere other than the top level of forums?

What is the status of this request? Will this functionality appear in Drupal 7? Those error messages still present in 6.14. IMO this presents a significant usability problem.

Revisiting what looks like an interesting discussion. mthomas and I have a Drupal 6 forum and have taken to using hook_form_alter to disable the container links. This is a rather inelegant solution.

It looks like the discussion above stalled out above when it because clear that hierarchical select wouldn't be a good fit as a solution because it is not a part of D7 and does not have RTL support.

Before the discussion switched over to hierarchical select, the first of the awesome mockups in #7 was the favorite solution. However, there is a slight problem because mockup #1 would not support nested containers, which have been supported in previous versions of Drupal. Although, on a side note, I have never been able to figure out the appropriate use case for them.

I think that the next step is to see if we can find a way to implement mockup #1 with support for nested containers. Anyone disagree?

I've been looking into this for awhile and I think that the key is to allow the disabled value on options. Looks like it's being worked on in Drupal 7. Check out #284917: Allow FAPI select, radios, and checkboxes to specify some options as disabled.

Marked as duplicate:
#413512: Forum containers should be marked as disabled so that they're not selectable
#639388: No optical separation of Containers and Forums

This really depends on #284917: Allow FAPI select, radios, and checkboxes to specify some options as disabled

We have hardcoded elements that does not allow to set no attributes no classes

As solution this select/dropdown could be themed through own element.

Looks like a lot of work on this thread, but is it a bug or a feature? It's marked as a feature which means it needs to be bumped to D8... I don't know enough about the issue to make the call; at this point I'm just an interested observer. ;)

Michelle

Suppose this more feature then bug because it lives too long in core :)
Another issue that we should not allow containers inside containers this could allow usage of optgroup which is more reasonable

I'm going to bump this to D8, then. Not allowing containers in containers breaks an existing feature so that might not go over well. If you figure out a way to make this work without changing core, feel free to post a patch in AF's queue.

Michelle

Hm, hhis could be easy done with small amount of code :)

Just processing terms within form_alter and making containers as arrays

Screenshot attached

This is stupid if simple user can select container and send emails to admin asking what's wrong.
Just wast of time for all. This should be fixed as soon as posible. I remember this bug in D5! So long ago.
If commit to D6 is imposible may be new module can be created to fix this in D6?

@VladSavitsky: This is core, it needs some actual reviewing, not just a desire to have it, before marking it RTBC. Plus, the test bot hasn't had a chance to hit it yet.

Michelle

#33: 12089-forum-optgroup-d7.patch queued for re-testing.

Tests should re-worked to remove testing of error messages because there's no more errors :) and forum nodes are created anyway

I agree with Michelle that this is Drupal 8 work. Especially if we go down the road of introducing unexpected behavior of a form element (from a usability standpoint this is totally unacceptable). This problem is where hierarchal select would work beautifully, but too late for D8.

Bojhan, I strongly disagree with you - current case is common behavior which widely used in all other forum-engines for moderation. I think that you have not using forums as moderator - when you need to move topic from one forum to another!!!

Users should not have ability to select option that is un-selectable by it's nature.

phpbb - uses OPTION disabled

<option value="23" disabled="disabled" class="disabled-option">ТЕХНИЧЕСКИЙ РАЗДЕЛ ПО HUMMER. TECHNICAL SECTION</option>

Same used in SMF forum

But this approach does not work for IE6-7 - try to google "Option disabled in IE"

So I strong propose using OPTGROUP to remove the confusion and make visual difference between forum and container.

Or we continue pathetic about unusable esthetics?

Leaving this needs review to gather more opinions about markup

I can confirm that just using my own forum I try to put a post into "General" (container) instead of "General Discussion" (forum) at least a couple of time a month. :) It's not a huge deal to me but would eliminate that annoyance. I have no idea if my users are having that problem. They don't start new topics often.

Michelle

I mean, you are right users shouldn't be able to select something that they technically can't select.

However showing "disabled" elements in an select list, is not the way to go in terms of usability - as people expect items in a select list to always be selectable (the behavior of disabled elements is not common at all), that PHPBB or SMF didn't find a solution and thus went for a less usable solution shouldn't mean Drupal should lower its standards too. I mean it will cause a usability and its not "pathetic unusable aesthetics" - which is not very nice :(

I mean, you can say we will ignore the clear usability issue and move on anyway. But don't state the issue is non-existent.

A new screenshot with sub container and sub forum inside

I think the visual difference should make a sense

EDIT The generated HTML

<select name="taxonomy_forums[und]" class="form-select required" id="edit-taxonomy-forums-und">
 <optgroup label="Container"></optgroup>
 <option value="37">-New forum</option>
 <optgroup label="--Sub container"></optgroup>
 <option value="39">---Su-sub forum</option>
 <option value="35">General discussion</option>
 <option value="40">-General sub forum</option>
</select>

Also this code is not valid from w3c validator

Line 13, column 39: end tag for "OPTGROUP" which is not finished
<optgroup label="Container"></optgroup>

But it's used only in edit forms.

Re: #44

That's a start, but the problem here is that the markup is not semantic. Options need to be inside the logical optgroup. I think you are on track to at least an improvement, though. Here's my proposed solution:

<select>
  <optgroup label="Top container">
    <option>Top container forum A</option>
    <option>Top container forum B</option>
  </optgroup>
  <optgroup label=" - Sub container 1">
    <option>Sub container forum A</option>
    <option>Sub container forum B</option>
  </optgroup>
  <optgroup label=" - - Sub sub container">
    <option>- Sub sub forum A</option>
    <option>- Sub sub forum B</option>
  <optgroup label=" - Sub container 2">
    <option>Sub container forum A</option>
    <option>Sub container forum B</option>
  </optgroup>
</select>

The indentation would need to be tweaked (see screenshot), but you get the idea.

So, to summarize, it is a combined approach: optgroups represent containers, and direct child forums only are inside the optgroup. Sub-containers get their own optgroup, with their direct children only inside. We could continue to use the hyphens to denote the indentation as in taxonomy normally (or not).

Advantages of this method: valid and semantic markup, more usable and accessible, no fighting with disabled items, no selecting the container and having to wait for the validator.

Disadvantages: This method would have to disregard weighting systems where a direct child forum is stuck between two subcontainers (since all forums need to be inside the proper optgroup), but I think that's bad practice anyway. Also, the indentation's not quite right, yet. Not sure how much is possible in CSS.

Ideally, this would be the no-javascript graceful degradation, and we would include an AJAX/AHAH/jQuery/whichever handler to override it in a more usable and intuitive fashion.

@xjm thanks for idea of spaces

EDIT: The benefit we get here is separation of sub-forums and sub-containers within parent item

Hyphens are removed, names are taken from d.o/forum

Screenshots from win browsers

<select name="taxonomy_forums[und]" class="form-select required" id="edit-taxonomy-forums-und">
 <optgroup label="General">
  <option value="8">News and announcements</option>
  <option value="2">General discussion</option>
 </optgroup>
 <optgroup label="Deprecated">
  <option value="39">Deprecated - Usability feedback</option>
 </optgroup>
 <optgroup label="&nbsp;&nbsp;&nbsp;&nbsp;Deprecated - Development (working groups)">
  <option value="48">&nbsp;&nbsp;Deprecated - Database compatibility</option>
  <option value="33">&nbsp;&nbsp;Deprecated - Documentation</option>
 </optgroup>
</select>

Some OS X screenshots for the same markup. I'm also looking into CSS possibilities.

Additional screens for IE6 and IE7 win

Here's a js variant

After discussing this with andypost and Bojhan, here's my thoughts. There are two separate questions to decide: the semantics of the markup, and the presentation.

For markup semantics, we have three choices:

1. Printing a flat list where both forums and containers are options
2. Printing semantically invalid, empty optgroups as "headers"
3. Printing semantic optgroups containing only direct child forums

#1 is potentially confusing to users. #2 is not a good idea because it is not semantic nor very accessible; we are bending the markup to do something it's not intended for (like table layouts). #3 has the disadvantage of potentially forcing sub-containers to appear heavier than plain forum children despite weights.

How we choose between these three options is separate from the presentation. After talking to andypost and looking at the related APIs, I think we agree that the presentation of the containers should be handled by javascript, since it is not currently possible to add attributes to options in FAPI (see #284917: Allow FAPI select, radios, and checkboxes to specify some options as disabled). So, we could use javascript to do any or all of:

1. Disabling container options, if markup method #1 is used above.
2. Appending text indentation to the beginning of option and optgroup values, either using - or  . This could be used with any of the methods above.
3. Applying css classes for contrib and custom theming. We should probably do this regardless.

I think we should add this JS processing because contrib theme could easily override this default script and have a good example how to change this behavior.

Also we need to fix #786620-12: Regression: Add new forum topic not visible within a forum - context link to "Add forum topic" should be visible only for pages which does not suppose to throw error message (screen in #6)

I can't see spending time on fixing this at this point in the release cycle. D8, possibly for back-port later. We need to focus efforts on issues that are going to get D7 out the door, and this doesn't qualify, and comes almost a year since feature freeze.

I'm personally a bit relieved to think of this as an 8.x issue. The more I think about it, the more I feel that it's just one part of a larger issue with FAPI, usability, and form themability; one that applies equally to all taxonomy (not just to forums). Perhaps something to explore in contrib, also.

There's actually an issue open already (which should probably also be bumped to 8.x):
#211494: Usability: Unify select option formatting

+1 sub

subscribe

After reading this thread and being I am about to start creating a forum in a site we are developing, would you suggest to have the containers only at the root and make everything else forums and threads?
I personally found the use of mock-up1 the more elegant one, I personally liked it, and will try to apply it until something better comes around.
looking forward to D8.x :)

marked as duplicate #913436: Forum container should not be a selection choice from drop-down in create forum topic

#49: 12089-forum-select-js-d7.patch queued for re-testing.

Previous patch no longer applies, which makes sense since it was made for D7 (though, it looks like the submitted patches never passed testing previously). Steps to reproduce this issue in d8:

1. Activate forum module under extend
2. Add several layers of containers and forums
3. Click "forums" from home page to add some content. Click "Add new forum topic"
4. Attempt to select where to put new forum topic in forum/container structure. Discover that it is possible to select a container, which cannot actually hold content. Return error message as shown here.
5. The issue is still an issue. It should not be possible to select containers only to receive an error message, particularly when the containers are not even obviously labelled as containers and can be nested.

I'll attempt a reroll but this probably needs more in-depth rethinking from someone with a little more experience. As mentioned in xjm's #53, this issue also spills over into general taxonomy.

I think optgroups is the easiest way to fix the issue.
See #1407746: Support grouping in select list for term reference field.

Took the javascript solution and converted variables to cmi for drupal8.

it had been a while. :)

+++ b/core/modules/forum/forum.js
@@ -0,0 +1,23 @@
+// $Id$
...
+    }
+
+  });

Extraneous newline.

+++ b/core/modules/forum/forum.js
@@ -0,0 +1,23 @@
+// $Id$

This is from the CVS days — we haven't needed this for years :)

+++ b/core/modules/forum/forum.js
@@ -0,0 +1,23 @@
+(function($) {

Drupal and drupalSettings missing in the closure.

+++ b/core/modules/forum/forum.js
@@ -0,0 +1,23 @@
+Drupal.behaviors.forumContainers = {

Docs missing.

+++ b/core/modules/forum/forum.js
@@ -0,0 +1,23 @@
+function attachForumContainers(context) {

Docs missing.

+++ b/core/modules/forum/forum.js
@@ -0,0 +1,23 @@
+  var forumContainers = Drupal.settings.forumContainers;

s/Drupal.settings/drupalSettings/

+++ b/core/modules/forum/forum.js
@@ -0,0 +1,23 @@
+  $('#edit-taxonomy-forums option', context).each(function () {

$(context).find('#edit-taxonmy-forums option.

+++ b/core/modules/forum/forum.js
@@ -0,0 +1,23 @@
+    if (forumContainers.indexOf($(this).val()) >= 0) {
+      $(this).attr('disabled', 'disabled');
+      $(this).addClass('forum-container');

Calling $(this) three times is a bit silly, let's:
- $variable = $(this)
- use chaining to reduce the last two uses to just one

+++ b/core/modules/forum/forum.module
@@ -628,6 +628,10 @@ function forum_form_node_form_alter(&$form, &$form_state, $form_id) {
+    drupal_add_js(array('forumContainers' => $containers), 'setting');

drupal_add_js() may no longer be used, use #attached instead, like you're doing on the next line! :)

+++ b/core/modules/forum/forum.module
@@ -628,6 +628,10 @@ function forum_form_node_form_alter(&$form, &$form_state, $form_id) {
+    $form['taxonomy_forums'][$langcode]['#attached']['js'][] = drupal_get_path('module', 'forum') . '/forum.js';

This does not declare dependencies on system.module's drupal and drupalSettings libraries, which it should. To do that, this should be converted into a library, which can be declared in forum.module using hook_library_info().

I was able to apply the patch successfully. The functionality worked as intended, and I was unable to assign to a container. The node saved successfully, and I was able to edit the node and assign to another forum.

#877584: Forum look&feel Related issue. Would be good to fix as we use the forum module here.

Has this issue been abandoned. I use the forum and can't believe it hasn't been fixed in all these years. Please please fix

@paintingguy https://www.drupal.org/project/taxonomy_container can help on this.

@Chi Thank you for your suggestion however I cannot make the Taxonomy Container Module work for me. I either do not understand how to implement it or it isn't working on Drupal 9? Any help would be appreciated.

Am I able to create a forum container that doesn't show in the dropdown list when members are creating a new topic?

Thank you

@paintingguy, you need to configure selection plugin for taxonomy field. Anyway, this is Drupal core issue. Questions about Taxonomy Container module should be asked in the corresponding issue queue.

@Chi,

my question is the same as the OP here. You suggested using Taxonomy Container , so I tried and it doesn't solve the issue.

Is it possible to make forum container terms enclosed in optgroup in the dropdown select during creating a forum topic? This way, the container terms cannot be selected by user when specifying where the would_be forum topic belongs.

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.

Adding the Accessibility tag as this issue has implications for screen reader users who can't see any text decoration that may indicate that a forum container is different to forums in the select field. As the screen reader announces the forum container as a selectable item, this leads to confusion and a poor user experience.

I appreciate that this issue is currently marked as postponed, but adding the tag for when the forum module is split off and issues start to be addressed again.