With a small change the js can handle commas in the terms allow quick addition of multiple terms.
Currently in activeTagsActivate() you have

  $('.add-tag:not(.tag-processed)').click(function () {
    var tag = $(this).prev().val().replace(/["]/g, '');
    if (jQuery.trim(tag) != '') {
      activeTagsAdd(context, tag);
    }
    activeTagsUpdate(context);
    $(this).prev().val('');
  }).addClass('tag-processed');

By changing to

  $('.add-tag:not(.tag-processed)').click(function () {
    var tag = $(this).prev().val().replace(/["]/g, '');
	  jQuery.each(activeTagsParseCsv(',', tag), function(i, v) {
	    if (jQuery.trim(v) != '') {
	      activeTagsAdd(context, v);
	    }
	  });
    activeTagsUpdate(context);
    $(this).prev().val('');
  }).addClass('tag-processed');

it will handle commas in the new value and treat as multiple tags.

Comments

dragonwize’s picture

Status: Active » Closed (works as designed)

Single tags only are accepted in the field, including commas (ex. Smith, John). This is by design to fulfill the modules purpose as noted on the project page.

If you want to add multiple terms by comma then use the standard taxonomy autocomplete form instead of AT.

cerup’s picture

Status: Closed (works as designed) » Active

Thanks nevets.

dragonwize, I'm marking this as active again just to see if this would be a possibility for the future.

I personally think (and several others have agreed) this should be an option per field to set 'use comma seperation' or not. My users keep writing a comma separated list instead of adding each single term individually (despite help text stating otherwise). This creates poor usability and incorrect behavior. It would not be ideal to switch to autocomplete since that doesn't have the same functionality (adding/removing terms) as this module. Adding an optional value for each field would make both parties happy I would imagine.

dragonwize’s picture

The option already exists. Use the standard autocomplete form without active tags.

The ONLY difference between the standard form and AT is that AT changes the workflow from treating all the terms as one single field to each term being its own entity.

I don't see the point in creating a version of AT that works exactly like standard form. If you can convince me of why that would make any sense at all then I might be willing do something.

nevets’s picture

Actually as cerup pointed out, adding the ability to use commas with active tags is not the same as using the standard auto complete. I actually modified the copy I am using to handle commas while retaining the way AT shows the tags and allows easy removal.

cerup’s picture

AT allows you to press 'add' and see the terms added as well as remove (using the X) to remove terms which is fantastic in terms of usability. This is something that vimeo.com uses (although they use comma seperated terms). The standard auto complete does not add terms like this and you can't actually see what's added until submit. That's the reason my users and myself enjoy this module because of it's usability. The way AT works especially helps when the list can be long.

So, no I wouldn't consider using autocomplete as an 'option' in that sense. Can it ultimately produce the same result? Yes. But is the usability the same? No and that's the main reason we like using the module - usability. :)

From my understanding, the original module allowed comma separated lists, so doesn't that mean that wasn't the original go of the module (to be different from autocomplete)?

dragonwize’s picture

Title: Add comma handling in the terms » Add configuration to allow comma seperated user input style

The original module did not allow comma separated lists. It was added in version 1.1 on a user request here #310098: multipe tags.

After that it was requested for the change to be turned back and was discussed here #373309: Treat entry field as a single term including commas and here #412578: Tags are not submitted if user does not click add.

Including both the current maintainers agreeing that the comma separated method did not fit the modules purpose as described on the project page.

Since we have seen continued requests for both even though I do not agree with the comma separated method, I will be willing to put a configuration option in to choose which method to use. I am currently busy though so this feature won't be put in 1.x without a patch from someone else. Otherwise this will have to wait until I am done writing 2.0.

cerup’s picture

Thanks dragonwize!

If I get a chance, i'll try to submit a patch - otherwise we'll happily wait for 2.0.

We appreciate you taking the consideration despite you not agreeing and I'm sure people will thank you for it in the end. :D

slucas’s picture

I'v just come across this discussion, I've detailed a bit the advantages of a commas separated aproach, and how it's different from autocomplete widget in
http://drupal.org/node/1030908

Somebody have tried the patch described at #1 by nevets.
It would work?

lennart’s picture

The way delicious.com does it, is the best I've seen. There you can even show a tag panel with previously used tags.

dragonwize’s picture

Version: 6.x-1.9 » 7.x-2.x-dev
Status: Active » Fixed

This has been added to the 7.x-2.x branch.

dragonwize’s picture

Version: 7.x-2.x-dev » 6.x-2.x-dev
Status: Fixed » Needs work

Need to backport to 6.x-2.x.

Some of the 7.x JS code could be used but most of the configuration will have to be done separately. Since 6.x works with taxonomy module and content_taxonomy module, both of those integrations will need to be accounted for.

bryancasler’s picture

Just tried the dev, seems to work

bryancasler’s picture

I take that back :)

I get the following warning and notice when adding tags now.

Warning: Invalid argument supplied for foreach() in _community_tags_term_reference_field_search() (line 935 of C:\xampp\htdocs\drupal7beta3\sites\all\modules\community_tags\community_tags.module).
Notice: Undefined index: und in _community_tags_term_reference_field_search() (line 935 of C:\xampp\htdocs\drupal7beta3\sites\all\modules\community_tags\community_tags.module).
dragonwize’s picture

@animelion: This is the active_tags issue queue not the community_tags queue

bryancasler’s picture

Thanks, sorry for the mix-up.

mahyarsbt’s picture

Assigned: Unassigned » mahyarsbt
Issue summary: View changes
Status: Needs work » Fixed

Thank you for your continued interest in the Active Tags module.

We are excited to announce that the issue you raised has been addressed in the revitalized Active Tags version 1.0.0. This update supports Drupal 9, 10, and 11 and brings a modern interface along with a range of new features to enhance your Drupal tagging experience, including:

  • Enhanced Tag Styling: Enjoy a modern and visually appealing interface for entity reference fields.
  • Dynamic Tag Creation: Flexibly enable or disable tag creation based on your Drupal settings.
  • Support for User Avatars: Display user avatars in tags when using the User entity autocomplete.
  • Efficient Tag Management: Organize tags effortlessly with drag-and-sort functionality, duplicate protection, and multiple selection support.
  • Entity ID Display: Optionally display the entity ID alongside each tag for added clarity.
  • Integration with Key Modules: Seamlessly integrate with Token, Webform, Facets, and Better Exposed Filters for enhanced filtering and autocomplete functionality.

This is just a glimpse of the new capabilities. We encourage you to explore these new features by downloading the latest version. For a full list of features and more details, please visit the Active Tags project page.

mahyarsbt’s picture

Status: Fixed » Closed (fixed)

With the release of Active Tags 1.0.0, we believe this issue has been fully resolved. We invite you to explore the latest version and share any feedback you have.

Thank you for your continued support and contributions to the Drupal community. Together, we can keep improving Active Tags!


Visit the Active Tags project page to stay updated and provide feedback.