Closed (fixed)
Project:
Drupal core
Version:
8.6.x-dev
Component:
migration system
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
3 Jan 2018 at 16:00 UTC
Updated:
15 Mar 2018 at 12:04 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
David Hernández commentedI think this should deal with the requested changes in the issue. I have not been able to find anywhere in the code base where this file is used.
Comment #3
joelpittetThere would be a slight BC break if anybody extends that class, but not sure if our policy covers that.
Comment #5
heddnThis gets a little tricky here. Because we are also dealing with d6 file fields. I tried changing the destination module and some other things, but it still doesn't show image up on the list as a non available module.
re: BC
No, we'd still want to leave the class in the old location and have it extend from the new location. And we need to do that for d6 and d7.
Comment #6
joelpittetAh, that's a good BC approach @heddn, good call.
Comment #7
heddnI think I'm making this more complicated (in my mind) than it needs to be. In addition to the d6 change I mentioned, we also need:
Tests are because we didn't catch it with our current test coverage. We need to add module dependency, because otherwise we don't require the image module to be enabled.
Hmm... I wonder if we want to just add the image dependency onto the d6_user/d7_user migration too? That way we can be sure that the image module is enabled.
Comment #8
gábor hojtsyDrupal 6 user pictures are disabled by default and sites actively need to enable it, so should not be a fixed requirement for user migrations.
Comment #9
heddnBumping priority. Current state provides misleading data on a pretty important module.
Comment #10
quietone commentedUpdated the tests.
Comment #11
quietone commentedWith this imagefield will display as missing.
Comment #13
quietone commentedI was working on 8.5.x, let's try that again.
Comment #14
jofitzI'm unable to replicate the test failures locally, but I have identified a minor change that is required.
I am also running the patch in #10 against 8.5.x on the assumption it will suffer very similar failures.
Comment #15
heddnI wonder if any of that is related to https://symfony.com/doc/current/components/phpunit_bridge.html#mark-test....
Comment #17
jofitzComment #18
heddnComment #19
heddnComment #20
jofitzComment #21
heddnfield module is a module dependency of MigrateDrupalTestBase, that's why ImageField is even showing up on random things like Action. Now to figure out why it is erroring...
Comment #22
heddnI'm not sure how much the interdiff is going to help. But I've added one. The reason for the test failures is because when we moved the field plugin to image module, we left the cck plugin. This plugin is no longer masked and gets discovered because file module is enabled in the base migrate test class. Oops.
To solve this, I've moved the cck class from field into image as well. Simple enough. We'll see after tests if it is really that simple.
Also you'll see in the patch links to a CR and deprecation notices added to the file classes that got copied (not moved to retain BC) into image module.
Still need some tests to address the concerns in #7. But let's see how the BC layer is holding up.
Comment #23
marcvangendIn other places, "8.3.x" was changed to "8.5.x". Shouldn't these be changed too?
Comment #24
heddnThat's because
core/modules/file/src/Plugin/migrate/cckfield/d7/ImageField.phpwas deprecated in 8.3. We're just updating the reference to point to the new location. The other places are actually deprecated for the first time in 8.5.Comment #25
quietone commentedCorrect the destination modules in MigrationProvidersExistTest and renamed a directory from cck to cckfield.
Comment #27
jofitzStill need some tests to address the concerns in #7.
Comment #28
quietone commentedThere are two items in #7
The second was answered in #8, a module dependency can't be added. That leaves the tests.
I'm a bit unclear on the test, it seems to be a test to ensure that this field plugin, image, is in the correct module, that is the module where the image field type is defined. Is that correct? If that is correct, than the test should cover all field plugins and not be limited to any particular one. And then should that be done here or in a followup? Or, do I have it all wrong?
Comment #29
quietone commentedAsked on IRC and learned I got that all wrong
I take this to mean a test of review page when running from the UI, /upgrade. If so, we could use the new test base class, MigrateUpgradeReviewPageTestBase, from #2914974: Migrate UI - handle sources that do not need an upgrade.
Comment #31
heddnSo, writing a failing test here is going to be hard. Since the problem is that we need to enable the image module for things to pass successfully. I guess to show the problem, we add a test of the successful import of images. Right now it looks like we don't have that. Or at least one that doesn't also enable the image module. To show the failing situation, we can upload an almost duplicate patch that doesn't enable the image module.
Comment #32
quietone commentedThis adds a test of image field migration for d6 and a fail test.
Comment #34
heddnHere's an interdiff on the failure and success patch in #32.
Comment #35
heddnAnd here's an interdiff against #25 for the success patch in #32
Comment #36
heddnYeah, we've got us valid test coverage now, as seen in the failure test in #32.
Unable to determine class for field type 'image' found in the 'field.storage.node.field_test_imagefield' configurationThe last actionable thing I think we need to do is figure out what to do for d6 user profile photos. See comment in #29. The option to include user profile photos is a config option in D6. And by default it is turned off. If it is turned on, then we want to somehow notify the user upgrading their site that they will loose user profile photos. User profile photos in d6 are unique, because are not managed files. They are just a string location of where the file is located on the disk. However, when that gets sucked into D8, that becomes a managed file. So, the "source" of the data is the user module in D6. The destination is image module in D8. And we want to warn users.
To solve this, we could do a couple things. 1) open a follow-up to address this and get what we have committed. I like that option :)
Or we can press on here and 2) add a kernel test that tests this whole scenario and see what are our options.
Putting to NW for the nits below. If there is consensus on breaking out the user profile stuff into a follow-up, let's also get that opened. Then this is pretty nearly ready to go.
This should be updated.
I'm not sure this is necessary.
Comment #37
quietone commented36.1 Fixed
36.2 Without menu_ui there are schema errors.
I think it is worth noting that a MigrateImageTest for d7 is not added because the d7 MIgrateNodeTest already includes assertions on a image field.
Yes, lets solve the user profile problem in another issue and keep this about moving the image field plugins.
Comment #38
quietone commentedThe followup has been created, #2944966: User profile migration should send a warning if image module is disabled
Comment #39
heddnThis is big enough and complex enough that splitting things off to a follow-up make sense. Let's get this merged, then on to follow-ups. I think the last thing is a CR? The code here looks solid. Plus, I cannot RTBC this thing since I worked on it too much.
Comment #40
quietone commentedThere is an existing change record, Migrate Image CCK and Field plugins moved to image module, which looks good to me, so we are all done here.
Comment #41
phenaproximaLooks good -- I mean, it's incredibly confusing, as these "move X to another module" issues always are -- but it seems legit to me. The only strange element is MigrateImageTest.
Can this doc comment be expanded? It doesn't explain what the purpose of the test is, or why it's extending MigrateNodeTestBase, or...you get the picture. I think we need to explain the context a bit more.
I find this comment a bit odd.
Comment #42
heddnComment #43
quietone commented@heddn, thanks for making the patch. It looks good, but I don't think I can RTBC since I added the test.
+1 RTBC
Comment #44
phenaproximaMy comments are addressed. Looks legit.
Comment #45
alexpottLet's add a link to the CR here too... i know this is an existing issue.
This should also link to the CR as per policy.
There should be a corresponding
* @expectedDeprecation ImageField is deprecated in Drupal 8.5.x and will be removed before Drupal 9.0.x. Use \Drupal\image\Plugin\migrate\field\d7\ImageField instead.on the test - this message will need the CR added too.Also I think we should have a corresponding test for Legacy test for D6 just to show it works
Comment #46
jofitzComment #47
heddnFeedback addressed. Back to RTBC.
Comment #49
heddnRandom test failure
Comment #50
alexpottComment #51
alexpottWe can't do this. We should leave the legacy code in place and not extend from the non-legacy. This is because image module might not be installed so we can't extend from its classes.
Comment #52
heddnIt's a bit of a catch 22. The field migration is going to fail if image is disabled. Even if we don't extend. Because the field schema didn't exist. That's why there is no annotation on the legacy field any more. Because the annotation gets moved to a place where it can function. The only reason we have a bc layer is for the case where someone directly extended the class.
Yes, this is confusing. Not sure if that explanation is enough to return to rtbc or not. Let's try it.
Comment #53
alexpottAdding credit. I confirmed with @heddn in slack that existing migrate plus migrations will pick up the new plugins.
Comment #54
alexpottCommitted and pushed 544740df31 to 8.6.x and 50f4ceae89 to 8.5.x. Thanks!
Discussed with @catch and we agreed as a migrate_drupal patch which is beta this should be backported to 8.5.x so it's in 8.5.0.
Fixed coding standards on commit.