Upgrade problem from 5.x-2.5 to 6.x-1.2

Update:

I did some digging in the database and I can now confirm that I have not enabled the experimental i18n modules so they are not causing these problems.

i18n strings: I don't have {i18n_locale_strings} that would have been created during install
i18n sync: the weight of this module is 0 (would be 100 if the module had been installed)
i18n content: this module does not make structural changes to db, only select queries

Based on this I can't see any "stupid user errors" that I would have made to cause these update errors - all other i18n modules (except the experimental ones) should upgrade without errors, right?

-Markus

Upgrading experimental modules is not yet supported. This seems to be a duplicate of #395598: D52 -> D6 upgrade: missing columns in i18n_strings table.

hass, thanks for your reply!

If I'm not mistaken only the first part of problem #2 is duplicate to issue #395598.

i18n strings
I'm a little confused about this issue (i18n strings) because I haven't enabled the experimental 5.x strings module as I explained in comment #1.

i18n blocks
i18n blocks is also causing troubles and I think that module is not marked as experimental. Any ideas to this?

How to proceed
I would really like to help troubleshoot these issues and contribute my findings but I need a little guidance on how to proceed. I'm familiar with PHP, MySQL (and Drupal module development to some extent) but I haven't been working with module update scripts before.

What I'm asking is that somebody would check my first post in this issue and give me an educated guess of whether this problems are related to each other or do they look like separate problems. Meanwhile I'll google how the update scripts work.

#1. This is a core bug, see #223077: update 5.7 to 6.0 failed "ALTER TABLE {locales_target} ADD PRIMARY KEY (language, lid, plural)"

#2. How have you upgraded? I haven't tested the upgrade path with i18n, but I believe it's possible that this haven't been tested with all i18n modules disabled, but in such a case the upgrade hooks are still executed. I'm only guessing... you need to post the upgrade errors (marked red).

How have you upgraded? I haven't tested the upgrade path with i18n, but I believe it's possible that this haven't been tested with all i18n modules disabled, but in such a case the upgrade hooks are still executed. I'm only guessing... you need to post the upgrade errors (marked red).

The update process is described in detail in the first post of this issue as well as the DB error messages I got. The i18n modules were all disabled at first as instructed in the updgare handbook page of the i18n module, see http://drupal.org/node/313315.

- Disable all i18n modules (Disabling all contributed modules is always recommended) before upgrading to Drupal 6.
- Upgrade your codebase and run the Drupal 6 standard upgrade
- First, enable Drupal 6 core Translation module. Internationalization now relies on it.
- Go through the Inernationalization package module list and enable the ones you need.
- Run the update script again (update.php) so i18n modules can update their data properly

If I understood your last comment correctly I should try to upgrade my installation with i18n modules enabled, right? Just to make sure:
- leave i18n modules enabled in D5 installation
- copy D6 core files to the right place
- copy D6 i18n files the right place
- try to run update.php

I'll try this and report how it went.

If I understood your last comment correctly I should try to upgrade my installation with i18n modules enabled, right?

Yes, many developers missed this D6 feature :-(((. It's best to upgrade core first via update.php and copy the modules afterwards inside and run update.php again. This way you really see if this is a core or module bug and it may prevent failures you may have seen if you keep the module enabled in D5, but make sure not to copy the modules into the install until core has been upgraded. Try it...

I got rid of the first problem (locales_target) which was a Drupal core bug, http://drupal.org/node/223077#comment-2195328

I then made two different upgrade tests.

Test 1 - i18n modules were disabled in 5.20 before upgrading

This is like the upgrade test in my first post except that I'm using the patched core system.install to avoid the locales_target -error.

• All contrib modules, including i18n, were disabled in 5.20
• Ran update.php of D6. No errors - core is succesfully updated to 6.14
• Ran the update.php again as suggested - No errors - Now the database log module (dblog.module) is updated as well
• Enabled the core "Content translation" module as suggested in the i18n upgrade handbook page
• Copied the i18n module files to sites/all/modules/contrib_modules
• Enabled the following Internationalization modules: Internationalization, String translation, Block translation (these all are required by Menu translation which is the module I actually need). When I enable these modules I get these two error messages:
  • user warning: Table 'dev.drupal_i18n_blocks' doesn't exist query: SELECT * FROM drupal_i18n_blocks WHERE language = '' in /path/to/drupal/sites/all/modules/contrib_modules/i18n/i18nblocks/i18nblocks.module on line 367.
  • user warning: Table 'dev.drupal_i18n_blocks' doesn't exist query: SELECT DISTINCT b.* FROM drupal_blocks b LEFT JOIN drupal_blocks_roles r ON b.module = r.module AND b.delta = r.delta LEFT JOIN drupal_i18n_blocks i18n ON (b.module = i18n.module AND b.delta = i18n.delta) WHERE (i18n.language ='fi' OR i18n.language ='' OR i18n.language IS NULL) AND ( b.theme = 'garland' AND b.status = 1 AND (r.rid IN (2,3,4,5,7) OR r.rid IS NULL) )ORDER BY b.region, b.weight, b.module in /path/to/drupal/modules/block/block.module on line 407.
• Summa summarum: I can't even get to the point where I should run update.php for i18n modules

Test 2 - i18n module enabled in D5.20 before upgrading

In this test I left the i18n module and i18n block module enabled before I started the upgrade process.

• All contrib modules, except i18n and i18n - blocks, were disabled in 5.20
• Copied the D6 i18n module files to sites/all/modules/contrib_modules
• Ran update.php of D6. Selected the following update script versions for i18n modules as suggested:
  • i18n module: 9
  • i18n blocks module: 1
  • i18n taxonomy module: 1
• This update fails to fatal error:
  • An unrecoverable error has occurred. You can find the error message below. It is advised to copy it to the clipboard for reference.
  • An error occurred. http://www.example.com/update.php?id=1&op=do <br /> <b>Fatal error</b>: Call to undefined function tt() in <b>/path/to/drupal/sites/all/modules/contrib_modules/i18n/i18nblocks/i18nblocks.module</b> on line <b>234</b><br />

Conclusion

• The second upgrad method is clearly wrong - one is supposed to upgrade the core first as I did in test #1
• Core was succesfully upgraded to 6.14 in test #1
• There is something wrong with the D6 version of the i18n blocks module. When I enable the module, I get the two error messages that tell me that table drupal_i18n_blocks does not exist. These errors occur before update.php, when enabling the i18n blocks module

I managed to debug this a little bit further. As the conclusion in my previous comment suggests, the problem is indeed in the i18nblocks module. I can upgrade the Internationalization module and install the String translation module without errors as follows:

• All contrib modules, including i18n, were disabled in 5.20
• Ran update.php of D6. No errors - core is succesfully updated to 6.14
• Ran the update.php again as suggested - No errors - Now the database log module (dblog.module) is updated as well
• Enabled the core "Content translation" module as suggested in the i18n upgrade handbook page
• Copied the i18n module files to sites/all/modules/contrib_modules
• Enabled the following Internationalization modules: Internationalization, String translation, (Block translation was not enabled) - No errors!
• Ran update.php and selected the following versions to module updates:
  • i18n: version 9 (suggested value)
  • i18nblocks: changed to value "No updates available, suggested value was 1"
  • i18nstrings: No updates available (suggested value)
  • i18ntaxonomy: version 1 (suggested value)
• These updates ran without errors

Debugging the i18nblocks module

After succesfully upgrading the i18n module and installing the String translation module I dug a little bit deeper with the i18nblocks module.

• I enabled the the module, which resulted in the two user warnings mentioned in my comment #7 (table drupal_i18n_blocks doesn't exist)
• I think that enabling this module doesn't trigger the i18nblocks_install() function for some reason. The most obvious reason that comes to my mind is that I probably have had i18nblocks module enabled in my D5 site at some stage and the i18nblock_install() is only ran when we are doing a new install. However, for some reason my old site doesn't have the i18n_blocks table in the DB so that causes the errors after enabling the module.
• After enabling this module I have three i18n related tables in the DB: i18n_node, i18n_strings, i18n_variables. No i18n_blocks
• Because I do not have any translated blocks in my D5 site I guess that the only thing I need to do is to manually run i18nblocks_install() which is quite simple function, it only creates the i18n_blocks table

Because I do not have any translated blocks in my D5 site I guess that the only thing I need to do is to manually run i18nblocks_install() which is quite simple function, it only creates the i18n_blocks table

I ran drupal_install_schema('i18nblocks') manually. I did this by creating a new node, setting the input format to php and running the function from there by previewing the new node. The i18n_blocks table was created successfully without errors and now everything seems to work normally.

Conclusion

For some reason my D5 DB did not contain the i18n_blocks table and this caused the problem. This might be due to disabling (maybe even uninstalling?) the module at some point in my D5 based site development. As I mentioned earlier the only i18n module I needed in my D5 production site was the i18n module itself. However, everything in this case suggests that I had had the i18n blocks module installed at some point in the development of my D5 site.

Edit: fixed a typo, the right argument to drupal_install_schema is 'i18nblocks' (not 'i18n_blocks')