Add a migration functionality to migrate locations from node/user locations to cck locations

Location node is the old Drupal/Location way of doing things before CCK. It is old, has a large user base, and lots of modules that know how to integrate with it.

Location CCK can(will) offer several advantages mostly around tighter integration with other modules like CCK, Views, and others. However, location_cck is newer and still a bit wet around the ears. It is the future of Location but not fully developed yet.

If you need a more stable solution right now use location node. But if you are a developer and have some time location cck is the way to go.

Hopefully that answers your question. If not feel free to re-open this.

What is the current status of Location CCK, as of the latest dev release? I tried reading the other issues but it was unclear whether it was ready for live use yet or not. We would be using it with Views and GMap to provide mapping and a proximity exposed filter.

Also, is there an upgrade path to migrate your data from the old Location format to CCK Location?

Tagging

We are upgrading our system and lots of our nodes have location node but our new content types will have cck location.

Will there be an upgrade option?

Anietie

I also encountered some difficulty just recently using the cck location field and Gmap. I came across this other thread in which I placed a comment http://drupal.org/node/386848#comment-1705876

There are answers there with suggestions on how to do this with views. But, when cck location field is working it will make it simpler, I think.

Izzy

Take a look at this video

http://drupal.org/node/347030#comment-1626842

you can use cck but need to setup a relationship in the view with the content cck field

Who knew???

I have spent weeks coming back to this issue and going back and forth between cck and the node implementation.

Thanks very much.

Izzy

I'm also very interested in the possibities of a upgrade path from node location module to CCK location field.

Looking at threads like http://drupal.org/node/373465 , for me CCK location fields doesn't look stable enough for a production site. (I hope i'm wrong) I'm talking about a stable combination of Gmap, location data and views.

However considering the integration of CCK in views, i guess CCK fields will be much stronger then the node location module as soon as it is stable enough.

So choosing for some stability with the location field module, is there or will there be a nice way to jump over to CCK location fields once it is ready for a production site?

I've been configuring cck location fields and gmap with the help of suggestions from others (http://drupal.org/node/386848).

It seems pretty stable from what I've seen. cck location fields, views with a relationship, and gmap. I haven't been faced with needing to transition existing nodes to the cck fields so can't comment on that journey.

Izzy

Thanks for you reply izzy.

Thats good news.
Some questions still....

Which version of location and Gmap are you using?

Did you as well had the errors mentioned in http://drupal.org/node/373465 #57 #76 #61?

Did you use a patch mentioned in http://drupal.org/node/373465 and if so which one?

Thanks.

Byron

I'm using the latest Gmap 6.x-1.x-dev and Location 6.x-3.1-rc1.
I did not have the errors described and I think comment #76, http://drupal.org/node/373465#comment-1695758 answers that.
I did not need to apply any patch. It appears it is already in this version.

Izzy

I'm a bit suprised.

I have the same versions.

In the following scenario i'm getting errors.

-Both Gmap and Location CCK are configured to let users set lattitude and longitude data by using a Gmap.
-Users can also add a postal code

Now when i want to edit a node which has the lat. and long. + postalcode data under contentmanagement by putting a mark before the title and choosing for unpublish and click update i get:

    * warning: array_filter() [function.array-filter]: The first argument should be an array in /home/mysite/domains/mysite.com/public_html/sites/all/modules/location/contrib/location_cck/location_cck.module on line 385.
    * warning: array_keys() [function.array-keys]: The first argument should be an array in /home/mysite/domains/mysite.com/public_html/sites/all/modules/location/contrib/location_cck/location_cck.module on line 385.
    * warning: Invalid argument supplied for foreach() in /home/mysite/domains/mysite.com/public_html/sites/all/modules/location/location.module on line 1440.

i'll add this to http://drupal.org/node/373465#

Izzy, thanks for your insight

@held69

I'm not sure what to say. No array errors here.

In my setup the user permissions under location module do not show any role with permission to submit latitude and longitude.

In the cck location field, under collection settings, coordinate chooser is allowed, under display options coordinates and coordinate chooser are hidden. With these settings the coordinate chooser does not appear to the user, they simply enter their address including postal code. I do not think the fields are forced. When I was doing some testing I tried just entering a postal code, or just entering a street address and city and I think it worked either way.

Not sure if that helps any.

Izzy

Thanks again

i've posted this as an issue in the thread jus mentioned.

An upgrade path will be necessary, to convert node locations to cck fields, when choosing cck route which might just end up replacing the conflicting node locations.
See #391160: CCK/Views: location_instance fix

Any news on an upgrade script to move data stored via the legacy Location module into location_ccK fields? I'm not a MySQL expert, but on the face of it this doesn't appear to be a hugely challenging task for someone who knows how the modules work.

Just want to keep this alive, many people looking for it I bet.

Any fresh take for 2010 re: when it's OK to go back in the water? I have an issue where I can't stop users from being able to edit node locations on node/edit and would like to migrate to CCK Locations if it's recommended to do so.

wild thought to be investigated:
migrate extras for an upgrade path
http://drupal.org/node/459236#comment-2757412

I personally see merit in working on an upgrade path... but I sense there may be critical problems with cck still... ??? People should not upgrade yet, things still in flux, but I think we could work on testing an upgrade path?!

Would making an upgrade path (and not recommending people take it) be too confusing? Should we hold off on an upgrade path until cck locations are "ready"?

Well, I guess it depends on whether they are ready or not, yet, and I personally do not know. I've used them on certain content types without significant errors, but I was using only the most basic features of the module.

Subscribing

subscribing, I am also interested on the upgrade path, if any.

subscribing, tons of locations stored as Location Node and looking for a migration path to CCK to acquire more flexibility, as the option to bulk modify CCK field with VBO.

I know this is old but I'm just cleaning up a few issues.

Support and feature requests do not use the critical priority.

For more info see http://drupal.org/node/45111

As for cck vs node locations, CCK locations are the superior option and are definitely now stable.

It seems this issue is going the way of an upgrade path so I would say that it is possible and should not be so hard to do, although it would obviously have to come with the caveat that you should back up your data first and it is possible you might lose data etc.

This will be especially useful in drupal 7 seeing as node locations will eventually be removed from that version.
It also should be done in drupal 7 first anyway so changing version.

For drupal 7 we can also migrate from users to cck.

I have found an automatic way to migrate "old" node locations to the new location cck, which fortunately use the same location table to store locations.

First I looked at which nodes use locations.

SELECT DISTINCT type FROM location_instance li, node n WHERE n.nid=li.nid AND n.vid=li.vid;

Now I know what node types need a new location field. I created a CCK field called geolocation (field_geolocation) and assigned it to the content types listed above. This created a new table, in my case called field_data_field_geolocation

mysql> DESCRIBE field_data_field_geolocation;
+-----------------------+------------------+------+-----+---------+-------+
| Field                 | Type             | Null | Key | Default | Extra |
+-----------------------+------------------+------+-----+---------+-------+
| entity_type           | varchar(128)     | NO   | PRI |         |       |
| bundle                | varchar(128)     | NO   | MUL |         |       |
| deleted               | tinyint(4)       | NO   | PRI | 0       |       |
| entity_id             | int(10) unsigned | NO   | PRI | NULL    |       |
| revision_id           | int(10) unsigned | YES  | MUL | NULL    |       |
| language              | varchar(32)      | NO   | PRI |         |       |
| delta                 | int(10) unsigned | NO   | PRI | NULL    |       |
| field_geolocation_lid | int(10) unsigned | YES  | MUL | NULL    |       |
+-----------------------+------------------+------+-----+---------+-------+
8 rows in set (0.00 sec)

Next I made a backup of my database and ran the following MySQL query (li.uid = 0 filters out all user locations)

INSERT field_data_field_geolocation(entity_type, entity_id, revision_id,bundle,field_geolocation_lid,language)
SELECT 'node', li.nid AS entity_id,li.vid AS revision_id,type AS bundle,lid AS field_geolocation_lid,language
FROM location_instance li,node n
WHERE li.uid=0 AND genid = '' AND n.nid=li.nid AND n.vid=li.vid

After clearing the cache (important), all my new CCK location fields magically showed the "old" location and addresses. All that needed to be done was to disable node location for the node types.

Your mileage may vary. I only had ONE location assigned to any of my nodes, so in case you use multiple locations per node you will have to look into how that is handled.

#28 looks like a nice starting point for creating migrate(update) path

I would recommend doing a node load, setting the field values and then a node save as opposed to just doing direct database queries.

You could have a UI where you could select which field they are to be put in (in case there are multiple location fields).

It should probably also use the batch API to do the updates in the case there are a large number of nodes.
Batch size could be configurable.

Language support should not really be needed because node/user locations are not multilingual.
We should just be able to add them under LANGAUGE_NONE.

#28 works perfect. Thx a lot!

Hi,
Is this still necessary to Migrate Location info to a D7 site?
So is the strategy first to go from Node Locations to CCK Location field on D6, like on https://www.drupal.org/node/375259#comment-7212220
And then migrate Location field D6 to Location field D7?
Or is Ordinary Location migration to Location field in D7 implemented? I do not see this in the Migrate UI..
greetings, Martijn