Disable deprecated and remove modules during D7 upgrade

[herbdool]

Perhaps we can disable i18n_variable, i18n_user, i18n_block in an update hook in i18n.install. And perhaps remove it altogether. Not sure the code is necessary if we have an upgrade path for variables defined in variable_store.

[herbdool]

@indigoxela I think this is the best we can do. During the D7 upgrade we can disable the deprecated modules so it won't prevent subsequent upgrades. I haven't figured out yet how to start the upgrade (other than manually disabling in the system table or adding dummy modules).

[herbdool]

Just thinking about this now: maybe we should be putting all the update hooks (which I added to other issues) in i18n.install so that we can remove these submodules now or later.

[herbdool]

This PR #55 addresses this issue now (makes it easier to keep most update hooks in i18n.install in one PR).

[indigoxela]

Thinking this over...

We need the database tables and/or variables of the following modules:

• i18n_block (has no table)
• i18n_user (has no table)
• i18n_variable (stores data in the variable_store db table)

What we do not need is the code. Correct me, if I'm wrong. So the module code could get removed anyway, empty "dummy modules" should be sufficient.

I'd agree, we should put all update hooks regarding these deprecated modules in i18n.install.
Then we grab the data we need from database tables. And when we're done we drop the obsolete table and delete the variables. Is that correct so far?

[indigoxela]

A suspicion, why the i18n_variables module might be so tricky in the upgrade process: its value in the "bootstrap" system column is "1", which means:

Boolean indicating whether this module is loaded during Drupal’s early bootstrapping phase (e.g. even before the page cache is consulted).

But I'm only guessing.

[indigoxela]

Already done in this branch https://github.com/backdrop-contrib/i18n/tree/d7-upgrade-path

Testing is welcome.

Note: if you update the code locally, in case you're not using git, do not just unpack the file over the old code, but completely replace the whole i18n directory.

[herbdool]

It's not easy to review and test when I don't see a complete diff of what you've changed/added and how it compares to my PR. Can you provide a link for that?

[herbdool]

I checked each new commit on that new branch. I don't see any major issues but I haven't tested it. I might not be able to test it until the other PR I created is incorporated (where the variable_store and custom block translations are migrated). I have to keep an eye on the time I can spend - I've already spent a few hours on it.

[indigoxela]

I might not be able to test it until the other PR I created is incorporated (where the variable_store and custom block translations are migrated).

That's the next step on my todo list. Again, many thanks for your PRs, they give me helpful hints.

I have to keep an eye on the time I can spend - I've already spent a few hours on it.

I can understand that, fiddling with i18n is time consuming because of the module's complexity.

[herbdool]

I'm closing my issue since it's addressed.