Location data not saved (when only have country filled in, and leave it as the default country) problem w location_strip()

I confirm the bug.

No errors arise, but when you change coords in a node, the coord changes WILL NOT be saved (as if you clicked Back instead of Save).

If you change the country field in addition to the coords, the changes WILL be saved.

This is not a matter of default country. It requires the country field to be changed, no matter whether you do that from default to custom, from custom to default or from custom to custom.

I believe I might be having the same problem.

After doing a bit of digging, I think there might be an issue with how some of the data is being saved. It may also be a misconfiguration on my part. In either case, would you be able to point me in the right direction?

Please see the following screenshots:

node_locations_query.jpg - This is the query that is executed when you attempt to go to the "node locations" page. The first INNER JOIN makes the data in the location_instances table required.

SELECT n.nid, n.type, n.title, l.latitude, l.longitude , m.marker
    FROM node n
    INNER JOIN location_instance i
      ON n.vid = i.vid
    INNER JOIN location l
      ON l.lid = i.lid
    LEFT JOIN gmap_taxonomy_node m ON n.vid = m.vid
    WHERE
      n.status = 1
    AND
      (l.latitude != 0 OR l.longitude != 0)

location_instances.jpg - this is what is being stored in my location_instances table. As you can see, the NID and VID columns are all zero. This seems bad.

                                nid 	vid 	uid 	genid 	               lid
  	Edit   Delete   	0  	0  	0  	cck:field_location:2  	2
	Edit 	Delete 	0 	0 	0 	cck:field_location:13 	3
	Edit 	Delete 	0 	0 	0 	cck:field_location:15 	4

node_save_query.jpg - When I create a new node, saving the location data as part of it, these queries get executed. In here, the data is deleted, and when it gets recreated, it only sets the two columns... and NOT the NID or VID columns.

DELETE FROM location_instance WHERE genid = 'cck:field_location:15'
INSERT INTO location_instance (genid, lid) VALUES ('cck:field_location:15', 4)

Please let me know if you may need any additional information, or if you may know what I might be doing incorrectly.

Thanks.

I think i may have a potential fix for the issue I mentioned above.

It seems that the problem is that when location_save_locations is called from within location_cck_field the following is executed:

    case 'insert':
    case 'update':
      // Store instances of locations by field name and vid.
      $genid = 'cck:'. $field['field_name'] .':'. $node->vid;
      location_save_locations($items, array('genid' => $genid));
      // CCK automatically picks up the new lids and stores them in its own tables.
      break;

The patch I've attached will update this to be:

    case 'insert':
    case 'update':
      // Store instances of locations by field name and vid.
      $genid = 'cck:'. $field['field_name'] .':'. $node->vid;
      location_save_locations($items, array('genid' => $genid, 'nid' => $node->nid, 'vid' => $node->vid, 'uid' => $node->uid));
      // CCK automatically picks up the new lids and stores them in its own tables.
      break;

Note: The difference being the addition of the nid, vid and uid columns being passed into location_save_locations.

Since I'm new to using this module, I'm not entirely positive that this will have no negative impact, but with my implementation, it does appear to work just fine.

One thing that this may alter is if revisioning is enabled on the site. With the new parameters being passed in, an instance will be inserted for each revision. The reason for this is the existence of the vid in the table. The delete statement within location_save_locations deletes only exact matches of all the columns passed in.

Hope this helps.

thanks for posting a patch!

tagging.

I think there are some duplicates of this issue reported in the queue... but I dont have the time to find them. Maybe someone else could look, maybe search for "country default" or "country default save"

http://drupal.org/project/issues/search/location?text=default+country+sa...

I can confirm this critical bug!
Patch from #8 is working, thx, but I don't think that this is an appropriate solution?

Subscribing, needing solution for this also.
Anyone has a prober solution?
Greetings, Martijn

Subscribing, where experiencing the same problems. The patch does work, only partially, the selected location is altered when saved and is not displayed on the same location

Subscribing, too.

subscribing

See if this helps, please.

Locpick is being stripped out, but I forgot to copy out the changes first.

Hopefully this works without introducing regressions.

(From #511378)
* Fix emptiness check centrally, instead of relying on location_save().
* Remove cck validator -- the condition it was checking for was a bug, not
a feature.

http://drupal.org/cvs?commit=244962
http://drupal.org/cvs?commit=244966
http://drupal.org/cvs?commit=244968

This should take care of this bug.