Using CCK 6.x-2.8, location 6.x-3.1, d6.17

When a 'project' node type with 2 location CCK fields is saved, none of the location information is saved. It's as if there was nothing in those fields, excpt that their titles are displaying. No record of it in the database...

Was apparently an issue before and fixed by Bdragon: http://drupal.org/node/347091#comment-1185760
And then again a patch: http://drupal.org/node/346605#comment-1442872

But the patch is older and the code has changed.

Help!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mrcharles’s picture

Snap - I have the same problem...
Please help!

007pig’s picture

Please disable "Node Locations" and "Location Add Another" module. They're conflict with "Location CCK".

Tech explain:
Node Locations inserts nid and vid to location_instance table.
Location CCK inserts nid, vid and genid to location_instance table.

After Location CCK calls location_save_locations(), Node Locations will call location_save_locations() again with the same nid and vid. Then location_save_locations() thinks that the 'lid' (location id) is an unreferenced location and then deleted the locations Location CCK just creates.

If this error happens, you will see "Deleting unreferenced location with LID X" in system DB logs.

rp7’s picture

I can confirm this. Thanks for the solution.

albert9000’s picture

This solution is not working for me. I've disabled the Node Location and User Location options, and I've uninstalled them. Still no luck. I never had Location Add Another enabled. I suppose I should try a reinstall of the module.

-------------------------------------
Update: This solution does work. I needed to clear my cache.

entilza72’s picture

A warning to others - I used this solution, and it wiped out all of the locations in all of my nodes. The data still shows up in the node location maps, but it is missing in the node view itself, and when editing a node.

So whilst the usual warnings apply (back up your live data), it does leave you holding the can in terms of how to migrate that data. Fortunately, my site is not live, so I've only lost test data and I do not have to worry about migrating the data. But someone will...

Cheers,
Jason.

entilza72’s picture

Hi gang - the advice to disable "Node Locations" will have ongoing negative impacts for some Drupal sites, besides the data loss issue I highlighted above. I do not believe this is a "solution" to the problem.

With "Node Locations" disabled as suggested, the URL Aliases module no longer processes Location tokens for example. I am sure the URL Aliases module is not the only one depending on Location information in this way.

Does anyone have a suggestion for how a node can make its Location Tokens available to modules when "Node Locations" has been disabled? Otherwise, a patch/alternative solution may be needed.

A walk-through example:

1. Ensure Location fields are enabled in your node, but with "Node Locations" disabled (as above). Also ensure you have installed/use URL Aliases module.

2. Enter a valid location token into the URL Aliases module under "Automated alias settings" for your node (eg use the token [location-country_name_0] or [location-province_name_0] as a parent directory for the URL). This will successfully save (as opposed to an error if you add an incorrect token) because the location token is correct and known to the system.

3. Bulk generate your node URL (delete the alias beforehand if the node already exists).

4. Now check the node's URL. The Location token part of the URL fails to be interpreted, instead it shows up as the token name (eg "[location-country_name_0]" instead of "Japan"). All other tokens work fine. This implies URL Aliases are working as expected, but just the location tokens are failing to be interpreted.

5. Now re-enable "Node Locations", delete the existing URL Alias for the failed node, and rebuild under "Automated alias settings". You will see the URL now has correctly translated the token.

Cheers,
Jason

bluesherpa’s picture

I ran into this and disabling the listed modules did nothing to fix the problem. Luckily, in my case, I didn't have any data to worry about. The only way I was able to get it working again was to remove the field from the node, save, and then go back in and re-add it.

stefan81’s picture

subscribe

Alan D.’s picture

@Bdragon Any work done on this? We have just effectively lost 7000 locations on a live site and will require a data mirgation or fix asap. We have not yet tried dev.

I.E. Will we be starting afresh or have you done some work on this?

For reference #857000: Migrate from node location to cck location

kpojeta’s picture

Not sure if this helps but I am having this same issue, however, the phone and fax numbers in the address are retained. All other information is lost (Address, additional, city, state, zip, country).

stefan81’s picture

#2 worked for me

adamwhite’s picture

#2 worked for me as well.

Steven_F’s picture

Subscribing

modulist’s picture

Title: CCK Location Fields won't save. » Make sure you delete the affected CCK field(s)

#2 helped, but I didn't see results until I deleted the Location fields I had created in CCK.

sunchaser’s picture

disabled the Node Locations module as proposed in #2
Removed the CCK field "Locations"
Re-added the CCK field

works

Alan D.’s picture

Title: Make sure you delete the affected CCK field(s) » CCK Location Fields do not save when Node Locations are enabled.
Version: 6.x-3.1 » 6.x-3.x-dev
Issue tags: -not, -saving +node location, +not saving

Reverting the title - this should represent the active issue, not a single step in the solution!

IT-Cru’s picture

Perhaps their should be a way to set the node location to a number of 0 and then only the CCK locations would be saved? It's not fine but perhaps a possible coding work-around?

I Think many people uses first node_locations so they have many location data bindings to nodes and then activate and use CCK locations. Their should be a warning that node locations and cck locations does not realy work together yet.

capellic’s picture

I had to remove and then re-add my CCK field. We need an upgrade path. Or we at least need to have a warning during module installation that the modules conflict.

rooby’s picture

Subscribing so I remember to come back and have a look into this.

rooby’s picture

Priority: Critical » Major

I have now added information about this issue to the INSTALL.txt file in the module and to the location handbook on drupal.org.
For more details see #860820: Teach location_node how to avoid cck locations

For reference, to disable node locations for a content type set the max number of locations to zero on the content type edit page.

I have been investigating this while getting cck locations to work in the D7 version (they wouldn't work at all, even when node locations were disabled - #1048658: location_node is interfering with location_cck saving locations) and it doesn't seem like there is a nice easy solution.
It will probably require a rewrite of the location_save_locations() and location_save() functionality, which will probably not be a minor change.
So it will possibly not be addressed in 6.x-3.x and it will probably have to be done in the next major version.

Setting as non-critical because:
* Node locations and CCK locations weren't intended to work together.
* The functionality of the location module is not broken. Node locations and cck location both work, just not together.
* There is now information available to tell people about this known issue.

Alan D.’s picture

Add the warning to the project page. Personally haven't read one of these files for over 2 or 3 years (unless instructed to do so from the project page). Maybe throw big red warning messages during the install to make the point really clear???

rooby’s picture

Yeah, I'll put up a message on the project page.

I often don't read the README & INSTALL files these days either unless I have an issue, then I do.
Most issue queues will tell you if you don't read the documentation you have no cause for complaint.

rooby’s picture

I can add a message when you enable the modules too.

js’s picture

Until I read this thread, I didn't know that "CCK location" worked without "node location" enabled. My logic error, obviously, but I had pictured the CCK field as wrapper. Obviously not. I see that now. I only comment because if this is in the documentation, I missed it completely.

rooby’s picture

The notice is only now on the project page and has only been in the handbook and INSTALL.txt for about a week so that probably explains how you missed it.

lukebrooker’s picture

I am having the same issue even though I have never enabled the "Node Location" Module. The CCK Location will just not save. Is there something else that could also be doing it? I am using Domain Access, Revisioning and Workflows. I haven't had any problems like this so far.

Danny Englander’s picture

Subscribing, same issue. Disabling node locations enabled CCK Location to save and display the data.

scotwith1t’s picture

This is kind of a pain, so I've just gotten in the habit of disabling location name for collection and display, using another regular text field for location name and using that field for auto_nodetitle patterns. Would be nice to just use the built-in location name field though. I can't seem to make the location name token work unless I go back and edit and save the node again, so I'm going with my alternate method for the time being.

tahiticlic’s picture

This bug is common with 7.x-3.x-dev version : even with GMap, GMap location, Location, Location CCK enabled only, location data are not saved.

lukebrooker’s picture

I looked at my database and for some reason their were no location tables created. I disabled and uninstalled all location modules then reinstalled them and it works fine now :)

drew29’s picture

FileSize
33.59 KB

Hej,

sorry I was wrong here is the right post for the drupal7 version http://drupal.org/node/1064666

kind regards
drew

spyderpie’s picture

#24 - I didn't realize this either, I also thought cck locations was a wrapper for node location.

#30 - disabling and uninstalling all location modules also worked for me.

Now if I could just get the markers to show on the map ........

Julie

alexbk66-’s picture

Can anybody please explain the difference in usage between 'node location' and 'location cck'?
If I simply want a location associated with a content type, also a map of locations, which one should I use?
Everything I read about this problem says to disable 'node locations' and use 'location cck', but then what's 'node locations' for?

Currently I realized that I have both enabled, I did notice some problems, but can't work out exactly what to do.

HobbyBlob.com

nags338228’s picture

I don't know wht i did. I jus tried out a trick, and it's working fine ... I jus copied this case 'update' from location_cck.module in node_location.module file line 43

    case 'update':
/*  -----     if (!empty($node->locations)) {
        location_save_locations($node->locations, array('nid' => $node->nid, 'vid' => $node->vid));
      }
      break;*/
      $criteria = array(
        'genid' => 'cck:'. $field['field_name'] .':'. $node->vid,
        'vid' => $node->vid,
        'nid' => $node->nid,
      );
      location_save_locations($items, $criteria);
      // CCK automatically picks up the new lids and stores them in its own tables.
      break;

if any one having issues please let me know..

pdrake’s picture

Even after location_node is disabled, locations which may be in an inconsistent state (no location record, but a location_instance record) are not saved because location_load_location returns an object with a lid even if a location does not exist with that lid. An UPDATE SQL statement is then executed although there is no record to update. Attached is a patch to fix the problem by returning false when a location does not exist - allowing the location to be inserted rather than updated.

pdrake’s picture

This is the same as the patch in #35 except FALSE is appropriately capitalized.

pdrake’s picture

There is another case in which an update may be attempted against a non-existent location which may have been deleted by another CCK field in the same node save. The attached patch fixes both the above case and this case.

pdrake’s picture

If you have had Node Location and CCK Location enabled at the same time, there may be entries missing from the location_instance table, which will cause data loss if/when nodes are edited which appear to have a CCK Location entry. Below are two queries which may be used to restore these entries.

Depending on the normalization of your CCK tables, one of the following two should be used for each of your location fields. The first should be used if CCK has created a separate table for storing the location lid (if a table named content_FIELD_NAME_HERE exists). The second if CCK has included the field data in the content type table. Use at your own risk.

/* Restores location_instance entries for normalized content fields */
insert into location_instance(nid,vid,uid,genid,lid) select nid, vid, 0, concat('cck:FIELD_NAME_HERE:', vid) as genid, FIELD_NAME_HERE_lid from content_FIELD_NAME_HERE where FIELD_NAME_HERE_lid != 0 and FIELD_NAME_HERE_lid not in (select lid from location_instance where genid like 'cck:FIELD_NAME_HERE:%');

/* Restored location_instance entries for non-normalized content fields */
insert into location_instance(nid,vid,uid,genid,lid) select nid, vid, 0, concat('cck:FIELD_NAME_HERE:', vid) as genid, FIELD_NAME_HERE_lid from content_type_CONTENTTYPE where FIELD_NAME_HERE_lid != 0 and FIELD_NAME_HERE_lid not in (select lid from location_instance where genid like 'cck:FIELD_NAME_HERE:%');
bramface’s picture

pdrake, this was really great work on your part! Very complex problem (seems to me) and artfully solved. The SQL query was a particularly nice touch. Thank you for your thorough care!

-bram

ymeiner’s picture

This should be resolved in both modules.

  • the location cck side - that needs to have the ability to "sync with node location" if exists
  • node location side - should act like pdrake's patch.

This problem is not resolved even on 7. FYI

Maybe next week i will have time to create a patch for it.

for my website, i know i have one location to every content item. this gives me the ability to just add the following row to the update and insert functions at the end.

$entity->locations=array_intersect_key($items,$entity->locations);

it is better to have some sort of checkbox in the field settings that says - sync with node location. In this case:

if checked....{
        $entity->locations=array_intersect_key($items,$entity->locations);
}

Yaron

aerozeppelin’s picture

#14 worked for me

aitala’s picture

A quick question - I need to give a node (an event) a location which will be displayed on a map and a location (for the contact person) which is not displayed on a map.

I had tried using both node location (for the event) and CCK location (for the contact person) for the event content type and hit this bug.

What's the easiest way to handle this?

Thanks much,

Eric

doublejosh’s picture

@aitala
After reading through it looks like you'd need disable both the Node Location and Location Add Another modules.
Then create your CCK field of type location with the CCK Location module turned on.
OR
You can leave them both on and transfer the data over as shown in the query in #38.
Bottom line... giant pain.

Tempting to create a mySQL script that would push all the data across into the new field (with both modules on) then remove the Location module.

ChrisValentine’s picture

Under a Drupal 6 install, I have user locations working but I can't get markers to appear on my node locations map. I've tried various combinations of Location and CCK Location modules but it doesn't make any difference - but the location data always seems to stay with the node records, so I don't think its a data issue.

In GMap Location settings, I've used exactly the same value for the Macro as for user locations.

I also followed this video to create a page via Views but again I get a map with no markers:
http://www.drupalove.com/drupal-video/gmap-location-module-and-views

Permissions seem to be correct for each of my user types - each location-related field is on, apart from "administer user locations".

ChrisValentine’s picture

Status: Active » Closed (works as designed)

My mistake - I had not enabled geocoding options for the countries I was putting nodes in.

Administer › Site configuration › Location > Geocoding options

Alan D.’s picture

Status: Closed (works as designed) » Active

@ChrisValentine Please do not close active issues. I'm glad you resolved your own separate, but unrelated issue. :)

apoc1’s picture

I still have this bug in the lastest 7.x version; even with node location and "add another" disabled, location fields are not saved when saving the node..

loze’s picture

I was also having this issue of the fields not saving using the latest 6.x-3x dev branch
- I never had location_node or location_add_another enabled.
- i am using location_cck

I think I tracked it down to the sanitize $op in location_cck_field(). I Think the array_merge is backwards. and it looks like the submitted values are being overwritten by the loaded variables.
from the php manual: http://php.net/manual/en/function.array-merge.php

If the input arrays have the same string keys, then the later value for that key will overwrite the previous one.

I switched the order of these and it appears to be working. I'm not too familiar with some of the inner workings of location, and am unsure if this would break something else, but it seems to be working correctly now on my install.

I hope this helps someone. Attached is a simple one line patch.

loze’s picture

Status: Active » Needs review
apoc1’s picture

I found out it was a bug that was caused by the field dependencies module. I gave my users the possibility to fill in the adress or select a venue (node) that was listed on our site.

podarok’s picture

podarok’s picture

Status: Needs review » Fixed
Issue tags: -CCK, -location, -node location, -not saving

#48 pushed to 6.x-3.x-dev

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.