I have a custom content type that uses the location cck field. When I edit a node of that content type, and enter all the information in the address fields (Location Name, Street, City, State/Province, Postal Code, and Phone number), and save the node, the Location Name, Street, City, State/Province, and Postal Code do not show up. The Phone number, however, does. Examination of the database tables shows that the location address fields are not getting written to the database.

I have another custom content type that uses the same location cck field, with the same configuration, that *is* saving the location to the database. When nodes of this content type are viewed, both the address and phone number show up (and I see entries corresponding to this data in the database). Unfortunately, the custom content type for which everything works is a dummy one I created in order to try to narrow down the problem.

Comments

eswenson’s picture

eswenson commented

I noticed, from watchdog logs, that I was getting the error message: Conserving lid N due to uniqueness whenever nodes were saved with location information such that the location address info was lost. This error message did not happen with the "other" content type, that never appeared to have problems.

So I changed these lines of code:

if (!empty($location['lid'])) {
watchdog('location', 'Conserving lid %lid due to uniqueness.', array('%lid' => $location['lid']));
drupal_write_record('location', $location, array('lid'));
}
else {
unset($location['lid']);
drupal_write_record('location', $location);
}

so that the first drupal_write_record did NOT pass the third parameter. This caused the address information to save to the database and appear in subsequent views of the node.

I'm sure this is a complete hack that has other (bad) ramifications -- but it appears to work for me. My hope, however, is that the developer of this module will know what the right solution is.

eswenson’s picture

eswenson commented

This appears to be related, or the same problem as http://drupal.org/node/378132. It is most certainly still an open issue because it is happening with the latest release of the location module on the latest release of Drupal 6.

yesct’s picture

yesct commented

just linking 378132 with the [#nnnnnn] notation to get a nice link

#378132: Deleting unreferenced location with LID

josesanmartin’s picture

josesanmartin commented

I confirm that altering line 1142 of location.module from:

drupal_write_record('location', $location, array('lid'));

to:

drupal_write_record('location', $location);

makes the problem go away. Any ideas of the consequences, though?

ddbell’s picture

ddbell commented

I changed to:
drupal_write_record('location', $location);

and still not working. Any entries to the location section do not save including coordinates.

I flushed cache and not working.

Any help would be appreciated. Thanks.

pwaterz’s picture

pwaterz commented

There problem is you can not have node location and cck location enabled at the same time. Look here http://drupal.org/node/860820 ....I have not look at the code at all, but could this be a name space problem. Both are altering the form, could they both be conflicting with form names?

kristen pol’s picture

kristen pol
she/her
Primary language English
Location Santa Cruz, CA, USA
commented

I turned off (and uninstalled) location_node module because none of my address fields were saving (including phone), but now only the phone field is saving.

If I try removing the lid like mentioned in #4 above, then the address data is saved but I'm sure this is not the correct fix for the problem.

[update] It appears that any *new* nodes created are fine but any old nodes that were edited when the location_node module was on are not happy (even after full uninstall and clearing cache). I'm still debugging and hoping to find a way to get a clean fix without having to make the code change above. But, doing that code change and re-editing all old nodes, does fix the problem... so if you only have a few nodes that are affected, then you can temporarily do the code change, re-edit all nodes, and then change the code back.

Kristen

nally’s picture

nally commented

I'm running into this as well. Thanks for that last update Kristen.

For me, my errant LID is 15. I'm noticing that the location table has no row with LID 15, but location_instance DOES. Further, the node I'm trying to edit has two entries in the location_instance table. (I also used to have node_location installed).

Could the fix here be that the code needs to look for instances of the LID in both tables? (I'm not sure of the assumptions being made within the module code about rows corresponding).

I'm in a position where I could just delete all rows in both tables. Would that be safe and sufficient to wipe out all my location values and start fresh?

UPDATE:

Merely deleting rows from location and location_instance doesn't help. LID 15 is recreated in location_instance. Incidentally, the row that comes back has the following for the genid: cck:field_location:913 where 913 (matches the revision for the node involved).

SECOND UPDATE:

Oddly, deleting all rows did get me going in the end, but only after I'd added a new node.

alexbk66-’s picture

alexbk66- commented

*subscribing*

Steve Polito Design’s picture

Steve Polito Design commented

I do not have node locations enabled, but rather location cck. I have updated the postal codes of over 3,000 nodes using the feeds module. The info is saving, but when I do a proximity search using a views filter, nothing happens. However, when I go in and delete the postal code, save the node, then go back and add the postal code and save, the node appears when I search based on proximity. The same applies if I simply delete the postal code. Every time I update a node location I get a message like this in the logs Conserving lid 1234 due to uniqueness. Any ideas as to how I can update all my nodes with out manually doing so?

legolasbo’s picture

legolasbo
he/him
Primary language Dutch
Location Middelburg
commented
Issue summary: View changes
Status: Active » Closed (outdated)

Closing old D6 issues as D6 is end of life