Pass variables to 'Advanced PHP Code'

My solution, FYI, is to add to the parent php box this:

if ($_POST['field_major']['value']) {
  return $_POST['field_major']['value'];
}else{
  return $field['parent'];
}

That gets the value of the major tag from the $_POST variable at submit time, which when the autotag runs. The other time it is used is for the autocomplete string. At that time it uses the default value as the $_POST doesn't have the major field. At least this way it doesn't come with suggestions from the major vocab. Ideally it should suggest from the child terms but that would mean knowing field_major value and I could see a way to do that.

I think this should be re-labelled as bug since even though the widget allows php to select the parent there is next to nothing the php can do. If however the form_state had been passed to the check parent routine then the php could access any of the other values. As it stands the php has no variables to work with.

Hi,

Well, it would be nice to more powerful. Input validation is one thing but this the parent so if you can't compute it then it may as well just be a fixed value. OK, you can compute it a bit. I did look at the globals and the comment above is a sort of fix. I got lost trying to understand it. I think I need to know more about FAPI. What is needed is the $form_state to be passed down to content_taxonomy_field_get_parent as well as the field. That way it could use the previous form values.

And/or it might be better to have auto complete as optional. At least that way the user is not confused by autocomplete suggestions from the wrong parent. I can sort of do that with the fix above if default points to an empty parent (perhaps an invalid might also work and not throw an error, I haven't tried that, 0 gives the root though, any the rotator would still go round).

BTW another suggestion, would be to have a defined list or defined not list for free tagging. And php. So much like plain text field. That way you define a list of allowed possible values that would be put into a vocab but not have them in the vocab until they were used. This would keep vocabs smaller and not full of empty entries. Making that the inverse would give a not list which would stop unsuitable free tags (e.g. impolite words).

I did consider the route of plain text fields, one as a defined list for major vocab and one as free for free tagging and then using computed field as in this http://drupal.org/node/297030 . But it seems a shame to go to that much effort for less return when this module is almost ideal.