This issue is fixed and can be found in releases starting from i18n 7.x-1.12.

Issue
Fatal error: Call to a member function cache_reset() on a non-object in /home/domain/public_html/_new/sites/all/modules/i18n/i18n_string/i18n_string.pages.inc on line 402

CommentFileSizeAuthor
#20 i18n_string-2227523-20.patch800 bytessylus
#7 i18n_string-2227523-7.patch747 bytescs_shadow
PASSED: [[SimpleTest]]: [MySQL] 2,221 pass(es). View
#1 2227523.2.patch655 bytesGiorgosK
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in 2227523.2.patch. View
Membership dollars fund testing for the Drupal project. Drupal Association Learn more

Comments

GiorgosK’s picture

FileSize
655 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in 2227523.2.patch. View

it seems to be happening with any translation string

admin/config/regional/translate/edit/xxxx

and it always results to that message but the translation is actually saved

I believe there is cases that the i18n_string_get_by_lid function will not return an object
therefore I am checking for the existence of object before calling the $i18n_string_object->cache_reset()

here is a simple patch but I am not sure its the correct way to resolve this

kari.kaariainen’s picture

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

espurnes’s picture

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

patch #1 seems to work.

junetellain626’s picture

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

GiorgosK’s picture

Status: Active » Needs review

Marking as needs review
but probably the approach to solve this bug is not the right one
a maintainer needs to comment on this

Status: Needs review » Needs work

The last submitted patch, 1: 2227523.2.patch, failed testing.

cs_shadow’s picture

Status: Needs work » Needs review
FileSize
747 bytes
PASSED: [[SimpleTest]]: [MySQL] 2,221 pass(es). View

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

tompagabor’s picture

Status: Needs review » Reviewed & tested by the community

It works for me too!
RTBC then?

idebr’s picture

#7 Fixed the fatal error, thanks!

tomo738’s picture

#7 did it! Thanks a lot!

Kasper Souren’s picture

The patch in #7 worked well for me.

Jose Reyero’s picture

Status: Reviewed & tested by the community » Fixed

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

Thanks.

  • Commit 76b371e on 7.x-1.x authored by GiorgosK, committed by Jose Reyero:
    Issue #2227523 by cs_shadow, GiorgosK: Saving translation text results...
Transmitter’s picture

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

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Dret’s picture

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

Problem still exist.

slussier’s picture

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

selinav’s picture

#7 works for me.

rodrigoaguilera’s picture

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

sylus’s picture

FileSize
800 bytes

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

sonician’s picture

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

russellb’s picture

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.

gianfrasoft’s picture

#20 solved my problem. Thanks.

fazni’s picture

Thank you very much work for me ;)

jshosseini’s picture

thanks. #7 works fine for me!

chanac_hares’s picture

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 !

isholgueras’s picture

#7 works for me too. Thanks!

cs_shadow’s picture

@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.

chanac_hares’s picture

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

apermuy’s picture

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

TwiiK’s picture

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.

Maxam’s picture

#7 has been worked , thanks for solving !

Alan D.’s picture

Title: saving translation text results in error » Fatal error: Call to a member function cache_reset() on a non-object in i18n_string.pages

Changing title so the issue is easier to locate.

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

ThuleNB’s picture

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?

GiorgosK’s picture

@ThuleNB
this is a closed (fixed) issue
so the patch should be included in the june DEV version
try that

nimek’s picture

patch from #20 solved my issue
+1 for commit

Alan D.’s picture

patch is included in the june DEV version

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

GANYANCI’s picture

howdytom’s picture

Any plans for release date which includes the bugfix?

Can't agree more with TwiiK and ThuleNB

jsheller’s picture

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

russellb’s picture

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.

francescosciamanna’s picture

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

GiorgosK’s picture

Guys read to the end of the issue queue issue has been fixed so its included at least in the latest dev release try that instead of manually patching

Kimitri’s picture

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?

ressa’s picture

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

GiorgosK’s picture

@ressa we are passed RTBC, its already fixed and closed
use dev version until a full version is released

ressa’s picture

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

GiorgosK’s picture

@ressa try .dev version in a test environment and if you get no problems with it use it on your live site
I use .dev version for major modules all the time with no problem

kerios83’s picture

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

ressa’s picture

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.

dob_’s picture

@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!!!!!!!!!

Anybody’s picture

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!

hosais’s picture

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

GiorgosK’s picture

@hosais
this bug its not related to resources (definitely) so it must me a coincidence

about dev releases:
I use dev releases all the time usually to fix bugs when there is no official release fixing them
you can pretty much trust dev releases when it comes from modules such as i18n that have a lot of installs because a possible problem will be reported fast

anyway I would test on a test installation first and if it does not appear to have any problem I would install it on the production install, the next realese of i18n will come from the existing dev release so you have nothing to worry about

take a look at the release usage stats for the dev release to make up your mind
https://www.drupal.org/project/usage/i18n

Alan D.’s picture

Issue summary: View changes

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

hosais’s picture

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

hosais’s picture

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

yogaf’s picture

Issue summary: View changes
Nobru’s picture

#7 works like a charm. Thanks a lot !

moertle’s picture

#7 solved the issue. Thanks!

Alan D.’s picture

Issue summary: View changes

Making the message even clearer in the summary ;)

harshadananjaya’s picture

#7 works for me.
Thanks..!

ilclaudio’s picture

#20 works for me thanks