location_cck back compat and views support

oh, so THAT's the trick? Nice!

OK, confirmed, that's how to get cck to keep the locations cached. Awesome!

http://drupal.org/cvs?commit=175710
http://drupal.org/cvs?commit=175714

And a followup patch: Since the location is being cached, no need to load it before theming.

http://drupal.org/cvs?commit=175718
http://drupal.org/cvs?commit=175720

Thoughts I had while coding:
I noticed location_cck_field_formatter() doesn't seem to get called.
Also, I am also loading the locations for token stuff. I wonder if it's possible to also skip loading it in this case too.

Regarding loading locations and location, that would be nice to have, node locations will have to be copied to a new field (and that considered the new "official" source internally to location) before that's feasible though, otherwise the cck locations would leak into the node locations.

tagging. nice to see this!

#drupal-geo sounds like a good place to work on a sprint to try and work "real time" on some location issues.

#452806: sprint? can bdragon make it?

The 'arguments' and 'views' sections need to be removed altogether. That is the way things worked in D5, those operations are not invoked in D6 and should be removed. I haven't done anything with the rest of the patch, just wanted to note that much.

There are a billion threads on cck location and proximity filter. would this patch help that issue also?

Tried the patch out in #12 and views still don't seem to work. Created a view with a 'Location: Nodes' relationship, and selected 'Content: Address' as the field... nothing displays.

Looking at the query, the join still says: "LEFT JOIN location_instance location_instance ON node.vid = location_instance.vid", which is what landed me at the solution here: #517914: Location CCK Address Fields don't display

Is there a thread somewhere describing why genid is used for location_cck, as referenced here? Is this due to fields in D7 not being node-specific?

Ah, so I shouldn't be using a Location:nodes relationship, but instead just a Location relationship? I'll try that out. Thanks!

Has anyone tried this patch which connects the location cck with the node. It allows me to use location without relationship for views

http://drupal.org/node/343943

The posiive is that I can have multiple node types called and their locations without relationships being used. admittedly i have not gotten proximity to work yet.

@dragonwize, I still cannot get this working. Could it be that your patch for location_cck is not up to date with this patch for location.views.inc? I see three relationship options for location. "Location: Users", "Location: Node", & "Location: Node Revisions", whereas your screenshot shows only "Location".

@dragonwize: Ok, so one clarifying question: Your view where it's working is a node based view, not a location based one, right?

Honestly, I don't see how this can be done with genid. Node based tables need to have joins based on the nid. A snippet from your patch:

<?php
      $data["location_$table_alias"]['table']['join']['node'] = array(
        'table' => 'location',
        'field' => 'lid',
        'left_table' => $table_alias,
        'left_field' => $field['field_name'] .'_lid',
      );
?>

Which if I'm understanding correctly is essentially saying join the 'location' table to the 'node' table via $table_alias on lid = $field['field_name'] .'_lid'. Which sounds good, except that location.views.inc already joins to the node table via location_instance on nid/vid.

Also, this means that you can't actually just use the views field that CCK is providing. I have a feeling a custom relationship handler is going to be needed if nid/vid cannot be used for CCK fields in location_instance. The handler would need to parse out the genid from the location_instance table and join location to node that way.

@dragonwize,

Thanks for continuing the dialog, its very helpful. I think I'm going to end up switching to location_node instead of using location_cck. I just can't get this working.

Location type views are handled by location.views.inc and were taken care of by another patch of location.views.inc... All your assumptions there are assuming that both peices are working together but they actually are playing separate parts. My patch is only on the location_cck module and use CCk's views support api.

Yeah, I understand that location.views.inc is primarily for location views. My point is, look at this code from location.views.inc:

<?php
  $data['location']['table']['join'] = array(
    // Location links to node through location_instance via lid.
    'node' => array(
      'left_table' => 'location_instance',
      'left_field' => 'lid',
      'field' => 'lid',
    ),
?>

And then compare with your code below in location_cck:

<?php
      $data["location_$table_alias"]['table']['join']['node'] = array(
        'table' => 'location',
        'field' => 'lid',
        'left_table' => $table_alias,
        'left_field' => $field['field_name'] .'_lid',
      );
?>

They are both functionally doing the same thing (joining location to the node table). The former one is joining location to node via location_instance, whereas the latter is joining to node via the cck table that contains the location_cck field. In your case it appears that for some reason views is using the location_cck join over location.views.inc's join. In my case, the opposite appears to be true. Either that or my other guess is that it won't use the cck table to join because the cck table is already joined to node for the other cck fields.

Anyways, thanks for your help, I hope you're not feeling like I don't appreciate the time you've put into this!

i've noticed a bug with your patch in 2 installs of mine, please try and see if you get the same result:
- just change default location in location - main settings to any other country of your choice (or in cck same thing)
- now go to add node ... did the default country change or is it still the same? in both my installs the default country configuration wont change anything since i applied this patch.

funny, my default country of choice is set right in edit node if i create a node with empty location, but at add/create node the default country wont change to my configuration choice.

lol, solved the problem by deleting cck location field and creating a new one. seems like you cant change default country once the cck field has been created.

Thank you for the patch #16. Works perfectly for me! Should be committed.

The patch from #16 was against HEAD version 1.16 of "location_cck.module". Meanwhile, we are at v. 1.23, and it does not seem that the view improvements from this thread have been implemented. So, do we still have to apply the patch - and will it work - or must the patch be updated?

Thank you - patch #31 works perfectly for location fields in views with Location v6.x-3.x-dev (2009-Jul-31). I am using it at https://www.iseki-food.net/drupal/upcoming_ifa_events_all.

After applying this patch I get the following error: "warning: include_once(./sites/all/modules/location/contrib/location_cck/location_cck.module) [function.include-once]: failed to open stream: Permission denied in C:\xampp\htdocs\mysite.com\includes\bootstrap.inc on line 611."

I'm not sure if this is because of my setup with XAMPP, but the module worked fine before the patch. I've checked that the file permissions are not read-only.

Yes: I fixed this by following the instructions here: http://drupal.org/node/248176#comment-1001200. I'll let you know how the testing goes. Sorry for the unrelated issue: I just wasn't sure.

All right, hopefully this is related to this patch. I didn't get this warning until after the patch: "warning: Invalid argument supplied for foreach() in C:\xampp\htdocs\mysite.com\sites\all\modules\cck\includes\content.token.inc on line 59." This warning appears when editing my content type that includes my cck location field. It quickly disappeared after refreshing the page, but now, under "manage fields," my previously created CCk location field is reported as disabled: "This content type has inactive fields. Inactive fields are not included in lists of available fields until their modules are enabled...Location (field_location_cck_reusable2) is an inactive Location field that uses a Location Field widget." Is there no upgrade path for prior fields?

subscribe

The patch #31 doesn't seem to work with proximity search. If you input a number in the "miles" field, it will always display empty. If the "miles" field is empty with the correct zipcode, then it's able to produce the result. Any idea why it's like this?

Hmm... I've been digging around in the voluminous list of issues here and this is the closest to my problem that I've found. And since this seems to be the most active work on location_cck, it seems like the place to post. The patch in #31 works against the July 31 dev and certainly does seem to make improvements. The cck data is related properly and one can use the Location fields to display the various data. However, what doesn't seem to work is using the actual cck field itself. It appears in the Fields>Content list as an available cck data field, but when you add it to the display, it returns empty. The format pop-up is presented and provides the same options as the cck Display Fields setting (Address, Address with Map, Map only, Multiple field values on a single map) but none of those choice seem to matter.
I, in particular, would like to display the Address with map option in my view.
Anyone have any ideas?

And while I'm at it, the token support seems to have an issue with modules like auto_nodetitle and pathauto. The token isn't passed on the initial node save and the auto_nodetitle gets set to the token reference (ie - [field_location_name]) instead of the value of the field. Editing and re-saving the node then results in the proper behavior and the node is named.

The first half of my last comment was not very clear. I've now found an issue that is a bit more specific and done a better job explaining the bug here: http://drupal.org/node/427432#comment-2072838

@fred0 - I believe I provided a possible solution to the first part of your issue at http://drupal.org/node/427432#comment-2251824 (#14)

The second part, regarding the token support, is actually an auto_nodetitle bug, and can be fixed by applying the patch from http://drupal.org/node/194197#comment-2202358 (#69)

I was just about to call this patch rtbc but then I rolled back to DRUPAL-6--3 to create another patch quick. I must admit that it took some serious configuring to get a node based view to work with the Location relationship and configuring every location_cck field for testing. You can imagine my shock when after removing the patch only to find that the view is still working. Filters, exposed filters, arguments, sort criteria, all the styles, grouping by location field the whole shebang, everything I've just tested works the same with the patch as without.

The idea for this issue, correct me if I'm wrong, is to create backward compatibility with location_node. Which it is failing to do completely, by using a relationship to expose the cck location data to views, rendering the view incompatible with node location data. What is the point then, we will be better of going the location_instance route which can indeed have these two misfits behave each other in one view. See #391160: CCK/Views: location_instance fix Did I mention easy as pie to configure?

For the second part of the patch, I fail to see what the benefit is to populating $node->location and $node-locations. If these do somehow make our lives easier and the code base simpler and more stable or even just one of the above then I will agree, lets go ahead and commit, until then I'm marking this issue "needs work".

Instead of making things more complicated, lets work together to fix all these outstanding bugs, get the issue queue cleaned out, write some documentation, get more maintainers involved and lets turn this very special project into something extraordinary.

Back to the topic: How can we get these two very similar modules to stop stepping on each others toes and work together? Do we even need to concern ourselves with compatibility? Why are we keeping both? What are the pros and cons? Lets talk about it again and again until we find a practical solution...

KISS

subscribe

@nickl: confirmed - the patch is no longer required for Location 6.x-3.x-dev (2009-Dec-17) used with Views 6.x-2.8 :-)

subscribing