Add support for multi-select?

No plans at the moment. I did have a quick look at some of the CCK taxonomy modules, and some implement this feature. This could be a good place to start. It would be awesome if you can implement this nicely.

I will look at free-tagging soon, as I think I'll be using it for a work project that requires this. If both features are implemented, then it would be a minor task to extend this module to implement a CCK TaxiSelect taxonomy field!

Alan

Sounds great, let me know if I can help in any way

Subscribing

subscribing. This sound as a great extension

@Alan: +1 for a CCK TaxiSelect taxonomy field. I would be happy to contribute testing.

@equalspeterd Any progress on this?

I've got a bit of spare time at the moment to look at this.

Cheers

Alan

Attached is a screen shot of the proposed new functionality (not yet implemented), and any feedback will be appreciated.

The first is the JScript version. This will be fairly similar for single and multiple selects.

The next 3 are without JavaScript. The first of these is a multiple vocab with multiple terms selected. The second is a single select vocab with an existing selected term. The last would be a single / multiple without any selected terms.

I will create a new branch for this when I'm ready to commit the new changes, as the internal API will have changed a lot.

Just look at the screenshot in #8. This is a great. Good idea for the support with or without JScript. A graceful degradation.

I have a suggestion to improve usability. Find attached mockup to clarify.
-To make items easier to read. Add a grey background to each item.
-To save space. Replace 'Remove' with 'x'. 'x' means remove but takes less space. The 'x' is the standard for remove or close or delete. It's use in all OS such as Ubuntu, Mac & Windows.

This improvement suggestion is inspired from 'active_tags' module. dragonwize the module maintainer says the active_tags module doesn't plan to have a 'single line autocomplete' feature. Read more at http://drupal.org/node/530968 In other word TaxiSelect module is valuable because it's the only module that I know of who has a 'single line autocomplete' feature.

Just done a real mock up, and about to look at using AHAH for the requests.

Some points

I'm only going to have just the add / replace button by the autocomplete field. The "Add" will update the checkbox array with or without jscript, so there is no need for the "Update" button.

For accessibility, I think that it is best to stay with the "remove" text. I'll look at wrapping it in a t() so that you can easily update using string overrides in your setting.php [Eg: something like: t('remove'), the html included to distinguish between other instances of t('remove').]

Attached in a active screen shot of progress. Preferences on L / R for the remove link?

Neat mockup in #10. I like the stripped table in mockup #10 better than the all items with a grey background in mockup #9. #10 takes less space and is still easy to read.

Good idea for the t(). This way user can easily reword 'Remove' to match their needs.

About the first part of mockup #10. The one without JScript. Why adding checkboxes? It seems easier for the end user to simply click on each 'Remove' link beside the item he wants to remove. What do you think?

Option 1 without checkboxe:
Let say the user wants to delete items 1, 2, 3. To do so he clicks the 'Remove' links beside item 1, 2, 3. Total 3 clicks. And the table is using less space because the checkboxes column isn't needed.

Option 2 with checkboxes:
As oppose to user clicks checkboxes for items 1, 2, 3. Than clicks on any 'Remove' link. Total 4 clicks. Plus the table is using more space.

"It seems easier for the end user to simply click on each 'Remove' link beside the item he wants to remove."

This would require a form submit, something a link without javascript could not do. Then either the "Add" or main ""Submit" would update the removal of the terms. With javascript, these would degrade to a AHAH request (AJAX form POST), which would mean just the link with a hidden checkbox.

Do you have any preferences on the position of the remove link? The left is cleaner, but the right seems more natural.

Cheers

Alan

Ok I understand now. Thanks for clarifying. If I understand well the checkboxes are only visible to the user with JScript deactivated. If users has JScript activated checkboxes are hidden. Sounds good to me.

As for the position of the remove link my vote goes for right side. Because it's natural. The 'remove/close' link is usually on the right. For example Firefox & Internet explorer tabs, Mac & Ubuntu & Windows folder navigator. Anyway if the 'Remove' link is position to far on the right side then themers or designers can use CSS to resize the table to a specific width.

I am desperate for this exact module - has it developed any further?

The latest Development snapshots version 6.x-1.x-dev (2009-Aug-08) is available at http://drupal.org/project/taxiselect

Direct link http://ftp.drupal.org/files/projects/taxiselect-6.x-1.x-dev.tar.gz

This is still on the cards, but time issues have meant that I haven't had that much time to work on this. My first attempt was to create a new element that handles this functionality, but this failed badly.

Sorry no estimate for the TOA.

New 6.2 branch has this functionality, but has limited testing due to time constraints.

This is an important step in the road towards CCK functionality => D7 fields.

PS: AHAH functionality on the Remove checkbox is still in the works. These do update on the Add/Replace AHAH action.

Thanks Alan. I'll try testing next week. Then I'll post my result here.

I have tried the 6.2 branch. But now the widget is not showing up anymore. I am doing something wrong?

Did you remember to run your updates? You should have got a warning about Taxiselect being the module handling the Taxonomy loads or something like that.

Also check the settings just in case some got missed when upgrading. The only new ones of interest are related to the admin interface and free tagging.

Also disabling / enabling should set the "taxonomy_override_selector" variables flag - but this should have occured when running update.php?!

@cronix: If none of the above work try testing with a fresh Drupal install.

Awesome. Multi-select works.

I tested with "Create page" at /node/add/page. Adding multiple taxonomy terms. Saving. Works.

I tested editing same page again. The saved terms are showing. Works.

I tested removing terms. Works.

Tested with:
-taxiselect-6.x-2.x-dev.tar.gz (September 7, 2009 - 17:28) from http://drupal.org/node/569932
-Height taxonomies / 8,380 terms (Each taxonomy with 1048 terms). Created with Devel Generate.
-On "Create page" at /node/add/page
-Fresh Drupal 6.13

Tried the latest DEV. I get the new admin settings after disabling/enabling the module. But still no widget on the node admin page.

@cronix: TaxiSelect settings/admin page can be found at admin/settings/taxiselect Find attached screenshot to clarify (taxiselect-settings.png).

Have you try following the instructions into README.txt file? Under the section 'CONFIGURING AND USING'.

@cronix: Did you run update.php????

I always run update.php; I have seen that the module has updated itself. Does the module install any tables? Maybe I can try a clean install? I have a big installation with over 100 modules running.

I uninstalled the module, delete all files and installed it again. But the widget is still not showing up on my site.

@cronix: The most likely cause of this issue is that the 'Tags' box is selected. Make sure it's NOT selected. To do so navigate to Administer > Content management > Taxonomy
Click on 'edit vocabulary' link for the appropriate vocabulary.
Under 'Content types' section check a content type.
Under 'Settings' section make sure that 'Tags' is NOT selected. Otherwise it won't work properly.
Click on SAVE button.
Create a new page at node/add/page
If successful you should see the widget somewhere in that page at node/add/page

Source: README.txt file.

The alpha release has this feature and currently no known bugs.

I am putting all of the other AHAH magic on hold until I have free time. There are more important issues to resolve; free-tagging, interface for massive vocabs and maybe CCK.

Two recent empty string bugs were detected and resolved, so use the latest alpha version. Dev could be unstable with new features (if I get the time!!)

I am sorry, but the current version is still not showing up on my site. I have tried everything mentioned here.

I also get the following message when I Preview a post (does not happen when I select Save):
warning: Invalid argument supplied for foreach() in /www/sites/all/modules/taxiselect/taxiselect.pages.inc on line 69.

Beautiful, an error message, something to work with.

Can you send through a list of modules that you are running. There appears to be something that is setting a form item to a value that it should not be!! Are you sure there is not some custom code somewhere outside of the installed modules?

Even more helpful would be a copy of the $form_state at this point: If you don't mind editing the php file and you have a TEST site, you can help by changing the following:

<?php
        // The AHAH form_state overrides the $node->taxonomy. (This is line 66)
        if (isset($form_state['values']['taxonomy'][$vocabulary->vid])) {
          $default_terms = array();
          foreach ($form_state['values']['taxonomy'][$vocabulary->vid] as $key => $value) {  // Line 69
            if (is_numeric($key)) {
              $default_terms[$key] = $key;
            }
          }
        }
?>

to

<?php
        // The AHAH form_state overrides the $node->taxonomy.
        if (isset($form_state['values']['taxonomy'][$vocabulary->vid])) {
          $default_terms = array();
          drupal_set_message(print_r($form_state['values'], TRUE));
          foreach ($form_state['values']['taxonomy'][$vocabulary->vid] as $key => $value) {
            if (is_numeric($key)) {
              $default_terms[$key] = $key;
            }
          }
        }
?>

and copying the values printed to the drupal message area and pasting them here or sending them direct via my contact tab.

I can add checks to check if this is not an array, but going down this path means the 1/2 the module is checking for invalid variables and this becomes a great big mess, so I would prefer to see what is causing the error in the first place. Also changing this from a string (?) to an array could also cause errors in the other module that is doing this.

@all: Confirming that TaxiSelect alpha version works (6.x-2.0-alpha1). Using Drupal 6.14 and 22+ other contributed modules. Thanks Alan.

@cronix: You said in your comment #28 that your site has over 100 modules running. The issue you're experiencing might be cause by one of those contributed module conflicting with TaxiSelect. Here are two more things you could try.

1. Disable all contributed modules. Except TaxiSelect & Taxonomy. Test if error is still there. If error is gone activate one contribute module at a time. By doing so you'll isolated the error and find out which contributed module is conflicting.

2. If that doesn't work the second thing you could try is testing TaxiSelect with a fresh Drupal install.

Either there is a fatal flaw in my logic somewhere (I have also doubled checked this!), or another module on his site is incorrectly setting the node taxonomy settings to something other than an array.

@cronix: What access control mechanisms are you running on your site? Have you custom code to hide / show the taxonomy fields?

I'm hoping a dump could hint at the real issue. Maybe it has been wrongly converted to a string with the modules name tagged as a class in the code somewhere. But a non-programatic way of helpping would be to clone your site and to disable modules. The first ones would be any hacked or custom ones for your site. Flush your cache and check. Next look at taxonomy based modules that modify input / presentation. Then access control modules, then nuke the lot until you find the issue. If you send through a list I can tell you want the likely ones are.

Thanks for all the input. I have installed the latest alpha (2) today. The error message is gone. I have also tried the code from #32. No messages. I have put an extra drupal_set_message before the if statement in order to check if the code is called at all. That is the case. I get my message twice; that is correct since I have configured taxiselect for two taxonomies. To me it looks like the module is configured correctly.

I'm happy to hear about the happy ending.

That's a great module isn't? Much more user friendly, better usability and using less memory than core taxonomy module.

Oops. I was not clear enough. The widget is still not showing up!. I just did not get the messages that were in the loop. I too think it's a great module and I really, really need its functionality. I will try to disable the modules.

@cronix: Well at least you have one thing fixed ;)

Deactivate the other contributed modules might help isolate the source of the issue. I faced the same issue from time to time. When a site has lot of modules, in your case over 100, you can save time by deactivating all other contributed modules first. Then after that instead of reactivating the module one by one reactivate the first 50 modules. Then test if the widget is showing up. If the widget is showing that tells you the issue comes from one of the LAST 50 modules. If the widget is NOT showing that tells you the issue comes from one of the FIRST 50 modules. Then redo the same thing with the next 25 modules. And so on. Suck on that evil error (joke).

If it's your first time doing this and you're working on a production site you should first thing first activate the maintenance mode under admin/settings/site-maintenance. Then log-in as admin (user #1) to investigate. So while you're investigating your visitors are presented with a 'Under maintenance' screen instead of 'error can't find blah modules'. Then once you found the source of the error and the widget is showing you can deactivate maintenance mode.

@cronix: If you do send through a list of your modules, I can probably guess which one(s) it will be. I'd recommend a test site rather messing with the live site!! This should really have it's own issue, so feel free to open a fresh issue with any responses.

Anyway, once I get the new admin term listing page done, I may get the CCK field started, this would bypass the issue. (I can not list a current taxonomy using Drupal anymore due to it's size, thus creating a simple admin interface)