Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Tried to use content_migrate and encountered repeated errors. (see next post)
Comment | File | Size | Author |
---|---|---|---|
#14 | 1157234-cm.patch | 7.94 KB | solotandem |
#4 | 1157234-cm.patch | 7.66 KB | solotandem |
#1 | 1157234-cm.patch | 5.54 KB | solotandem |
Comments
Comment #1
solotandem CreditAttribution: solotandem commentedSimple patch that cleans up the items referred to above.
Comment #2
JoshOrndorff CreditAttribution: JoshOrndorff commentedThis looks promising. At the very least it cleans up coding standards and fixes the fatal error referenced at http://drupal.org/node/1154508
Comment #3
jelenex CreditAttribution: jelenex commentedI have a suspicion that these errors show up only in PHP 5.3.x. Can somebody confirm this perhaps?
Anyway, this patch works for me, in a sense that the migration process doesn't crash in the beginning. Still, I'm getting empty DB columns (no data is migrated for any field) but that's probably for another issue..
Comment #4
solotandem CreditAttribution: solotandem commentedAn improved patch that also deals with not writing records because it mistakenly determined the record was empty (column names like 'field_name_value' need to have 'field_name' removed).
Comment #5
JoshOrndorff CreditAttribution: JoshOrndorff commentedAwesome. The patch in #4 did it for me. It fixes the fatal error I mentioned earlier, removes some extra white space, and fixes the data migration issue that jelenex mentioned in #3.
Without this patch I was getting the fatal error, but solved it by manually removing the break. After that I was also experiencing fields being migrated but no data (like #3) and this patch cures both.
I'd be happy to provide any more feedback that I can. I'm tempted to mark it RTBC, but maybe someone else could test it out too? jelenex, could you give the patch in #4 a test?
Thanks,
-Josh
Comment #6
JoshOrndorff CreditAttribution: JoshOrndorff commentedAlso, this should be elevated since it fixes at least two different problems that completely break the module. I've referenced this post and patch from the issue about the critical error.
-Josh
Comment #7
imclean CreditAttribution: imclean commentedThis appears to fix #1100906: AJAX HTTP Error on migrating fields. The field is created and the data migrated without error to the corresponding field_data_ table, however the populated fields aren't appearing on the relevant nodes. The correct nids are listed in the field_data_ table.
Comment #8
ju1i3 CreditAttribution: ju1i3 commentedI'm getting this problem with PHP 5.2.14 so it isn't just 5.3.x.
I will install and test patch 4 later today and report back.
Comment #9
jelenex CreditAttribution: jelenex commentedI've tested the patch #4 with various field types (text, number, file, email) and several thousands of records. So far everything worked well (as opposed to before), so I'm marking this RTBC.
@imclean I'd suggest opening another issue, because that sounds like a different kind of problem. This issue already solves two pretty much different things and would quickly become too bloated.
BTW, I've already posted a fix to the empty data problem in different thread (#1150790: Empty fields show up on migrated nodes) but my solution is less elegant, so I'm closing the other issue..
Comment #10
xevious CreditAttribution: xevious commentedI'm having a terrible time with this. I have a CCK image filed with thousands of images that I need to convert to D7. I'm thinking this page might be the fix but I have not been able to get the Patch to work.
Could someone give me idiot instructions for applying this patch?
$ patch < patch -p0 < 1157234-cm_0.patch
Comment #11
xmacinfo@xevious: Try -p1 instead.
Comment #12
xmacinfoI can confirm that the patch in #4 fixed the problem in #1100906: AJAX HTTP Error on migrating fields.
It's RTBC for me as well.
Comment #13
mstrelan CreditAttribution: mstrelan commentedI can confirm that the patch in #4 fixed the problem in #1100906: AJAX HTTP Error on migrating fields
It's RTBC for me as well.
Comment #14
solotandem CreditAttribution: solotandem commentedAn improved patch that uses the correct variable in message (otherwise identical to patch in #4).
Comment #15
marcoka CreditAttribution: marcoka commented#4 fixed the problem, migrate successfull
Comment #16
ju1i3 CreditAttribution: ju1i3 commentedI'm getting slightly further after installing the patch (#4). Now I get
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /batch?render=overlay&id=43&op=do StatusText: OK ResponseText:
some openlog and syslog error messages and then:
{"status":true,"percentage":"19","message":"Processed 3 out of 16.\u003cbr \/\u003e\"Creating field: \u003cem class=\"placeholder\"\u003efield_photo\u003c\/em\u003e"}
Comment #17
xmacinfo@ju1i3: Please post which modules or type of fields you tried to migrate. Looks like you were able to successfuly migrate 3 fields.
Comment #18
aspafford CreditAttribution: aspafford commented#14 is working for me. It fixed a php error I was getting ("Fatal error: Cannot use string offset as an array ... content_migrate.admin.inc on line 252"), and content is now being imported correctly.
Comment #19
JoshOrndorff CreditAttribution: JoshOrndorff commented+1 for committing #14. This patch already solves more than one problem, so lets try not to report additional issues on this page.
@juli3 try the patch in #14, and if it still doesn't fix your problem, maybe try opening another issue.
-Josh
Comment #20
ju1i3 CreditAttribution: ju1i3 commentedSorry, I can't say which field types, I'm embarrassed to say I didn't note them - it's a test system and I'm having so many problems with Drupal 7 I just reran the migrate fields until it finished them all - some worked, some didn't. If I have any further problems with this on any of my other systems I will update this or as you say open another issue, thanks for your help, Julie
Comment #21
KarenS CreditAttribution: KarenS commentedTaking this in bits. I fixed the missing filefield break in a different issue. There are a few typos in the drush file that have nothing to do with any fatal errors, so I fixed them.
This part does nothing but change the name of the variable, which was not necessary.
$context is what that value was called in the D6 data that we are reading from. The D7 field module uses $view_mode now, earlier versions still used $context. This patch for some reason changes it to $display_mode, which doesn't match either the way this was done in D6 or the way it is done in D7. It didn't hurt anything to leave that value alone and it makes the patch harder to evaluate. We should either use the D6 standard or the D7 standard, not make up a new variable. So I have to find all the places that variable was changed and see what else is actually different. And the answer to the question is that those are values that might exist as keys in the $settings array, but they won't always be there.
Now digging through the rest of the patch.
Comment #22
solotandem CreditAttribution: solotandem commentedKaren, the point of the rename is you are reusing the name of $context that is passed into the function as a parameter (by reference no less), and the potential for contamination of that variable exists and does occur, and causes other things to fail. So, yes the change is necessary. Further, the value of that key is the "build mode" -- hence the rename.
The point of the comment is that $context will never equal the things you are checking for -- rather the test should be against $settings[something] == $some_value. The "continue" is never reached as those conditions are never met, and the whole clause could be removed.
Comment #23
KarenS CreditAttribution: KarenS commentedI see that you found a couple things that were flat-out mistakes, so I'm adding those fixes.
I was puzzling over this next bit, but I think I see what is going on and why it might be broken. The 'is_empty' function wants the simple column name, not the actual db column name. There may be a cleaner way to fix it tho. We probably shouldn't be assuming the column name will always be correctly identified by doing a str_replace() of the field name, even though in most if not all cases that will actually work. We should have that info stored in our field array or one of the field info functions, I just have to figure out where it went in D7 and use it.
Comment #24
KarenS CreditAttribution: KarenS commentedI finally figured out what you were trying to say about $context, you are absolutely right about that. I think I have most of this sorted out now but want to test it a bit. I may not get this committed until tomorrow.
Comment #25
KarenS CreditAttribution: KarenS commentedI made some additional changes and committed this. Thanks so much for banging through this!
Comment #26
aaronpinero CreditAttribution: aaronpinero commentedSorry I have to mark this as unfixed. I applied the patch listed in #4 and it did remove the AJAX errors but didn't fix the underlying problem (which I first mentioned here http://drupal.org/node/1100906) that none of the content in any of the converted fields is preserved. Everything comes through totally empty. Conformed with a look through the DB (a whole bunch of tables with zero rows). So the patch appears to have been cosmetic only.
Comment #27
solotandem CreditAttribution: solotandem commentedBefore drawing a conclusion, what dev release did you apply the patch to? Karen just committed some changes that include most of the changes in #4. At this point, you should be testing her latest release.
Comment #28
aaronpinero CreditAttribution: aaronpinero commented@solotandem You're right. Thank you. I was using a (now slightly) outdated version of the module which I had patched, rather than the one committed recently. I installed the new version, refreshed everything from my DB backup and tried again. This time content is being preserved when fields are converted. The issue indeed seems to be fixed.
Thanks for drawing my attention to my oversight, and thank you @KarenS for the update. I was having a devil of a time trying to determine if there was really an issue or if I had done something wrong in my upgrade.
Cheers,
Aa.
Comment #29
bryancasler CreditAttribution: bryancasler commentedUsing the current dev, no patches, this error is still being thrown on two separate occasions. Should I wait for this to be resolved or can it be ignored?
Comment #30
solotandem CreditAttribution: solotandem commented@animelion That error results from a change in the file handling between D6 and D7. In D6, you could have the same file (the uri field) in multiple rows of the file table. In D7, the uri is a unique key -- so no duplicates allowed. I encountered this issue too.
I would suggest you:
-- search your database for duplicate uri's,
-- pick one row to keep,
-- change the references in other tables to the file table id you keep,
-- and delete the duplicate uri's from the file table,
-- rerun the content migration.
BTW, The file table issue is unrelated to this issue, and should be filed as a separate issue.
Comment #31
bryancasler CreditAttribution: bryancasler commentedThanks solotandem,
I wasn't exactly sure which thread my error was related to. I think this one over here makes more sense now.
#781088: Updating CCK Fields and Data from D6 to D7 #152
I'm going to try and figure this out today. Is there a sexy SQL command I might use to help in this hunt, or did you do it all by hand?
Comment #32
solotandem CreditAttribution: solotandem commentedIn the D6 database, try:
SELECT COUNT(*) AS Rows, filepath
FROM files
GROUP BY filepath
ORDER BY Rows DESC
Comment #33
bryancasler CreditAttribution: bryancasler commentedThanks solotandem,
I'm following up in the other thread as not to clutter this one. Long story short, I didn't find any duplicates.
http://drupal.org/node/781088#comment-4545832
UPDATE: This discussion is now being continued here #1176186: D6 -> D7 upgrade: Duplicate files cause Integrity constraint violation: 1062 Duplicate entry 'xx' for key 'PRIMARY'