Location Integration

What's needed, minimally, is a location.inc in the supported directory to support location fields. Yes, the node_import location.inc would be a good start - migrate's roots are in node_import, although the migrate API is different enough that you won't be able to simply plug it in. If someone implements location.inc, I'll be happy to roll it into the migrate module.

mike, I have a bunch of other integration modules done. User Relationships, Taxonomy, PrivateMsg, and Userpoints. I'm about to jump on to Location , unless someone is starting a Location integration module? So what should be do with all of these addon modules? See forthcoming issue

the way i envision is that you would have a database table of locations, and using table wizard, you'd map the old content id's to either new user ids, or new node ids. Then the migrate module would go through the list, adding locations to your existing content (or previously imported).

I'm not as familiar with Location CCK, is that part of the Location module or does it do it's own thing for storage?

If location cck is storing info as cck fields, it might make more sense to import that data when you are saving the node/user intially. You can bring in the additional info in the hook_mirgate_destination_prepare_TYPE() hook function that migrate provides. Then you just add that info to the node or user object and it gets saved along with the node. You don't get automatic mapping of lid, etc this way, but you can just create your own mapping table. This is how i did files, and it worked reasonably well.

Yes, I've got it written (last week). It imports User Locations (if enabled), or Node Locations. However, it doesn't use CCK Locations. It also the clean/delete functionality isn't quite working yet (i've just been truncating tables). The module assumes you have existing nodes, or nodes you have imported that you want to create locations for, so it takes nid of the existing node (uid for users), lat, long, and all the other fields available in the API.

I would think that if you wanted CCK locations, Imported AS you import your nodes, that a wholly different method would be required, similar to the current cck integrations such as date, etc.

Mike, do you know if the CCK integration stuff can be added to from another module?

If the module works for you as is, I'll post a zip file of the module as I have it now.

Is the location compatibility implemented in the newest release?
Or is the code you "got written" a patch, published where?

Hi there,

any changes on that?

Thx,
Pedro Markun

No one has contributed location module support to the migrate module (or, as far as I can see, migrate module support to the location module...).

i had a working version, but it needs to be upgraded and refined. Work is starting on this again this week, so keep an eye out for it. (bug me)

Any updates on your contributions to add location support?

Thanks,
Jerod

Is this available yet?

Any chance this will be available soon? I don't even care if it is not tested, I would like to be able import my database into drupal soon.

The best place for migration support for contrib modules is in the contrib module itself. The second-best place is the Migrate Extras module, and Frank does have an implementation there (I haven't tested it though, I haven't used the Location module myself).

The Migrate Extras module still shows integration with the Location module as being tested. Does anyone know when this will be available? I'd be willing to offer a small bounty to help this move along faster.

Subscribing....

OK, worked on this last couple days. Should be ready to go. Note, this is just the location module integration. Location user is almost identical, but would still need to be done. CCK is a little more complex, but still creates creates a location with an lid, and then maps the CCK field entry to it.

The module needs to be enabled in the migrate settings. Make sure you have the latest dev version of migrate, since it has the hook_migrate_api() code in it. Please test and if there are bugs, please make a new issues.

Note: if you get EMPTY LOCATION errors trying to import US, country-only locations... see this post and patch for location module #730730: Default country location should not be 'us' but blank

Because locations aren't a CCK field, and you may want to import more than one location per node. "Location" is the content type that you want to use, not "Node: FooBar". It should be listed when you make a new content type. What you'll need is a view that has the NEW node id of the node you want to add a location to and then all of the location fields you want to import across the row. To get the NEW nid, I add a relationship in tw to add the master node map table (an option in migrate extras settings). I do the same things for importing comments, etc. Let me know if it works for you. I also just implemented user_location as well, and that will get out to the module when I can find some time. (bug me if more than 2 weeks)

the first part you have right but let me clarify the "how to hook those locations together with the nodes eventually" Let's say you have some locations a simple example would be

sourceid | country
123      | us  

So you've already imported sourceid 123, which is now node (nid) 567. When you import, you need to use nid of 567 (not 123). You can do this by using a relationship in views to a map table. So you are able to create a view that looks like

sourceid | country | destid (nid)
123      | us      | 567

and then you set the nid field to the destid and it will import the location into the right node.

Attached patch adds location_node support. I also made some code style fixes while trying to get my head around the existing code.

Hmmm not in the version I'm using which is the alpha2 one. It has the ability to migrate locations as an entity by themselves, and not as part of a node migration.

I've updated the patch to handle both location_node and location_cck. Could probably be improved upon / tidied up, but seems to work. We should probably also add support for location_phone and other add-on modules, maybe by calling location_field_names() to populate the list of fields instead, but that's for another day/issue.

oops, wrong patch. Here's the updated one - both with and without the style fixes. Take your pick.

--subscribing

I'll take a closer look shortly. I also added user_location integration as well on my local version.

great! I'll push the current dev into a new release and then start adding these features to the dev version. Tour issue with location country being US, is probably related to this problem: #730730: Default country location should not be 'us' but blank and #349877: Can't save a location which is just the default country

I'd like to see location_cck stuff pushed out to it's own include (see #753048: location_user integration )

Comment #40 - importing multiple line addresses into a Node: Location CCK field, how is this done exactly?

We're finding the content set only has a single 'CCK: Location lid' option in the destination field column, with AddressLine1,AddressLine2,City,State,ZIP to select from in the source field column.

How do you get the different lines of addresses from the source mapped to the fields in Location CCK?

Using migrate_extras 6.x-1.0-beta1, and Location 6.x-3.x-dev (2010-May-20)

Thanks

subscribing (hi alan :)

Hi All,

Sorry, I'm a newbie. But... will this allows me to map my location to the gmap? Hmm... so I have a csv with address, city and zip, and I'm trying to import with table wizard and migrate to plot my location on the map. So far, I have everything imported, but I'm banging and scratching my head at the moment :)

thanks,

Migrate and Migrate Extras V1 are no longer supported. Location support for V2 is now consolidated to the following issue:

#943178: Implementation of Location support for Migrate Extras V2