It appears that this module assigns the node the default taxonomy when the creation form is brought up, so if the user does not want the default category, they have to remove to assign their own. I would prefer if there were no default category assigned until after the form is submitted *and* the user did not choose their own category.

Would this be an easy thing to add? It would make a big difference for my site.

Thx,

-John

Comments

bradweikel’s picture

bradweikel commented

To clarify: Are you using a freetag vocabulary? Or a vocabulary with "Multiple Select" enabled?

Just want to be sure I'm understanding your question before I comment further.

bradweikel’s picture

bradweikel commented
Status: Active » Postponed (maintainer needs more info)
whyameye’s picture

whyameye commented

this is a multiple-select vocabulary. More specifically, I am using the "hierarchical select" module for users to choose/add multiple terms in their vocabularies.

-John

bradweikel’s picture

bradweikel commented
Component: Miscellaneous » User interface
Status: Postponed (maintainer needs more info) » Closed (won't fix)

I'm hesitant to add this feature to Taxonomy Defaults for several reasons:

  1. This module is really just for pre-selecting terms in the node/add/* forms, not for enforcing user behavior (e.g. 'You MUST select a term, or one will be automatically assigned'). I don't think the feature you're after makes sense for this module.
  2. Even if I did add it, it is unclear to me how to properly handle node editing. For instance, if a node was created with no terms, and this new feature assigned some default terms after submission, and then a user edits it, removes the terms, and submits again, should the terms be forced on them a second time? I think this is setting up some really bad usability scenarios, and would probably trigger a few support headaches for me.
  3. Insufficient demand.

I think a better way to go about this would be to add a new feature to the hierarchical select module, which would prompt the user (via jQuery) to add or ignore the default terms before allowing them to add their own terms. No counter-intuitive trickery hidden from the user, and no weird enforcement of required terms (unless the vocabulary has the "Required" core Taxonomy option enabled). While it still requires an extra click from the user, that click is presented as a forward moving choice rather than a clunky "undo defaults" step.

If you want to pursue this further, I'd suggest opening a feature request for the Hierarchical Select module and referencing these comments.

whyameye’s picture

whyameye commented

Addressing your points:

1. Hierarchical Select has a "mandatory category" feature already. But what happens is that people are forced to manually choose the default category every time they submit.

2. The behavior I am describing is exactly what WordPress and every other blog engine I know which supports categories does for every blog post. If you do not choose a category, the post goes to 'Uncategorized." Your answers to intuitive behavior for users would be in mimicking the behavior of those blogging engines. I guess that's what I had in mind. Might not have been clear before.

3. OK.

Anyway, thanks for considering. And thanks for maintaining this module.

-John

bradweikel’s picture

bradweikel commented

Re: 1. Understood. What I was suggesting was that the HS module could preselect the defaults, as it currently does, but prompt the user to keep or reject those defaults before they can add their own. If they don't touch anything, the defaults would stick. As opposed to the current setup, where they probably add their own and then see the defaults and go "huh? where'd those come from?" and then hit remove.

Re: 2. Aha! I hadn't thought about "Uncategorized" -- now your intentions make a lot more sense. If that's the only reason you're using Taxonomy Defaults, I'd suggest that you bail on this module altogether, because "Uncategorized" doesn't need to be a term (and probably shouldn't be, for multi-select vocabs) - it's really a state implied by the absence of a term. You should be able to use Views to display uncategorized nodes, as if there were an "Uncategorized" term. This approach also resolves my concerns about what to do when editing posts, etc.