PHP Fatal Error Call to undefined method i18n_object_wrapper::strings_update()

Sylvain_G, can you please specify when this error appeared? During installation/clearing caches/common use of site/...?

I'm not using this core patch but still have this error. Trying to track it down now. @Sylvain_G, are you also using rules_i18n?

Still an issue for me, Drupal 7.26, i18n version = "7.x-1.11", here is the list of the dependencies in my installation profile.

dependencies[] = i18n
dependencies[] = i18n_field
dependencies[] = i18n_hreflang
dependencies[] = i18n_node
dependencies[] = i18n_path
dependencies[] = profile2_i18n
dependencies[] = i18n_redirect
dependencies[] = i18n_select
dependencies[] = i18n_string
dependencies[] = i18n_sync
dependencies[] = i18n_taxonomy
dependencies[] = i18n_translation
dependencies[] = i18n_user
dependencies[] = i18n_variable
dependencies[] = i18nviews
dependencies[] = xmlsitemap_i18n

Core is not patched.

More information on this bug. I was getting issues with this when I was using Drupal 7.28 as opposed to Drupal 7.29. Upgrade to Drupal 7.29 fixed this issue for me. My error was similar but the method it was looking for was strings_remove. More below:

Call to undefined method i18n_object_wrapper::strings_remove()

We are seeing this during UI-based installations of our profile. Using latest i18n and Drupal 7.34

Drush-based (drush si) installations are not affected.

This patch should prevent errors but I don't know enough about i18n_string to determine if this is a real fix or merely a work-around.

We do still have this issue for i18n 7.x-1.11 !!

I had add some more conditions to make sure we get the correct objects/values.

And there is a rules_i18n part to it, I've attached it to the related issue.

Related issue: https://www.drupal.org/node/2410729

The patch worked for me. Thanks.

Worked for me too.
I tested it manually and reviewed the code and everything looks ok.

This may work but I think the patch just hides the error, not really fixing it. The question is why are we getting an invalid object there in the first place?

Some more background on the issue:
- i18n_object() should get back some wrapper for objects handled/translated by i18n/i18n_strings
- For objects having associated 'textgroups', that is the ones that should be able to use i18n_strings API, those have a strings_update() method and some others.
- it seems in this case i18n_strings is used on objects that don't define the proper i18n API and this should never be the case.

I know the code is somehow lacking and the proper way to do this is maybe using some interfaces, etc.. However the question here is: why are we invoking i18n_strings' methods on objects that don't support them? which kind of objects are those?

Or maybe.. is it happening only on installs because such object is not defined yet? (then defaulting to i18n_object_wrapper which doesn't implement these strings callbacks)

So, once we understand the issue, ok to some workaround but otherwise we may be just hiding a bug somewhere else.

This may work but I think the patch just hides the error, not really fixing it. The question is why are we getting an invalid object there in the first place?

100% agree as the original author of the patch. I simply wrote it to work around and I needed a place to upload the patch so I could include it in a make file.

This may be related to #1681414: Enabling i18n modules fail in install profile

The problem that i had before applying the patch happened when i updated a module (using drush) who needed do translations. Could the calling of the function fails because the Drupal bootstrap it's not executed?

Trying to apply #13:

git apply i18n_string-undefined-method-2082573-13.patch          
warning: i18n_string/i18n_string.module has type 100644, expected 100755 

@lsolesen according to the test it applies to 7.x-1.11

It should apply to the dev version

Patch worked. PLEASE commit. This breaks the whole update queue, I could not do any drush updb...

Patch works for me too!

As mentioned in #5 I was able to upgrade after clearning my caches, so it might be a caching issue?

@Isolesen: Also cleared my caches and it did not help me. I had to apply the patch.

Same for me. No caching problem...

@axe312,
Please do read the thread, specially #18 and #19 before moving this to RTBC..

I mean, absolutely NOT RTBC

I am getting the same error in one of my update_hooks when I run the update from drush. If I run the same update vie web-browser it works. My update-function looks like this:

function mut_deploy_update_7051() {
  menu_delete_links('main-menu');
}

Maybe this helps to narrow down the problem.

Patch works for me.

Some things I found out.
I have tested it on two environments. 1 Staging and 1 local in a vagrant box.
The staging had no problem even without the patch, but the vagrant one needed the patch. Maybe it has something to do with server configuration?

Patch saves the day for me too. In my case, I was getting this error persistently after running a hook_update_N() which deleted a View which had a page display with a menu link.

Patch worked for me also.

I had this error after I pulled a production database down to my local to study a problem. Turns out I just need to run "drush cc all". That fixed the problem.

i am tried including patch files but no use its still throwing same error can any one help in this case i am tring to install through drush
where iam geting this error

trying to apply #13 its showing this error

error: patch failed: i18n_string.module:860
error: i18n_string.module: patch does not apply

I have a gut feeling about this. What if several modules are enabled but the static i18n_object_info() cache is outdated then. Clearing it in hook_modules_enabled would help then.

EDIT: this is exactly what is currently done. ;-)

Yes my gut feeling was right, but this was way more complicated and the hardest debugging i can remember.

Patch flying in that clears all necessary static cachings.

I had this error on two multilingual websites with i18n version 1.13. It's pretty nasty because it gives a WSOD.

Strangely, I could avoid the error by updating the contrib modules in the interface and updating drupal with drush up drupal.

Patch in #40 did not help when calling menu_link_delete() inside hook_update_N().
Although clearing cache (drush cc all) before did.

The idea in patch #40 looks good to me.

Actually the solution should be this core patch, but it may take time so we can commit something in the meanwhile, #1891356: D7: Reset drupal static caches when a module is enabled or disabled.

Could we get the same with less code, adding the i18n_object_info_cache_clear() call inside i18n_string_refresh_enabled_modules() (i18n_string.admin.inc?)

About the menu item issue (#42), it may be a different problem, maybe coming form i18n_menu_menu_link_delete().

If someone could post a full backtrace instead of only the error message....

Not working...

#13 is the only patch that helps to unblock our automated upgrade paths.

Here is a backtrace after calling _og_menu_default_links_set_default_links() from inside hook_update_N():

Fatal error: Call to undefined method i18n_object_wrapper::strings_remove() in /vagrant/www/sites/all/modules/contrib/i18n/i18n_string/i18n_string.module on line 839

Call Stack:
    0.0003     224024   1. {main}() /home/vagrant/.composer/vendor/drush/drush/drush.php:0
    0.0003     224208   2. drush_main() /home/vagrant/.composer/vendor/drush/drush/drush.php:11
    0.1041    2458952   3. Drush\Boot\DrupalBoot->bootstrap_and_dispatch() /home/vagrant/.composer/vendor/drush/drush/drush.php:71
    0.6247   10408584   4. drush_dispatch() /home/vagrant/.composer/vendor/drush/drush/lib/Drush/Boot/DrupalBoot.php:68
    0.7510   13076320   5. call_user_func_array() /home/vagrant/.composer/vendor/drush/drush/includes/command.inc:178
    0.7510   13076896   6. drush_command() /home/vagrant/.composer/vendor/drush/drush/includes/command.inc:178
    0.7512   13078208   7. _drush_invoke_hooks() /home/vagrant/.composer/vendor/drush/drush/includes/command.inc:210
    0.7568   13137816   8. call_user_func_array() /home/vagrant/.composer/vendor/drush/drush/includes/command.inc:359
    0.7568   13138288   9. drush_core_updatedb_batch_process() /home/vagrant/.composer/vendor/drush/drush/includes/command.inc:359
    1.2810   13460376  10. _update_batch_command() /home/vagrant/.composer/vendor/drush/drush/commands/core/core.drush.inc:1143
    2.8928   19369288  11. drush_batch_command() /home/vagrant/.composer/vendor/drush/drush/commands/core/drupal/update_7.inc:242
    2.8942   19370280  12. _drush_batch_command() /home/vagrant/.composer/vendor/drush/drush/includes/batch.inc:90
    2.8944   19376400  13. _drush_batch_worker() /home/vagrant/.composer/vendor/drush/drush/commands/core/drupal/batch.inc:101
    2.9061   19412496  14. call_user_func_array() /home/vagrant/.composer/vendor/drush/drush/commands/core/drupal/batch.inc:149
    2.9061   19412544  15. drush_update_do_one() /home/vagrant/.composer/vendor/drush/drush/commands/core/drupal/batch.inc:149
    2.9063   19414136  16. mms_group_update_7100() /home/vagrant/.composer/vendor/drush/drush/commands/core/drupal/update_7.inc:73
    2.9141   19416272  17. _og_menu_default_links_set_default_links() /vagrant/www/sites/all/modules/custom/mms_group/mms_group.install:20
    2.9188   19582712  18. menu_link_delete() /vagrant/www/sites/all/modules/patched/og_menu/contrib/og_menu_default_links/og_menu_default_links.module:110
    2.9190   19588144  19. _menu_delete_item() /vagrant/www/includes/menu.inc:3030
    2.9190   19588240  20. module_invoke_all() /vagrant/www/includes/menu.inc:3064
    2.9192   19593072  21. call_user_func_array() /vagrant/www/includes/module.inc:895
    2.9192   19593488  22. i18n_menu_menu_link_delete() /vagrant/www/includes/module.inc:895
    2.9192   19593576  23. i18n_string_object_remove() /vagrant/www/sites/all/modules/contrib/i18n/i18n_menu/i18n_menu.module:280

Workaround here is to call drush_cache_command_clear('all') before _og_menu_default_links_set_default_links().

Might be some help to others finding this issue...

I was encountering the above error message while installing from a custom profile but none of the above workarounds using drupal_static_reset were helping. I debugged the i18n_object and found that it was related to webforms, but I didn't have the webform module enabled! Eventually I found that I had a feature that defined some field_bases and field_instances on the webform bundle, but that feature was missing 'dependencies[] = webform' from its .info file. After I added the dependency the error went away.

I get a similar error which might be related:

PHP Fatal error:  Call to undefined method i18n_object_wrapper::strings_remove() in /abc/sites/all/modules/contrib/i18n/i18n_string/i18n_string.module on line 839

Running drush cc all does not fix this but running drush rr does.

The code that causes this is an update hook similar to this (needs the my_vocab vocabulary this case):

function abc_taxonomy_update_7001() {
  _abc_taxonomy_revert_feature();
  $terms = array(
      'Current' => array(
        'zh-hans' => '现行有效',
        'zh-hant' => '現行有效',
        ),
      'NA' => array(
          'zh-hans' => '失效',
          'zh-hant' => '失效',
          ),
      'Not Current' => array(
          'zh-hans' => '失效',
          'zh-hant' => '失效',
          ),
      );
  _abc_taxonomy_create_terms('my_vocab', $terms);
}

function _abc_taxonomy_create_terms($vocab_machine_name, $vocab_terms) {
  $vocabs = taxonomy_vocabulary_get_names();
  $vocab = $vocabs[$vocab_machine_name];
  foreach ($vocab_terms as $vocab_term => $vocab_term_translations) {
    $term = new stdClass();
    $term->name = $vocab_term;
    $term->vocabulary_machine_name = $vocab_machine_name;
    $term->vid = $vocab->vid;
    taxonomy_term_save($term);
    if (!empty($term->tid)) {
      // Add translations for the term name.
      foreach ($vocab_term_translations as $langcode => $vocab_term_translation) {
        $i18n_string_name = array('taxonomy', 'term', $term->tid, 'name');
        i18n_string_translation_update($i18n_string_name, $vocab_term_translation, $langcode, $vocab_term);
      }
    }
  }
}

function _abc_taxonomy_revert_feature() {
  if (function_exists('features_revert_module')) {
    features_revert_module('abc_taxonomy');
    // Check it actually is in default state now.
    module_load_include('inc', 'features', 'features.export');
    if (function_exists('features_get_storage')) {
      $storage = features_get_storage('abc_taxonomy');
      if ($storage === FEATURES_DEFAULT) {
        drupal_set_message(t('Reverted abc_taxonomy module.'));
        return;
      }
    }
  }
  // There was an issue reverting the module.
  throw new DrupalUpdateException(t('Unable to revert abc_taxonomy module.'));
}

After running the drush updb, the fatal error shows up when I do other things (e.g. drush cc all). Once I run drush rr, it sorts itself out and then I don't get the fatal error anymore. Note that the patch from #40 did not fix my problem but I'm not enabling/disabling a module. It is a Features module that gets reverted so I assume it has something to do with that.

The only thing that worked for me to enable a module (feature) that was editing custom menu_links was patch #13. The error was firing at
menu_link_save($mod_link);
And nor patch #40 nor clearing cache worked. What always worked, without any patch was enabling the feature for second time. Since the feature had all the i18n dependencies, they got installed at the same time. But if they were already installed, it looks that I could avoid this error.

This patch is for version 1.12 of the module

Found this error too, not sure about the ultimate cause but I think it was adding fields through features, using features-revert-all...

Anyway, cleaned up the error by running: drush cc registry

Then drush cc all, etc... error gone.

drush rr fixed it for me.

This patch is for version 1.13 of the module

Hello,

I made a small correction in the previous patch.
There was still the old drupal_static_reset('i18n_object_info'); in i18n_modules_enabled().

The patch is applicable on the version 1.13 and the current dev version.

@Jose Reyero,

From your last comment, can I conclude that the logic as implemented in the patches since #40 did not work for you?

Oops, I forgot to attach the patch to my previous ticket.

Patch working for me