Undefined index: und in taxonomy_access_form_alter() -- incorrect assignment of language key

Few questions so I can try to reproduce:

1. Which widget is being used for the taxonomy field? (Select, Autocomplete, etc.)
2. How many terms are selected in the existing nodes when you edit them?
3. Does the user that gets have administer taxonomy permissions?
4. What add tag (create) and view tag (list) grants do the users' roles have for the vocabulary?
5. Also, is this site using any specific localization? If so, what languages are being used?

Edit: Here is the line in question:

    $options = array_keys($form[$field_name][$langcode]['#options']);

'und' is the actual value of the LANGUAGE_NONE constant. So, that means that the langcode is set as LANGUAGE_NONE for this field, but $form[$field_name][LANGUAGE_NONE] is not actually set.

$langcode is from $langcodes[$field_name], which is set earlier around line 468:

  // Get active language codes.                                                                                                    
  $langcodes = array();
  foreach (array_merge($ac_fields, $o_fields) as $field_name) {
    $langcodes[$field_name] =
      field_language($entity_type, $orig_entity, $field_name);
  }

So for some reason field_language() is returning LANGUAGE_NONE but that is not actually the correct value for the field. Argh. Not sure how to troubleshoot this without a multilingual installation.

Here is some additional troubleshooting to try. You will need the devel module enabled. Starting at around line 517 of taxonomy_access.module, change this:

  // Disable options for which the user does not have create permissions.                                                          
  foreach ($o_fields as $field_name) {
    $langcode = $langcodes[$field_name];
    $options = array_keys($form[$field_name][$langcode]['#options']);

to this:

  // Disable options for which the user does not have create permissions.                                                          
  foreach ($o_fields as $field_name) {
    dpm($form[$field_name]);
    $langcode = $langcodes[$field_name];
    $options = array_keys($form[$field_name][$langcode]['#options']);

Then, visit the form that gives the error. You should see a message with a collapsed javascript element that contains the full data structure of the field item in the form. Click on it to expand it, then also expand any collapsed child elements. Take a screenshot and post it here so I can figure out what's going on inside the form array. :)

An aside, #1204230: Missing hook_field_widget_form_alter() would help us avoid this problem.

Aha! From the screenshot, there is a $form[$field_name]['#language'] key available in your field, and it matches the key of the field items list. Maybe we can check that instead of using field_language().

If that doesn't work, I found a pattern for looping through available languages in _field_invoke().

Functions where we (attempt to) handle $langcode:

• taxonomy_access_field_attach_validate()
• taxonomy_access_form_alter()
• _taxonomy_access_pre_validate()
• _taxonomy_access_extract_entity_field_items()

Really all of these should be handled in a consistent fashion, either using the elusive API functions I've yet to find, or at least using a pattern that is factored out for reuse.

Talked about this a bit on IRC with jhogdon, and it sounds like ours is not the correct use of field_language(). Places we currently call field_language():

• taxonomy_access_form_alter()
• taxonomy_access_extract_entity_field_items()

Edit: And I just remembered field_get_items() also calls field_language(), so if the latter is unreliable for our purposes, the former will be as well. It looks like we may need to go back to looping over the fields manually.

I've spent a lot of time looking into this. I found the following information in the docs for the i18n modules:

The Taxonomy translation module (part of the Internationalization package) provides multiple options to translate taxonomy vocabularies and terms. For each vocabulary you'll have to choose one of four different modes defining 'multilingual' behaviors for the vocabulary:

1. None. No multilingual options for this vocabulary (default)
2. Localize terms. Terms are common for all languages but their name and description may be localized.
3. Per language terms. Different terms will be allowed for each language and they can be translated.
4. Set language to vocabulary. The vocabulary will have a global language and it will only show up for pages in that language.

This implies that it's possible to have multiple languages per taxonomy field, and the values for the same field may even differ across languages. So, we need to handle all languages a field may have individually. Thus, using the API may not work, and we should instead loop over all possible values.

http://drupalcode.org/project/taxonomy_access.git/commit/3f1065d is a partial fix for language handling on validation. The hook_form_alter() (which causes the original issue above) still needs to be fixed.

That commit has a stray dpm('foo'); left in it.... without devel enabled, it white-screens.

Haha, fixed.

Retagging according to standard.

subscribing

subscribing

Subscribing

subscribing

I talked to Gabor about this issue yesterday. He mentioned that i18n is actually not a good model to use, and there isn't currently a UI that lets someone edit a field in multiple languages simultaneously. However, that doesn't mean there won't be one in the future, so I'm hesitant to rip out the validation refactor based on that or to use that assumption in the form alter hook.

#1232120: Improve documentation of field multiple language system is about documenting the multilingual field API generally.

NOTE: This patch requires the patch in #1204230-36: Missing hook_field_widget_form_alter().

It should resolve this issue, as well as the following issues:

• #1214660: Hide term reference field when user cannot edit it
• #1235038: Notice: Undefined offset: 0 in _taxonomy_access_form_extract_entity() on user add and edit form
• #1235248: Allow vocabulary default to control new term creation for autocomplete fields
• #1236898: Test constraints on number of values

Maybe I should actually attach the patch, eh?

Patch #23 works for me!

Fixed in http://drupalcode.org/project/taxonomy_access.git/commit/56c4402.