Fatal error: Call to a member function cache_reset() on a non-object in i18n_string.pages

I got the same error. The patch at #1 helped.

I get the same error.
i18n 7.x-1.10+14-dev installed

patch #1 seems to work.

Also using i18n 7.x-1.10+14-dev and above patch solved the issue.

Attaching properly formatted patch according to the idea suggested in #1.

It works for me too!
RTBC then?

#7 Fixed the fatal error, thanks!

#7 did it! Thanks a lot!

The patch in #7 worked well for me.

Committed, just a slightly different form, http://drupalcode.org/project/i18n.git/commit/76b371e

Thanks.

Thank you very much for the patch in #7 - it worked well for me.

Same problem for me on 7.x-1.11 and Drupal 7.28.

Problem still exist.

Me too... Same problem i18n 7.x-1.11 and drupal 7.28

#7 works for me.

This marked as fixed means it'll be in 1.12 (yet to be released) if this is bug bothering you use 1.x-dev or apply the patch to your version

Created a patch based on recent commit for drush make purposes since can't reference a patch format from drupalcode repo.

When applying any of the patches, I get

Parse error: syntax error, unexpected end of file in ../sites/all/modules/lang/i18n/i18n_string/i18n_string.pages.inc on line 449

Hi sonician, this is fixed in 1.x-dev so you may not need to apply the patch.

You should just be able to download 7.x-1.x-dev and use that, which contains the fix.

#20 solved my problem. Thanks.

Thank you very much work for me ;)

thanks. #7 works fine for me!

Hi,

First excuse me for my bad english !

Somebody can advise me please, i had the same probleme, and i fixed it like that :

• I Create a custom module my_custom_module
• I implement on my new custom module the hook module_implements_alter for ensure me that my_custom_module_hook_form_alter will be the last to be call
  

  /**
   * Implements hook_module_implements_alter().
   */
  function my_custom_module_module_implements_alter(&$implementations,
      $hook) {
  
    switch ($hook) {
  
      case 'form_alter':
  
        if (array_key_exists('my_custom_module', $implementations)) {
          $my_module = $implementations['my_custom_module'];
          unset($implementations['my_custom_module']);
          $implementations['my_custom_module'] = $my_module;
        }
  
        break;
    }
  
  }
  
  

• I implement on my new custom module the hook form_alter for unset the submit fonction added by i18n_string module and added my own submit function.

  
  /**
   * Implements hook_form_alter().
   */
  function my_custom_module_form_alter(&$form, &$form_state, $form_id) {
   
    if ($form_id == 'i18n_string_locale_translate_edit_form') {
     
      if (!empty($form['#submit']) && $form['#submit'][0] == 'i18n_string_locale_translate_edit_form_submit') {
        array_shift($form['#submit']); // we unset the i18n_string submit function
        array_unshift($form['#submit'], '_custom_i18n_string_locale_translate_edit_form_submit'); // we add our own submit function
      }
    }
  
  }
  

• And we call in our submit function the same code from the i18n_string submit function plus the patch #7
  

  
  /**
   * Custom fonction submit.
   */
  function _custom_i18n_string_locale_translate_edit_form_submit(&$form, &$form_state) {
  
    // Invoke locale submission.
    locale_translate_edit_form_submit($form, $form_state);
    $lid = $form_state['values']['lid'];
    $i18n_string_object = i18n_string_get_by_lid($lid);
  
    
    // https://www.drupal.org/node/2227523 patch #7.
    if (is_object($i18n_string_object)) {
      $i18n_string_object->cache_reset();
    }
  
    foreach ($form_state['values']['translations'] as $key => $value) {
      if (!empty($value)) {
        // An update has been made, so we assume the translation is now current.
        db_update('locales_target')
        ->fields(array('i18n_status' => I18N_STRING_STATUS_CURRENT))
        ->condition('lid', $lid)
        ->condition('language', $key)
        ->execute();
      }
    }
  
  }
  

Somedy knows what is the best way between apply the patch directly on i18n_string module or avoid the patch by my way ?

Thanks in advance !

#7 works for me too. Thanks!

@chanac_hares, it's generally a bad practice to apply custom patches on core/contrib modules directly. Also, such custom patches cause a big problem while updating the modules and hence its a strict no-no to applying any custom patch to a module. I'm not entirely sure if your way is the best way to solve your problem, but it's certainly better than applying a patch to i18n_string module.

@cs_shadow ,
Thx for your response, you reassures me ! But if you know one third solution, i will take it !

The patch in #7 worked for me too. Thanks guys!

How can a fix like this not result in a new release version immediately?

The recommended version for this module, which by the way has a reported 150k installs, is completely 100% broken at the moment. I downloaded it, installed it and encountered this fatal bug within minutes.

Drupal has to get new practices for minor versions. Having to install the dev version for every single contributed module because the recommended release has many unfixed bugs is a stupid practice.

#7 has been worked , thanks for solving !

Changing title so the issue is easier to locate.

Is a new version close to being tagged up and released?

Some problem here. What can I do? I don't know how to apply a patch :-(. Will the patch go in a new release soon?

patch from #20 solved my issue
+1 for commit

patch is included in the june DEV version

So maybe time for a new version to be tagged :)

https://www.drupal.org/node/2227523#comment-8838687
patch #20 worked for me. Thanks.

Any plans for release date which includes the bugfix?

Can't agree more with TwiiK and ThuleNB

Thanks for patch #20. Worked for me, too.

Hi, my understanding is that this José committed a fix for this issue - see #12 - so you might like to test latest dev. rather than patching here.

#20 fixed my my issue too (I am translating between Chinese and English). Thx again

Nice that this finally got fixed. It would be even nicer, though, if this fix got to the actual release version of the module. Any idea on when the next release version is expected to land?

I can confirm this fixes the "PHP Fatal error: Call to a member function cache_reset() on a non-object". RTBC?

@GiorgosK you are correct, what I meant was if the dev version is ready to be released as a full version.

I want to confirm that dev version (which have this issue fixed) is working well.

Thanks for the suggestion @GiorgosK. I am already using the dev version, and it works great. I just prefer to use the official realease, in case of future updates, so I don't need to keep track of why I use dev version of this of that modules.

@TwiiK I totaly agree with you. Drupal is a quite unstable ecosystem. It's such a buggy system that we already started developing a node.js based CMF. That shows how frustrated we are with the system at the moment regarding scalability and stability. This bug is the last straw which breaks the camel's back.

If it's fixed and tested RELEASE a working version. It can't be true that the community has to install DEV versions to be able to use Drupal with i18n!!!!!!!!!

I totally agree that we need a new stable release ASAP. It's bad that the stable version is broken and it's not a good idea to use DEV in production...
Thanks a lot!

Hi,

In my local PC (aquia drupal dev), drupal does not have this issue. When I move it to openshift, there are this issue. Is this related to memory resource? Could anyone explain the risk of using dev verion in this case? (in production site of course).

If we dont use dev version, what would happen? Anyone has experience about this?

hosais

Updated the summary to let users know how to handle this issue to avoid the need to repetitively post here ;)

Thank you for your quick comments, GiorgosK.

Just would like to clarify something.

The error in my site currently is about translating the Password Reset form online (not Email. you know, the user click the email link and then go to the web site. And at this moment, the English form show up).

It seems that these forms will disappear after a while. Do you think this is the problem? The way I translate this kind of form is not the right way?

I would really appreciate you give me some brief comments about this.

Thank you again.

hosais

By the way, FYI

I checked the code. The only difference is do the code below or not.
$i18n_string_object->cache_reset();

I suppose the cache would be release in the end no matter what. I patch right a way since to me Fatal error may has higher risk.

hosais

#7 works like a charm. Thanks a lot !

#7 solved the issue. Thanks!

Making the message even clearer in the summary ;)

#7 works for me.
Thanks..!

#20 works for me thanks