Call to undefined function i18n_taxonomy_allowed_values() after update

In fact I think that there's two cases.

• The first case is when I have i18n 7.x-1.3, I've enabled then disabled i18n_taxonomy -> WSOD on node edit
• The second I had enabled a previous version of i18n_taxonomy and disabled it. I update i18n and then WSOD on node edit

The first case is due to i18n_taxonomy_disable, it uses field_update_field to update the field but field_update_field uses the prior field values for 'settings' (from where i18n_taxonomy_allowed_values is called) :

// In i18n_taxonomy.install
function i18n_taxonomy_disable() {
  foreach (field_info_fields() as $fieldname => $field) {
    if ($field['type'] == 'taxonomy_term_reference') {
      unset($field['settings']['options_list_callback']);
      field_update_field($field); // <------------ First part of the problem
    }
  }
}

// In field.crud.inc
function field_update_field($field) {
  // Check that the specified field exists.
  $prior_field = field_read_field($field['field_name']);
  // ...

  // Use the prior field values for anything not specifically set by the new
  // field to be sure that all values are set.
  $field += $prior_field;
  $field['settings'] += $prior_field['settings']; // <------ Second part of the problem

  // ...
}

The second case is due to i18n_taxonomy_update_7002 that add i18n_taxonomy_allowed_values callback to the taxonomy fields even if i18n_taxonomy module is disabled. It could be fixed with a condition like if (function_exists('i18n_taxonomy_allowed_values')) :

/**
 * Switch back to real taxonomy fields and override option_list_callback.
 */
function i18n_taxonomy_update_7002(&$sandbox) {
  // Update fields only if i18n_taxonomy is enabled.
  if (function_exists('i18n_taxonomy_allowed_values')) {

    foreach (field_info_fields() as $fieldname => $field) {
      if ($field['type'] == 'taxonomy_term_reference') {
        $field['module'] = 'taxonomy';
        $field['settings']['options_list_callback'] = 'i18n_taxonomy_allowed_values';
        field_update_field($field);
      }
    }
  }
}

Actually there's a simple patch to fix that.

If the patch work, if you have the WSOD and want to get your site back without i18n_taxonomy :

1. apply the patch,
2. enable i18n_taxonomy module,
3. disable i18n_taxonomy module,
4. if you won't need i18n_taxonomy you can uninstall it.

Cool ! The patch applied in dev fix the first case described in #1. But the committed patch don't fix the second case of that issue.

Test case :

1. fresh standard install of drupal 7
2. attach a "term reference" field to "article" content type in admin/structure/types/manage/article/fields
3. add a new "article"
4. drush dl i18n-7.x-1.2
5. drush en i18n_taxonomy
6. drush dis i18n_taxonomy
7. drush dl i18n --dev
8. drush updatedb
9. edit the article created in 3 -> WSOD

Here's a possible patch on dev version.

ytsurk if i18n_taxonomy isn't uninstalled (just disabled), you can fix the issue by applying the patch to dev version of i18n and do an updatedb.

Oops ! I forgot the patch... Here it is.

And I forgot to change the status too...

This is not clear in api documentation but in my test in #17
the update is applied on i18n_taxonomy when it is disabled but not uninstalled.

If I look in drupal core code, the update_get_update_list which is called by update.php perform the update on any installed schemas :

function update_get_update_list() {
  // Make sure that the system module is first in the list of updates.
  $ret = array('system' => array());

  $modules = drupal_get_installed_schema_version(NULL, FALSE, TRUE);
  foreach ($modules as $module => $schema_version) {

    // ...
  }
  // ...
}

So it seems to me that hook_update_N() is called if a module is installed, this module can be enabled or disabled there's no check on this.