Problem/Motivation
i18n site offline message is not migrated.
This is blocking
#2970849: i18n Variable to config: user settings and user.mail
#2970847: i18n Variable to config: system site settings [d7]
Proposed resolution
Migrate i18n variable, site offline message to config.
This is the first of the i18n variable migrations for Drupal 7 and includes a new source plugin because in D7 the variables are stored in the variable_store table, not variable, where the data may or may not be serialized. There is still much in common with the Drupal 6 VariableTranslation source plugin so a base class is added.
Remaining tasks
Write migration.
Write tests, includes updating the drupal7 test fixture.
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Comments
Comment #3
quietone commentedRight, let's make a start. This has a new source plugin to access the data in the d7 table, variable_store and of course changes to the fixture (yuck).
the source plugin shares code with the d6 version, so there is still work to do. Haven't run all the tests, so lets see what testbot finds.
Comment #5
quietone commentedThis add a base class for the VariableTranslation source plugin, changes the id of the d6 source plugin from variable_translation to d6_variable_translation, and attempts to get the various MigrateUpgrade tests working correctly.
No interdiff because there are
Comment #7
quietone commentedAdd a single quote to the test string for MigrateUPgrade7NoMultilingualTest and remove debug line of code (an exit() that stops a test early).
Comment #9
quietone commentedUpdate the tour entity count
Comment #11
quietone commentedNow, attempt to fix the coding standard errors. I've since found out the PhpStorm has magically decided to not run code inspections.
Comment #12
quietone commentedBecause this has a new source plugin for the D7 variable translations, it is a blocker for the other migrations.
Update IS.
Comment #13
maxocub commentedI did not do a full review yet, but don't think we can change this plugin ID without adding a BC layer.
Comment #14
quietone commentedYes, of course. This add the deprecation.
Comment #16
quietone commentedAdd @legacy to the two failing tests.
Comment #17
quietone commentedAdded the issues this is blocking to the IS
Comment #18
maxocub commentedI'm wondering if the renaming of the
variable_translationsource plugin tod6_variable_translationis really necessary? It's for consistency with the newd7_variable_translationplugin, but we end up with 3 classes:d6/VariableTranslation,d6/D6VariableTranslationandd7/VariableTranslation, which is also confusing. What do you think is better?Why is this new test in the @legacy group?
This class description should says something like "Tests the migration of...".
Why is this new test in the @legacy group?
s/Translation/translation
I'm not sure about this, but since this abstract base class use the values() method but does not provide it, should we not add an abstract values() method? So people extending this class will be warn that they need to implement this method?
Is it really enough to only use the language as ID? What happen if we are fetching more than one variable?
This should use the format from this page: https://www.drupal.org/core/deprecation#how-class. In particular, the 'see' link should point to a change record.
Also, the new class name is D6VariableTranslation.
Same here.
Why all those new missing paths?
Same here.
Why is there a new tour?
Comment #19
quietone commentedA small step, fixes for 18-1, 2, 3, and 4. Note that 1 and 3 are the same.
Comment #20
quietone commentedTest failure in #19 looks unrelated.
18.6. The variable source plugins are different than others. What happens in that each row has a property for the language and one each for every variable requested. An easy way to see this is in the source plugin test, this is from the d7 test.
18.7 and 8. Format of deprecation and trigger_error changed. However, still to do is the correct link to a change record.
18.9 Yes, that is wrong. fixed.
18.10 Because in this type of review page test all the modules in the source are enabled and i18n has quite a few modules.
TODO:
18.5 and 11
Comment #21
quietone commented18.11 When config_translation is enabled the tour tour.tour.locale entity is added.
18.5 I wasn't too sure about this base class myself. Maybe it would be better to not have it. There plugins are atypical anyway and it probably isn't a good idea to add to that.
TODO:
18.5
Add change record and update the link to change record in the deprecations.
Comment #22
quietone commentedNeeds a reroll.
Comment #23
quietone commentedRemove the new VariableBase class.
Comment #24
quietone commentedAdded change record.
Comment #25
quietone commentedThis is now ready for review.
Comment #26
maxocub commentedLet's get this issue moving since it's blocking other issues.
I think I would prefer if the BC layer class was the one called
D6VariableTranslationso that When Drupal 9 comes we will be able to remove it and end up with the better nameVariableTranslationfor the remaining class. It won't impact anyone who my have been extending the class (if any) because we make it extend the new class anyway.I don't understand how this i18n patch needs to add
entity_translation_*modules to the missing paths.Are those new blocks necessary for this patch?
Comment #27
quietone commented1. Fixed, I think I got it right.
2. They are needed because the that ReviewPageTest enables all the modules on the source site, except test and example modules. And since they are enabled they will appear in the UI lists.
3. I don't think they are so they are removed.
TODO: Update the CR.
Comment #28
maxocub commentedRe #27.2: Thanks for the explanation, now I get it.
Sorry I didn't find those nits in my previous review, but I think those are the last ones:
Should be
assertSame().As @masipila would say, class description should start with a 3rd person verb ;)
Comment #29
quietone commented1. Fixed
2. Fixed and did the same for the D7 source plugin.
3. Updated the CR
And that covers all the todos in this patch so far. :-)
Comment #30
maxocub commentedThis looks good to go, thanks @quietone!
Comment #32
maxocub commentedI'm starting to read in other issues that plugin deprecation should be done in a constructor, as well as in Drupal core deprecation policy. On the other hand, migrate if full of deprecation in the global namespace.
I guess we should start doing the deprecation in the constructor, what do you think?
Comment #33
quietone commentedYes, we should.
Comment #34
maxocub commentedPerfect, thanks! Back to RTBC.
Comment #35
gábor hojtsyWhy are we just adding a source just to immediately deprecate it?
How come all these i18n modules were missing in the D7 fixtures earlier?
Comment #36
quietone commented35.1 The existing variable translation source plugin in source/d6/VariableTranslation is named 'variable_translation' and not 'd6_variable_translation' as is typical and implies it will be used for both d6 and d7. Now that this patch introduces a new source plugin 'd7_variable_translation' which would leave us with 'variable_translation' and 'd7_variable_translation' which is confusing. It makes sense to change 'variable_translation' to 'd6_variable_translation' to avoid that. That can be done by introducing a new class with the new d6 source plugin annotation. But what do we call the new class since d6/VariableTranslation.php already exists and that is the class name we would prefer to keep. Originally I solved this by making a new class D6VariableTranslation #24 but maxocub suggested in #26 that it would be simpler to move the existing d6 annotation to a new immediately deprecated source plugin class and change the annotation in the existing d6/VariableTranslation.
35.2 This is the first patch that enables any of the i18n modules for D7 so it is the first time they are found. And they all need to be in the source db for the MigrateUpgradeD7ReviewPageTest which will enable all modules in the source.
Comment #37
gábor hojtsyThanks, makes sense.
Comment #40
gábor hojtsyThanks a lot!
Comment #41
heddnPublished CR.