I'm working on putting together some handlers for pulling in lists of static files (such as static HTML) for migration. In the interest of making this as reusable as possible, it'd be great to know a few things.
1) Has anyone already begun work on this? How are you structuring it and what are you naming the files?
2) Would this be useful as an addition directly to the Migrate module, or should it be handled elsewhere? (migrate extras, elsewhere in contrib, etc.)
3) What would be the set of naming standards you'd suggest for classes?
Thus far I've put together a simple implementation that builds off of the MigrateList and MigrateItem classes to facilitate passing in a path and other options which will invoke file_scan_directory() to provide an index for migration and files to iterate through, keying off the relative path to the files as a unique identifier. I'll likely add a couple of other methods including some different ways of keying the index and using a http source.
Jeremiah
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | migrate_files_sources-1231492-10.patch | 5.64 KB | Mark Theunissen |
Comments
Comment #1
jerdavisHere's what I've got thus far.
And an example implementation..
Comment #2
moshe weitzman commentedI think that we have come across situations like this where we monitor a directory for files to process. Maybe Mike can recall. Kayak?
Anyway, this sounds like a worthy enhancement.
Comment #3
mikeryanYes, the idea of a file-based source plugin has been around for a while, just never quite got around to it... But, let's please use File rather than "Static", which may make sense for your particular application of "static" HTML files but doesn't reflect the generality of the concept. For example, MigrateListFile would be useful for reading a directory full of XML files.
Thanks!
Comment #4
Mark Theunissen commentedjerdavis: That's a coincidence, we're evaluating migration modules for importing a very large static HTML site, and obviously would love to use Migrate V2.
Let's see what we decide on and possibly work together with you on creating this functionality.
Comment #5
jerdavisSounds good!
Comment #6
Mark Theunissen commentedjerdavis: We needed to implement a proof of concept so I've taken your code above and done Mike's suggested changes, committing it to a sandbox fork of Migrate, branch html-files-source:
http://drupal.org/sandbox/marktheunissen/1242682
Not sure where to go from here, should we stabilise it in the fork before supplying patches to Migrate?
Comment #7
jerdavisMark,
What a coincidence, I'd done the same thing ;). http://drupal.org/sandbox/jerdavis/1232588
Yeah, we should stabilize in one of these and then provide patches back to Mike.
Jer
Comment #8
Mark Theunissen commentedJer,
I've created a patch to the current files.inc implementation, and posted it here in an issue on your sandbox:
http://drupal.org/node/1279024
It allows the implementer to specify multiple directories to be scanned (in the case where you don't want an entire folder and all it's subfolders, but only a selection).
Should we continue there or here?
Comment #9
jerdavisThanks for the follow up. I'll review there and we can continue work in that issue queue if that works for you.
Comment #10
Mark Theunissen commentedOn second thought, I'd like to see if Mike or Moshe will accept this patch in it's current form, as it's come a little way and we're using it quite successfully so perhaps it's time to move it into the mainstream.
Patch attached! This provides the original functionality plus it allows multiple directories to be specified, in the case where you want a single Migration class to pull files from separate directories.
Thanks.
Comment #11
jerdavisUpdating to needs review, I'll try to get this in my personal list to check too.
Comment #12
sylus commentedHello,
I have used this patch successfully to scan a directory and create a bunch of multilingual nodes (french and english language).
However I was wondering however if it is possible to extend this patch to include the ability to link the "tnid" between two different nodes for node translation. Conceptually I am at a bit of a loss for how to do this as when using the DestinationHandler I only have access to the current node being processed so can't link with a previous"tnid" value from the previous node.
I was curious if anyone thought about this problem and would have a potential solution?
Comment #13
Mark Theunissen commentedWe do exactly that, in a two-pass system. While the migration runs, it build up information about the translation sets, and saves them to a custom table.
Then, we implement postImport() which does a pass over the migrate map table and uses the translation set data to manually update the tnid value for each node.
I don't think it's possible to do this in 1 pass.
Comment #14
mikeryanI don't have a good use case to test with at the moment, but based on a review of the code and faith;) I've committed this to D6 and D7. We can always refine it later...
Thanks!
Comment #16
Mark Theunissen commentedI've written a blog post on this, with tips on handling legacy content:
http://fourkitchens.com/blog/2012/05/04/migrating-old-html-files-drupal
There's a working gist, too, with the basics of parsing HTML using QueryPath : https://gist.github.com/2596787