Support Location module: Location CCK

Not on my To Do list, but if anyone wants to create a patch for this or commission me to develop it I'll be happy to add this feature.

The attached file should add support for location fields. Just add it to the supported folder within user_import.

Looks interesting. Which version of User Import is this for?

Ah, never mind, I can see the version setting is 5.x-2.x-dev, cool.

I'll review it ASAP.

Anyone wants to test this before I review it?

_location_effective_user_setting does not exist anymore in the recent version of location-module.

The function _location_save also does not exist. This seems also to be something the location-module get rid of. Is the function identical with the location function location_save?

Just pointing out that I was informed these issues are related, and I'm interested in a fix :)
#652724: User Import can't important node-based location info for content profiles

Cheers all!

anyone had any luck with this in 6.x?
I tried the zip in #2, but was of course met with white-screen of death... really need to import 1000 users complete with postcodes (zips).

Subscribe

I'm also interested in this. Can anyone help with the development? Any chance of an update?

We would be interested in this functionality for 6.x as well.

subscribe

I've got this working with Location CCK fields in a user's Content Profile, but you'll need the patch (which is against CVS HEAD) below. The root of the problem is that, unlike other CCK fields in Content Profile which are of the format:

[field_profile_fieldname] => Array
        (
            [0] => Array
                (
                    [value] => xxxx
                )

        )

Location CCK are like this:

    [field_profile_locationname] => Array
        (
            [0] => Array
                (
                    [lid] => xxxx
                    [name] => xxxx
                    [street] => xxxx
                    [additional] => xxxx
                    [city] => xxxx
                    [province] => xxxx
                    [postal_code] => xxxx
                    [country] => xxxx
                    [latitude] => 0.000000
                    [longitude] => 0.000000
                    [source] => 0
                    [is_primary] => 0
                    [province_name] => xxxx
                    [country_name] => xxxx
                )
        )

So when content_profile_user_import_node() sets every different location "field" (e.g. postal_code, street, country, etc) like this:

$node->{$field_name} = $field_value;

The whole array is overwritten and all the information lost, except for the last field to be imported!

The patch below is rather hackish as it implements a whole new logic flow for 'location_cck' fields ONLY, where I would prefer to have something which would work for both Locations (and other "groups" of fields?) and "normal" single-value CCK fields. I'll probably revisit this and try to come up with a better way of doing it, but if anyone has any better ideas I welcome all posts :)

Found another problem, though I am not entirely sure where the root cause is.

The symptoms are that the Country field in the import MUST contain the country code in lowercase, and not the country name or other-cased code. This is in contrast with http://drupal.org/node/64234#comment-407972 for example, which states that "you can now enter the name of the country (Belgium) or the country iso code (be)", and with the fact that node_import/supported/location_cck.inc actually sets the 'allowed_values' for Country fields correctly.

For some reason, when being imported with User Import, these 'allowed_values' are not taken into account, and in fact node_import.inc:node_import_values() does not to run, so none of the 'preprocess' functions appear to be being called to verify imported fields.

I've not been able to track down where the root cause of the problem is, but the patch below (against CVS HEAD, and thus conflicting with my patch in #14) simply looks up the imported data as either a country code or country name, and makes sure to set the relevant country code.

Still cannot import location data via user_import -> node_import -> content_profile -> location [cck]. Using pressflow 6.17.85 with just about every possible combination of:

- User Import 6.x-2.3 or CVS HEAD
- Node Import 6.x-1.0-rc4 or 6.x-1.x-dev (2010 Jul 11)
- Content Profile 6.x-1.0
- Location 6.x-3.1

Even tried patch #14 this thread, and the patches and "solutions" put forth in threads elsewhere. In each case, I can get location CCK (but not location) fields to show up in the user import mapping form, but only the fax number actually makes it through the import.

This may not be purely a user import module problem, as I have similar difficulties attempting to import via the node_import UI as well.

Anyone else have other ideas or things to try?

@higherform: I've imported 35,000 users with this, so there's probably something going on with your source data. Any chance of some samples (not too many!) so we can have a try at diagnosing the problem?

I created a support file for the User Locations component of the Location module.

This works for the latest release of both Location and User Import. Just rename the file to location.inc and drop it into the user_import/support folder.

It uses the Location API to support country/province validation and to respect location defaults. It needs the User Locations submodule to be enabled and configured in admin/user/settings.

Cool, this exactly the way it should be done.

I'll take a look at including this with the User Import module.

In the mean time please help test!

Not Location CCK, though :(

No, the purpose of my patch is to do it through User Location. I'm thinking it shouldn't be hard to adapt it to Location CCK, since it essentially uses the same mechanisms for validation and everything else.

My guess is that, to make it work, you have to change location_save_locations() at the end of my patch to take a criteria array for the content profile node:

$criteria = array(
  'genid' => 'cck:'. $field['field_name'] .':'. $node->vid,
  'vid' => $node->vid,
  'nid' => $node->nid,
);

Since I haven't dealt with user_import with Content Profile, I'm not sure how to get access to the $node object. Also, you have to figure out the name of the field. Those two things should not be hard at all; I just haven't spent any time on it.

As for testing, I managed to import a CSV with over 2000 users, and it worked flawlessly. Anyone else managed to test it?

I imported 35,000+ with #14 and #15 applied -- but that is Location CCK in Content Profile, not User Location.

Looks like between the two of us, we've covered all the bases?

Which one did you use to patch? #15 seems like an update on #14, instead of two independent patches.

Also, we need to roll both patches into one before we can consider this RTBC.

if there's two different modules that need integration with User Import module maybe it's best to start a separate issue for one of them?

That way we can test and develop each separately.

Since I'm the late comer, I created a case for the User Locations component of the Location module. I renamed this to differentiate them. The case is #918292: Support Location module: User Locations.

These lines need to be cleaned up before I can accept the patch in # :

$p = strtoupper($obj['province']);

foreach ($provinces as $k => $v) {
if ($p == strtoupper($k) || $p == strtoupper($v)) {
$found = TRUE;
break;
}
}

$obj doesn't exist as a variable.
All variables should have meaningful names, not $p, $k, or $v.

I attached an updated version. Thanks!

Thanks vkareh, I'll try to test and commit it this weekend.

Any movement on this? I've tried all the combinations above to import into cck location for content profile and I end up with empty location data in the nodes.

As a note, I didn't even see the location fields as an option until I updated node import to the 6.x-2.x-dev version.

Anyone else gotten this to work? Which versions of everything are you using? (changing issue to HEAD since it's assumed where this work is happening)

Robert, I would he happy to test this out for you. I've got 2.4 installed. If you can get me a dev release and/or the current patch you are working with, I'll give it a shot.

I got Location CCK working today with the CCK field on the Content Profile profile. Please note, there is a bug/issue in Location CCK which causes it not to save any data if Node Locations module is enabled. So you have to use one or the other.

In my case, I didn't see this bug but I had to make some changes to content_profile.inc. The changes are kind of generic in that if you have a cck field with multiple parts, content_profile.inc content_profile_user_import_node would only save the last part it encountered.

For example, if I have a Location CCK field named address I have the following in the node:

   [field_address] => Array (
        [0] => (
            [street] = "123 Pixel Lane",
            [city] = "Raster",
            [state] = "California"
      )
)

The code was doing things like this
$node->{$field_name} = $field_value[0];

field_value is just the value of one of the parts above. So assuming that "state" was the last one encountered, we would end up with

   [field_address] => Array (
        [0] => (
            [state] = "California"
      )
)

So I changed it to for UPDATE_REPLACE and the adding new content_profile nodes
$node->{$field_name}[0][$field_key] = $field_value[0][$field_key];

This also fixed issues I was having with other multipart cck fields like the name cck field.
I'm attaching my patch in case anyone finds it useful.

Subscribing.

I've used the location.inc in Post #27 successfully. It works for imports and import updates without any problems. I have not tried it with custom location cck fields yet.

n/a Duplicate for some reason.

Tested the patch bkat posted in #31. It fixed the issue of only the last field in the address field set being imported.

So is #31 ready for a full review?

What modules do I need to install, and what steps do I need to take to review it?

I saw this thread after I had rolled my own fix for multi-part/multidimensional CCK fields.

it is working for me with Location CCK fields that have only one location (it probably won't work when the field can have multiple locations).

Applied #31 Works like a charm, thank you for contributing!

I can confirm #31 worked great! Thanks.

I have no idea if this is where I'm supposed to be looking :-|

On drupal7, if I enable location and location cck, I can add location fields to users.
No need for profile2 or location_user.

User import 7.x-2.2 contains location.inc, which is a copy of #27.

When I try to import (anything), it warns, it the second ui step

Field Location is not supported

location.inc starts with the line
if (module_exists('location_user')) {
but that module isnt enabled here. i've just been
adding cck fields to users.

if I comment that line out the error goes away, I can map fields,
but on import I get errors on every user, as expected.

I see patches here for cck fields in content_profile (#31,#36), but
if I look at content_profile.inc, it starts with
if (module_exists('node_import')

There is no node_import for Drupal7 afaik - is content_profile.inc
only supported for drupal6 ? And, am I using profiles at all in d7 ?

The name of this issue is 'Support Location module: Location CCK';
it sounds applicable to my problem, but I'm totally lost ..

*-pike

What I see in the database, is that, for users i created in the backend, the location_instance table both have a uid *and* a genid (like cck:field_location:53) for each location. that makes sense, its pointing to a user entity, but a specific cck field within that user entity. Users created by the import only have a uid (which is exactly what location.inc does). Immediately after being created, they get deleted for being unreferenced (I can see this in dblog). Bummer.

I guess having only a uid makes sense if the 'User Locations' module is enabled, because that relates users to locations. In fact, that module is the prerequisite for location.inc.. if (module_exists('location_user')) {

However, the request here was: can we support Location CCK fields. location.inc (#18) doesn't do that :-(
#31 and #36 are about cck fields, but then they are not about user entities. They store their info in profiles, which are node entities.
So I think I'm not seeing what I need here ... though its really close ...

The 7.x-3.x contains location.inc, (based on #27).

There are further patches (#31 and #36), but they look wrong, as they go into other files. I believe location.inc and that other parts should not be bloated with code that only apply if the location module is enabled.

Bumping it back to "Needs work" for now, but it might be better to close this one, and then open a new issue to address specifically any problems that remain in location.inc?

(I leave that call to the maintainer.)