Closed (fixed)
Project:
Taxonomy Defaults
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
27 May 2010 at 12:20 UTC
Updated:
28 Dec 2010 at 15:10 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
bradweikel commentedRolf -- Apologies for the mundane questions, but I just want to bounce this back to you for some clarifications before I try to reproduce this. A few questions:
Were you able to verify that this was triggered by the D6.16 upgrade?
Did you also upgrade Taxonomy Defaults module at the same time? If so, did you manually update your "hidden vocabs" by assigning the vocabularies to the appropriate content types? Prior to beta2, a hidden taxonomy with defaults was accomplished by NOT assigning it to a content type and then marking it Active in the Taxonomy Defaults settings. This created all sorts of bugs with form validation and compatibility with other taxonomy modules, so in beta2 I flipped the logic: you have to assign the taxonomy to the content type and mark it Hidden in the Taxonomy Defaults settings. The upgrade path, however, was less than ideal, so if I recall you have to manually assign the hidden vocabs to appropriate content types to get them working again when upgrading to beta2.
Finally, have you tried the latest 6.x-1.x-dev to see if that resolves it? There were a few minor bugs that got fixed right after beta2 was released that could be related.
Let me know. I'm moving in a few days, so this is probably the best assistance I can offer until life settles down in mid June.
Comment #2
rolfmeijer commentedHi Brad,
No problem, it’s not mundane at all.
No I wasn’t able to verify this was triggered by the D6.16 upgrade, I was just trying to figure out what had been changed since the last time TD did work properly.
No, I did not upgrade Taxonomy Defaults at the same time.
Yes, I did test in 6.x1.x-dev (the one from 19 April) but the results were the same.
Some other thing I only noticed now, when changing the hide-option I got this error message:
So could it be related to #778972: Taxonomy Defaults: Invalid argument supplied for foreach() - line 91?
Thanks for your time, I hope your life settled down properly by now ;-)
Comment #3
tahiticlic commentedHi there,
same problem with D6.17 and Taxonomy Defaults 6.x-1.x-dev
Comment #4
tahiticlic commentedAround lines 95 and 111 of taxonomy_defaults.module, remove the test :
That will correct the error.
Comment #5
NiklasBr commented#4 does not solve this issue on the one of my sites that is hit with this bug.
Comment #6
tahiticlic commentedHave you replaced both lines 87 and 96 (last dev version 10 juil)? I've not tested with this version but I guess the problem is the same.
Comment #7
NiklasBr commentedI did so on 11 Jul, ran update.php, cleaned caches and manually ran cron without solving the issue.
Comment #8
bradweikel commentedJust a quick heads up that I plan to do a little bug bash on Sunday afternoon, and this issue is among the first I'll look at. Apologies for my lax maintenance.
Comment #9
Shadlington commentedSubscribing.
Comment #10
Anonymous (not verified) commentedI have the same problem, I also tryed to comment the lines according of #4
Comment #11
dboulet commentedI think that this error pops up when editing a node that was created before the taxonomy defaults were set. Please test this patch.
Comment #12
NiklasBr commentedTried your patch but it did not work
Drupal 6.19
PHP 5.2.12
Comment #13
bradweikel commentedI've given it my best effort, but I cannot produce this error. I'm going to need someone to provide better steps before I can fix it. Are there other taxonomy modules involved? Specific taxonomy settings (ie free tags, multi select, hidden, etc)?
Comment #14
NiklasBr commentedThe site these modules installed and activated:
Boost 6.x-1.18
Colorbox 6.x-1.0-beta7
Content Construction Kit (CCK) 6.x-2.8
FileField 6.x-3.7
Google Analytics 6.x-3.0
jQuery Update 6.x-2.x-dev (2010-sep-09)
Taxonomy Access Control 6.x-1.2
Taxonomy Defaults 6.x-2.0
Token 6.x-1.15
Transliteration 6.x-3.0
Vertical Tabs 6.x-1.0-rc1
Views 6.x-2.11
Wysiwyg 6.x-2.x-dev (2010-nov-14)
The taxonomy that is not working is
• Forums (from the core forum module), the forum taxonomy has a hidden default term that is set to one of the forum terms.
• News (a standard node that goes on the front page), the news node type has one exposed taxonomy default term (published for everyone and published for members).
• Page (the standard static page supplied by core installation), has two exposed taxonomy default terms, one is the same as the News nodes, the other is a multi-choice from a third taxonomy.
None of the taxonomies have siblings/metonyms and are all non-hieraichal.
Boost and Cache has been turned off for the sake of testing, watchdog provides no clues either.
Disabling Taxonomy Defaults makes editing and everything else go back to normal, enabling it prevents node editing but not creating new nodes.
Comment #15
bradweikel commentedThanks NiklasBr.
Are all three categories broken in the same way described at the top of this issue (the "illegal choice" message), or are they behaving differently?
The Forum issue is probably this: #573778: Taxonomy Defaults breaks forum module's ability to pre-select terms
For the others, it could be a conflict with Taxonomy Access Control. See #851648: Wrong taxonomy_defaults weight? and consider setting Taxonomy_Defaults' weight to be greater than TAC's.
Let me know.
Comment #16
brianmercer commentedI reproduced this on a fresh system. It only happens if the taxonomy vocabulary is "Required" and is hidden.
Create fresh install. (pressflow-6.19.96 for me) Add a vocabulary with two terms. Check "required" for the vocabulary and enable it for the story type. Enable taxonomy_defaults-6.x-2.x-dev. Go to taxonomy default page and select one of the two terms and also select hidden for the story type. Create a new story node and save it. Now edit the story, change the body text and try to save..."An illegal choice has been detected. Please contact the site administrator."
Temporary workaround: Uncheck "Required" (not such a great solution)
EDIT: I tried the patch at #11 and it applied to the latest dev and seems to solve the problem.
Thanks.
Comment #17
bradweikel commentedCommitted a similar but more robust patch. Thanks @brianmercer for providing clear steps and at @tahiticlic for the code suggestion.
Comment #18
ErikAllen commentedI'm getting this same error... however, mine is probably for a different reason.
I had previously created a HUGE webform (over 150 questions) for an online in-depth application for a client. I actually ended up doing 2 of them. So when my client said they wanted the same applications on another website I did for them... I was at a loss as to how to get the info over without having to redo them again. After doing some poking around, I found that NODE_EXPORT was probably my best bet. So I installed the module on both sites, exported the webform in question on site #1 and then imported it on site #2. After finishing it off and hitting SAVE... I was presented with this error:
"An illegal choice has been detected - please contact the site administrator"
For some reason I couldn't "save" the info without this error showing up. However, when I hit the VIEW tab, everything looked fine. I went into another browser and checked out the page without logging in. Page looks fine, but I have this error at the top of that page:
"warning: Invalid argument supplied for foreach() in /home/content/91/5081491/html/aymschoolconnection.com/sites/all/modules/webform/webform.module on line 2626."
Now what's weird, is that I don't get the second error while logged in... only as an anonymous user.
Any thoughts as to how I can fix this? I'd REALLY like to avoid having to remake these webforms.
Erik
Comment #19
bradweikel commentedErik - unless you are using the taxonomy_defaults module (which you don't mention), then you should take this to the webform module's issue queue. I see a number of form validation bugs there, so perhaps yours is a duplicate of one of them.
Comment #20
ErikAllen commentedFair enough... thanks.