This is the error I get when using the latest dev version of taxonomy defaults.

warning: Invalid argument supplied for foreach() in /sites/all/modules/taxonomy_defaults/taxonomy_defaults.admin.inc on line 91.

It still sets the term though . . . I think it's because a couple of my vocabularies are free-tagging.

Comments

echoz’s picture

I also get this error with the dev version from Jul 11. I'm not using free tagging like the above poster.

I had tested 6.x-1.0 and could not get it to hide the select on the node create/edit form, nor have the setting stick to any but one. I uninstalled and made sure both places it wrote to the database were deleted (system, for the module record + variables, for the weight, which the uninstall takes care of).

The dev version works otherwise so far, with hiding and making a default. Reloading the defaults pane is free of errors, but resaving shows the errors.

mpotter’s picture

I am also getting this error with the latest dev version. I am not using any free tagging.

The issue seems to arise from having multiple node types that you do not select any default for. As mentioned above, the errors only happen during Save Configuration and don't seem to prevent anything from working.

Just before the

foreach ($form_state['values'][$type] as $vid => $values) {

on line 91, I added this line:

if (is_array($form_state['values'][$type])) {

and then added the closing } on line 121. This seemed to fix the error. Sorry I don't have an official patch format for this.

echoz’s picture

I ended up creating a solution using the Content Taxonomy module, since already using it. Making taxonomy a cck field gives the option of Default value. Posting if this might be a helpful idea for others.

Andrew Gorokhovets’s picture

the same problem

NiklasBr’s picture

I had this problem with 6.x-1.0 and tried to update to 6.x-1.x-dev (2010-Jul-11) but the issue still persists.

momper’s picture

Title: Invalid argument supplied for foreach() - line 91 » Taxonomy Defaults: Invalid argument supplied for foreach() - line 91

same situation #2 seems to fix the problem ...

is this module still maintained? since april this problem ...

vanbot’s picture

someone found a solution?

NiklasBr’s picture

Priority: Normal » Major

I want to echo momper's question, is this module maintained?

ergophobe’s picture

mpotter - that's not quite right

The problem arises because node_get_type() gets all content types. However, if you have a content type that is not in a vocabularly, it will be in the array returned by node_get_type(), but there won't be any value for it.

So in my case, the Page type is not in a vocabulary. This means that

$form_state['values']['page'] is empty, so it fails when it attempts to run the foreach and that variable is empty, when it needs to be an array.

So the value has to be checked first to see if it's empyt, then to verify that it's an array.

Rather than nesting the whole thing in an if{} I think it's easier to read/maintain if you test for the failing case (is empty or isn't an array) and then use "continue" to skip.

So the new code would look like this for lines 90-92 (the old lines 90-91)

foreach (node_get_types() as $type => $name) {
    if (empty($form_state['values'][$type]) || !is_array($form_state['values'][$type])) {continue;}
    foreach ($form_state['values'][$type] as $vid => $values) {

That way it doesn't process node type that have no vocab associated with them.

I can provide a patch, but since it's one line, it's probably easier for most people to just insert it into taxonomy_defaults.admin.inc

bradweikel’s picture

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

Fix committed. Thanks @ergophobe for the clear steps and recommended fix.

ergophobe’s picture

Thanks Brad!

So the November sprint has happened. Glad to hear it and hope you're not too bleery-eyed from days of wading through CVS!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.