Multiple issues with i18n variables: wrong multilingual variables, cache rebuild, etc..

@patrick2000

Please take a look at #903658: i18n_variable_init() / _i18n_variable_init() causes full menu rebuild on every page hit to see if the issue described there can help you simplify your scenario or if are totally different. Anyway I'm pretty sure both issues are related.

Best regards

MyXelf

Yes, it seems after latest update, wrong variables are marked as multilingual and also the cache is rebuilt too often.

This patch seems to fix part of the problem. I think we need also to do some clean up of variables previously marked multilingual by mistake.

Working on this atm, will do a new release as soon as I get this fixed.

Thanks

subscribing

Marked #904914: Latest 6.x-1.x-dev (2010-Sep-05) and stable release 6-1.6 breaking/disturbing cron as a dupe. (i.e. subscribing)

Committed a tentative fix, including the patch here, and some other improvements.

Let me know whether this fixes the issue.

This is supposed to fix the cron run issue described here as well: #904914: Latest 6.x-1.x-dev (2010-Sep-05) and stable release 6-1.6 breaking/disturbing cron (marked as a duplicate of this one)

Well, the latest dev doesn't seem to fix it.

Yes, the cron issue persists. It even got worse for me. Now I get the green message "Cron run successfully" in one language but the status report in this language doesn't notice that cron ran (see attached pic). In the other language cron just fails and of course the last date cron ran from this language is noted.

Same here. 'Cron run successfully' ...yeah right. 4 days ago ;)

It looks like the problem is fixed, though the aditional multilingual variables introduced by 6.x-1.6 are still there. We may need some aditional clean up for that.

Just to check whether this is consistent with the multiple errors, this is what should be happening atm:

- People upgrading from 6.x-1.5 (or previous) to 6.x-1.7 should have no problems and see multilingual variables working as expected (more consistently than before).
- People that has upgraded first to 6.x-1.6, then to 6.x-1.7 may have wrong variables loaded, these were created by the 1.6 bug.

The manual fix is to delete such variables from 'i18n_variable' table, then refresh the cache. In the meanwhile, we'll be working on some UI option to clean up that variables table for next version.

Added this new setting page to help fixing all these issues with leftover variables. See the screenshot.

I confirm that the cron run issue in #904914: Latest 6.x-1.x-dev (2010-Sep-05) and stable release 6-1.6 breaking/disturbing cron got fixed with the latest 2010-Sep-11 dev. I am waiting for the next dev build to check the new feature that cleans variables up, but the issue was corrected without using it anyways! Thanx Jose ;)

...I rushed to speak. The issue seems to have been solved only in setups that were either straight 6.17 installations or 6.15 and prior that were upgraded to 6.17 skipping 6.16 as you explain in #11. Guess I'll have to wait for the variable cleanup feature and report back on remaining setups with the cron issue.

@Jose

This new feature seems to fix the cron problem. I cleaned all variables marked in red (quite a lot) and not only the cron variable. Were those all introduced by 6-1.6? Or am I cleaning up stuff that was ok?

Is the 'clean up variables' feature + the 'variables' tab supposed to be in the latest dev or did you people pull this from cvs?

It is in the latest dev. I didn`t find it in my first try but cache flush (or runnning update.php...don't remember what exactly I did) revealed it. It is located at /multilingual sytem.

Thought so. I've tried flashing the cashes (more than 3-4 times too), but it didn't do the trick.

Running the cron was not an option because of #904914: Latest 6.x-1.x-dev (2010-Sep-05) and stable release 6-1.6 breaking/disturbing cron, so I had to wait and try again after a day (24h) or so and then refresh the page a couple of times in random before I actually got to see the tab. Cleaning up the 'faulty' variables got me a 'Cron ran successfully.' again. FINALLY! Thanx everybody.

Here's the list of variables I had before the clean up in case it helps anyone:

   Variable name               Is multilingual   Has translations
=================================================================
v  site_name                          Yes               Yes
v  site_slogan                        Yes               Yes
v  site_mission                       Yes               Yes
v  site_footer                        Yes               Yes
v  anonymous                          Yes               Yes
   menu_primary_menu                  Yes               No
   menu_secondary_menu                Yes               No
   contact_form_information           Yes               No
v  site_frontpage                     Yes               Yes
x  cron_last                          No                Yes
x  css_js_query_string                No                Yes
x  drupal_http_request_fails          No                Yes
x  javascript_parsed                  No                Yes
x  language_default                   No                Yes
x  menu_masks                         No                Yes
x  node_cron_views_scale              No                Yes
x  pathauto_node_pattern              No                Yes
x  pathauto_taxonomy_pattern          No                Yes
x  statistics_day_timestamp           No                Yes
x  update_advanced_project_settings   No                Yes
x  update_last_check                  No                Yes
x  upgrade_status_last_check          No                Yes

Dont works. It clear page cache every time!
eZar

Give it some time (24hours at least). It didn't work for me either at start.

In my case upgrading 6.x-1.x-dev fixed the issue for everything but the variable 'logo_path'.
I have a bi-lingual site and it seems that the first language I set the logo for gets the correct path (and image), the other language doesn't get any logo at all and the field remains empty after saving.
This issue was briefly solved after upgrading to 6.x-1.x-dev...but now it's back. :(

I have no idea on how to debug this (not even sure it's the same issue!), so
any help is much appreciated.

TIA

@bohz: I had a quite similar problem of unsaveable settings (see #907422: Unable to change normal variables via admin interface - performance extremly slow). I solved the problem by manually checking the i18nvariables table and deleting the specific localized variable for the default language (in your case it should the settings variable of the current theme). You may also check the variables table first to see if there is also a version of that variable. Otherwise you may loose the theme settings.

Hope this helps

cheers

hctom

@hctom:
thanks a lot for your suggestions.
I will try your approach as soon as I can.
Do you mean that if I have a theme_MYTHEME_setting variable in the variable table, it is safe to delete the MYTHEME_settings variable(s) from i18nvariables table?.

For the time being I learned I can restore localized logos with a simple trick:

I started with only one language having the logo (it), the other language got blank setting (en).
- Disabled logo_path as a multilingual variable in settings.php - then chmod'ed 444
- Loaded the path for the proper image in the theme setting for the English language - saved
(this time the path was saved and image loaded)
- Immediately after, re-enabled logo_path as a multilingual variable in settings.php - chmod'ed 444 again.

Of course if I change one of the logos, the problem comes back, so a fix is needed anyway.
Luckily I don't have the same performance problem as you did!

Thanks again

Best

UPDATE: @hctom solution, deleting MYTHEME_settings variable from i18n_variable table seems to solve all problems. thanks!

subscribe

This caused a seemingly unrelated problem of update status module retrieving update information on every click on almost all admin pages, which resulted in very slow performance, 25+ sec delay on each request. After upgrading to 6.17 the update.module no longer could reset the update_last_check variable because it was marked multilingual.

There maybe people like me looking for this issue from other places thinking there must be something wrong with the core update status module, because disabling that will get rid of the delay. I hope they will find this page.

subscribe

I confirm what say kari.kaariainen, i am using 6.19 update.module.

I've had the same problem with update status fetching new releases continuously, due to the update_last_check variable being marked as multilingual.
The attached patch solves this, by having _i18n_variable_init() only insert into the global $conf array those variables that are actually multilingual, according to i18n_variable(), and not all spurious contents of the {i18n_variable} table.

re #28

So the dev did not fix your problem and you had to write a new patch? I am just asking because my problem was solved by the changes committed to dev.

Anyways I am correcting the status.

@dddave sorry I was using 1.7, I didn't try -dev. I'll try to test that later.

I try the dev version and it's not good for me, so i hope your patch will work wimh :)

Did you clean up the variables table using the new option provided in dev?

Hi dddave, could you please give me the path to access to this option because i didn't found it !

Thanks for your help.

@MasterChief: please read through posts #16 - #20. The option might not show up for you and in some cases even after flushing caches and running cron. Try going to ../admin/settings/language/i18n/variables

Hi klonos!

The link works well, so i deleted variables and now it seems to all is fine.

No problem mate ;) ...perhaps this information on the new feature + a link to the page needs to be posted in the module's front page.

Fixed in dev unless someone reports otherwise.

Great! Finally the solution for my problem after hours of searching!

First I only thought it was just a stucking cronjob and testet the fix on http://drupal.org/node/382682. Later I recognized, that only the german translation (default) the status report page showed me the nonsense.

For me it also fixed another problem concerning the very slow loading of administrator pages, which was described here:
http://drupal.org/node/369145

After installing the dev-Version of i18n and cleaned up my language variables, the admin pages loaded normally again and I could configure the cache settings.

Thanks a lot for the fix! ;-)

I've marked #908462: After upgrade to 1.7, admin functions slowed to a crawl as duplicate of this issue.

I think this patch may have broke saving new multilingual variables to the i18n_variables table: See discussion in #834290: Address fields are no longer multilingual variables and cannot be translated.

Edit: On IRC it was recommended that I create a new issue against 6.x-dev and leave this one be because it has been closed for a few months now. I have done so with issue #1205804: Variables set in the submit handler functions of forms are updated but never created in i18n_variables. Sorry for the noise!