I've been trying out the alpha and so far so good, but I have several million rows of "bookmarks" from a non-drupal site that I need to migrate into my D7 rebuild.
I've tried using the migrate_extras MigrateDestinationFlagSimple class with version 2 of Flag and it works fine (with a few teething problems), but obviously it doesn't work at all with 3.x given the changes to the database. I've tried editing MigrateDestinationFlagSimple myself to reflect the 3.x changes, but somehow I'm missing something and it doesn't work.
Are there any plans to provide an updated MigrateDestinationFlagSimple class? migrate_extras is officially unmaintained, but submitting a patch on the issue queue is all I need.
Failing that, has anyone else got a working 3.x-supportive version of the migrate_extra plugin?
Comment | File | Size | Author |
---|---|---|---|
#9 | flag-migrate-1988976-9.patch | 6.05 KB | hussainweb |
Comments
Comment #1
joachim CreditAttribution: joachim commentedWe should move Migrate support into the Flag project, where it can be better maintained and kept in tandem with branches.
Comment #2
xcession CreditAttribution: xcession commentedAgreed, that would be more convenient.
The migrate_extras issue queue already has a couple of useful patches for the 2.x version of MigrateDestinationFlagSimple - such as adding support for detecting already-imported rows - but it's a bit moot given the overhaul Flag 3.x is getting.
Comment #3
joachim CreditAttribution: joachim commentedWell we could bring those into the Flag 2.x branch, if they're not getting attention over at migrate_extras.
Patches very gratefully received! :)
Comment #4
chr.fritschHere is a patch for migrate_extras to support flag 3
https://drupal.org/node/2029613
Comment #5
chr.fritschAnd now, here is the patch
Comment #6
joachim CreditAttribution: joachim commentedIf this is for importing flaggings, it should be called flagging, not flag.
Also, we should inherit from MigrateDestinationEntityAPI maybe, or MigrateDestinationEntity at least.
I for one would be fine for Flag migrations to depend on Entity API even if Flag module itself does not.
Doesn't match function name.
There is no longer a flag_content.
Surplus blank lines.
Surplus indentation.
Comment and code don't match.
The Flag API should be used here. Migrate uses node_save(), for example.
Urgh. Please write this out as a proper if-then-else, as this is hard to read.
This should not be necessary if going through the API, surely.
Needs docblock.
This doesn't look sustainable now that flags can be on any entity!
Comment #7
hussainwebI have improved the patch based on the feedback in #6. I tested a migration with this and it works fine.
Comment #8
hussainwebI have been thinking further and wondering if it will be a good idea to add a new module within flag to provide migration support. Apart from the destination handler, it can also provide a dynamic migration class similar to migrate_d2d.
Does it make sense to have such a module within flag? Or is it a better idea to have it as a separate project? I think it might make sense within flag module as the migration support will always match the flag version used.
Comment #9
hussainwebI am attaching another patch with two tiny modifications to skip permissions check when flagging content in destination handler. It adds a parameter to skip permission check in
complete
method inMigrateNodeFlaggingHandler
andMigrateUserFlaggingHandler
.Comment #10
joachim CreditAttribution: joachim commentedLooks like this is coming along nicely. I'm a bit confused over the different kinds of classes in this, but I probably need to go read up on destination handlers in Migrate.
This needs trimming to 80 chars.
The parameters here need documenting: Migrate destinations have different parameters.
I don't get what this bit is for. Is this because the Flag API always forces the timestamp? We could perhaps consider changing that.
This should perhaps call its parent to get Field API fields too?
This needs to be split into a 1-line summary, and then more detail.
Presumably this class is only found if flag module is present!
Wow! That's a PITA :(
Comment #12
joachim CreditAttribution: joachim commentedThere's no test coverage at all for Migrate integration, so any patch for this is going to pass tests trivially!
This patch needs work based on my previous comment.
Comment #13
hussainwebI think the work done in #2503815: Flag destination class for migrate module is much more recent and complete. That issue just deals with a destination class. Here, we also have destination handlers which are worth talking about separately.
Let's deal with the destination class in the other issue and talk about introducing handlers here. I already combined the good parts from the patch here to the patch in the other issue.
I am renaming the title to that effect. This does not have anything to do with migrate_extras at all. I am also marking this postponed on #2503815: Flag destination class for migrate module.