Closed (won't fix)
Project:
Webform
Version:
6.x-2.4
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
29 Jul 2007 at 12:16 UTC
Updated:
10 Sep 2009 at 21:32 UTC
Jump to comment: Most recent file
Comments
Comment #1
sutharsan commentedI want to know this too! I need to ad a taxonomy select list (or a select list with tags) to the webform. Manually adding the terms to a webform select list is no option.
Comment #2
sutharsan commentedBased on select.inc I have made an include file to handle taxonomy tags. Code is tested but only for my (limited) use of taxonomies.
Comment #3
goose2000 commentedWow, thanks - I'll try it out; Do we need to patch the select.inc with this file or is this a new webform include (component)?
Comment #4
sutharsan commentedThis patch will create a new file: components/vocabulary.inc. select.inc is untouched.
Comment #5
summit commentedHi,
Could this patch be updated for webform 5 1.7
The values of the vocabularies are not saved when I tested this.
Taxonomy support for webform is a great + for me, so please update the patch so it works with webform 5 1.7!
Thanks in advance,
greetings,
Martijn
Comment #6
summit commentedI think this would really benefit webform. Please add it to the newest version.
If it's working..
greetings,
Martijn
Comment #7
summit commentedHi,
I got the following error on this code:
The mail I got back when using vocabulary support in webform.module gives back blank terms:
Where "Regionaal" and "Rubrieken" are my vocabularies.
Does anybody know what is wrong with this vocabulary.inc?
The complete code is as follows:
I think the problem is on this part of the code:
The newest select.inc (the file where Erik made the vocabulary.inc from) has one difference to the old select.inc and that is:
Old select
New Select:
Has this something to do with it?
Could somebody please help me to get this vocabulary support of webform working?
Thanks in advance!
greetings,
Martijn
Comment #8
summit commentedHi,
I have seen that the single term option works fine, but the selection of multiple terms not.
May be the code:
Is not correct?
Can somebody please help?
Thanks in advance!
greetings,
Martijn
Comment #9
summit commentedHi,
Please can someone assist why the multiselect terms is not working?
The single select is working. The multiselect is working in the webform, but the email which is received has empty fields for selected terms..
Please assist!
Thanks a lot in advance!
greetings,
Martijn
Comment #10
summit commentedHi,
THis error is away using: http://drupal.org/node/154870#comment-574381
Deleting [] from
$form_item['#default_value'][] becomes $form_item['#default_value']
I still don't have my vocabulary output on mail..If somebody has a suggestion. Please assist!
greetings,
Martijn
Comment #11
summit commentedHi,
I think the bug should be in:
Especially in:
This gives blank results back...
How can I debug this? Does somebody else also have this bug?
I attach my to webform 1.8 converted vocabulary.inc, please assist in solving this!Than webform has the taxonomy terms to be chosen from for your users!
Thanks in advance,
greetings,
Martijn
Comment #12
summit commentedHi, the attachment: http://drupal.org/files/issues/vocabulary.txt is converted to webform 1.8.
Again, please assist.
Thanks in advance!
greetings,
Martijn
Comment #13
summit commentedSomething went wrong, pressed twice..sorry..to late in the morning here..greetings, Martijn
Comment #14
quicksketchMarked http://drupal.org/node/220733 as duplicate.
I'm not wild about this idea mostly because the code is 90% the same as select.inc, meaning every bug in select.inc will need to be fixed in vocabulary.inc also. Wouldn't it be possible to include as part of select.inc somehow instead?
Comment #15
quicksketchNew features are no longer being added to the 1.x branch which is now maintenance-only.
Comment #16
quicksketchMarked http://drupal.org/node/230205 as duplicate.
Comment #17
summit commentedHi,
I am testing webform 2.0 now, and it is great...But it still doesn't have taxonomy support for user-entries.
If it will not be in a seperate file as you described earlier, may be you could build it inside the select.inc please?
Thanks in advance for considering this. It would be a great add-on to webform I think!
greetings,
Martijn
Comment #18
summit commentedHi,
There is a great new module release in the making of hierarchical select (version 3). www.drupal.org/project/hierarchical_select
The taxonomy terms can be put in dropdown lists with depth option.
Could this be implemented in webform also, so finally a user can also select taxonomy terms with other values to fill a webform?
Thanks in advance for considering this!
greetings,
Martijn
Comment #19
quicksketchPlease make a new request Summit. That one is quite different from the basic need of getting taxonomy terms into a select list.
Comment #20
wim leersquicksketch: it's not :) It's a simple matter of changing
#typeand passing the preferred settings. You won't have to set#optionsanymore, either. But it definitely should be the second step, because it requires an additional dependency (on the hs_taxonomy module, which is included in HS).Comment #21
wim leersHere's the separate issue for HS support: http://drupal.org/node/278236#comment-906938.
Comment #22
summit commentedQuicksketch, do you still think it is a seperate issue? If so off course I make another one then.
It would be great to join both great modules together.
greetings,
Martijn
Comment #23
quicksketchGreat, we can use the issue Wim posted in #21 as the separate issue. Yes, it's still separate though, as the first goal (the purpose of this thread) is to get a dynamic select working. Integration with hierarchical select can come later.
Comment #24
summit commentedHi Quicksketch,
great if dynamic select could become working. Then perfect it integration with HS would be possible!
Thanks!
greetings,
Martijn
Comment #25
hillaryneaf commentedsubscribing
Comment #26
quicksketchJust to let users know, I have absolutely no problem with a patch that enhances the existing select.inc. Also, I have no interest in personally implementing the feature. It's going to have to come from the community.
Comment #27
rgraves commentedI've added the patch from post #2 and after I added all my fields and customized all the administrative stuff for the form, I hit submit to save it. Now when I go to view my form, I get the following error:
I scanned through this page and didn't see a reference to this error. I don't see the actual function defined anywhere in the vocabulary.inc file.
Any suggestions?
Comment #28
quicksketchI think this function has simply been renamed to
_webform_filter_values()Comment #29
rgraves commentedThanks quicksketch, that solved the problem.
Like Summit, when I have multiselect enabled for the vocabulary list, the e-mail I'm receiving does not include the terms that were selected. Was this problem resolved? If it matters, I'm running version 2 of webform with Drupal 5.
Rob
Comment #30
quicksketchI don't support the vocabulary.inc provided in this issue. As I've said before in #14 and #26, I'd prefer that someone provide a patch to select.inc that simply populates a select list with a given vocabulary. I'd be willing to add this functionality to Webform directly, but most people seem content to work with whatever they find instead of actually contributing back to the project itself.
Comment #31
summit commentedHi Nathan,
I can't program it myself, but this functionality would be absolutely awesome to have with webform! Than vocabulary, and preferrebly also a list starting from a certain term or termlevel can be implemented in a webform.
The hierarchical select module has this functionality for node-support, taxonomy and content taxonomy, may be a webform widget from hierarchical select possible?
greetings,
Martijn
Comment #32
rgraves commentedThis is a total hack, but I found out how to display multiple terms in the e-mail sent by webform when the list is a multiselect list.
In the function
theme_webform_mail_vocabulary(), I changed:to
I'm not a drupal programmer, so I'm sure there's a better way to solve this, but it worked for what I need.
Comment #33
summit commentedHi Robert,
Could you post your working vocabulary.inc here please?
Is it on webform 2.0?
Thanks a lot in advance!
greetings,
Martijn
@quickscetch. I hear you. I cannot program this, but are willing to test is.
I saw that HS is postponed, because it depends on the dynamic list stuff. Hopefully someone steps in to program this.
For now a working vocabulary.inc on webform 2.0 would be ok for shortterm solution, right?
greetings,
Martijn
Comment #34
rgraves commentedHere it is. It's for webform 2.0
Comment #35
summit commentedHi Robert,
It is working, thanks!
You know what would be great, if Hierarchical Select would work with webform..
greetings,
Martijn
Comment #36
borapur commentedI am getting those warnings. It didnt desricbe the first table like xxx n
Thats why I am getting that warning and it prevents to use taxonomy in webforms.
user warning: Unknown column 'n.nid' in 'on clause' query: SELECT vid, name FROM vocabulary LEFT JOIN i18n_node i18n ON n.nid = i18n.nid WHERE (i18n.language ='en' OR i18n.language ='' OR i18n.language IS NULL) in /var/www/.../.../.../includes/database.mysqli.inc on line 154.
warning: Invalid argument supplied for foreach() in /var/www/.../.../.../includes/form.inc on line 950.
Is there another patch ? Or anything ?
Comment #37
borapur commentedOK We handled it.
Our alternations
-$result = db_query(db_rewrite_sql("SELECT vid, name FROM {vocabulary}"));
+$result = db_query("SELECT vid, name FROM {vocabulary}");
- _webform_filtervalues
+ _webform_filter_values
Comment #38
quicksketchComment #39
mnp commentedthanks for patch
but after adding that patch i added one component vacbulary then it is going blank destination page with url
mysme/?q=content/add-field-officer
same edit page but it is not going to component options page
why it is like that please tell me
it is very urgent for me
thanks in advance
Comment #40
lance.gliser commentedGood afternoon everyone.
Bugs Fixes:I've updated this widget on the behalf of emfluence LLC in Kansas City.
Please test it, and enjoy.
Form
Checkbox format: warning: Invalid argument supplied for foreach() in C:\xampp\htdocs\zupreem.com\includes\form.inc on line 1197
The problem was a default being set that was not accepted. I have commented the default on line 74 in case it is later needed.
Emails
Multiple select not being sent to in emails.
The problem was that while there was a theme hook to allow the output of custom vocabulary into the email, it was never registered.
Results
Multiple Values not retrieved in results view.
This may, or may not have been a problem to some. The visible value of fields was being stored in the database, not the posted value. So for taxonomy terms that were children --term was being stored. Which made it impossible to assign --term back as a match to the actual value of term. The database now stores the actual value of fields. *I have left the offending function: _webform_submit_vocabulary in the file, commented for historical purposes. Do not uncomment.*
Analysis
The analysis of values was failing. No information could be pulled.
Features AddedThis was another product of the incorrect storage method. It was fixed by storing the real value.
Storage Method
All taxonomy related storage is now in the database using the taxonomy ID. When output is requested, the ID's name is translated. This should make updates to your taxonomy terms not break your forms.
PlansWe need a way to control the depth, and starting parent of the taxonomy for our own purposes. I'll be getting it done tomorrow if I'm not called off.
Comment #41
quicksketchEveryone should also take a look at #406486: Allow pluggable select list values, which presents some very interesting possibilities for populating select lists with values (such as vocabularies).
Comment #42
lance.gliser commentedOk. I've been banging my head against this for a while now.
I've got it pulling in the list of terms under each vocabulary dynamically using AHAH.
Update: I'm still working on it. I found a couple of errors. The dynamic options work perfectly. Continuing on.
Comment #43
lance.gliser commentedHierarchy Limits
This release allows you to select terms to display, and a depth from them on the administration side. All reporting features still display the full, unfiltered list.
IssuesIn order for this code to work, the webform module must be altered. I have posted the above for quicksketch to look over. If he chooses to include it or not, is not up to me. While I think future developers would welcome the AHAH hooks, he has a tighter view of security than I. Until we hash out differences, and he helps optimize the code I've brute forced for his methods, you may add the alterations listed yourself, or use the two extra files attached to this comment. Please note that either method you choose to add this functionality will require you to rebuild the system's menus to recognize the webform AHAH path ("hooks"). You can do this by clearing the cache or with Devel.
It's late, and I'm getting off work. If there's bugs, leave them posted. I'll look tomorrow.
It's tomorrow, and I've found bugs. But at the developer's request, I will not be posting fixes.
Comment #44
quicksketchI'd just like to chime in and strongly discourage users from using modified versions of Webform. >:-(
lance.gliser, it'd be very much appreciated if you stopped work on the vocabulary.inc component. As I've mentioned (several times now #14, #26, and #30), this is not the way I would like this to proceed. Any users of vocabulary.inc will not receive any support from the Webform queue for any problems caused by it in the future.
Crell has proposed an alternative that I'd encourage developers to work with #406486: Allow pluggable select list values, where the select.inc component would be expanded to allow predefined lists, which could include Taxonomies, custom evaluated PHP, or any other predefined list (countries, states, etc.) This approach would allow for the same functionality as this vocabulary.inc file, only provide it with though an API and reduce the amount of duplicated code within Webform.
Comment #45
lance.gliser commentedAs you wish. I had not expected people to make a modified branch of your webform, I realize the problem with that. I was hoping we could work it together, but if this is completely off your vision, there's nothing to be done about it. Any word on importing CCK fields instead? Also:
I hope that you will at least look at the things I've written. Most of it could be ported to the solution you are suggesting.
Development StoppedAt the request of the module maintainer, this direction is abandoned.
Comment #46
lance.gliser commentedComment #47
summit commentedHi Lance,
Couldn't you work with quicksketch on altering your solution to the right scope?
It would be a shame if your effort would vanish, so please consider going forward on: http://drupal.org/node/406486 ?
hopefully you consider this!
Thanks for your effort, I am still in the need of a good taxonomy-solution with webform and it would be great if you two came up with a great one!
Greetings,
Martijn
www.trekking-world.com
Comment #48
lance.gliser commentedI have no problem at all doing that. It was my goal from the start to work with him, not create branches.
I knew that I was duplicating a lot select.inc's code from the start. However, the pieces that required custom work that have been tagged through the files are what's important. In theory, select.inc could just include a hook to load select-vocabulary.inc, and other sub select functionality. The options and renderings created by the sub selects could be output through select.inc. I have already written AHAH hooks, quicksketch could use if he wanted to enable loading in the select lists on the fly. Consider this a proof of concept, if you want. It shows what needs done for sub select functionality, somewhat. But, design changes like AHAH functionality, and sub components are global design issues. That's something quicksketch would need to decide, and layout for the rest of us to work off.
I might work on this in my spare time, but for the purposes of our current implementation, this is where we need it. My logged work hours can not be spent here.
Comment #50
unfeasible commentedSubscribe.
Comment #51
lance.gliser commentedThere is no point to subscribing to this thread as far as I know. The author fervently stated that this should go no further.
He has since put out updates for this nice module, and they are likely incompatible with the hacks developed here.
I suggest if you are interested in this kind of functionality, you go down roads he does approve of, or write your own modules to get this behavior.