Patch to views-enable location fields

It worked fine for me when I posted it but does not now. Maybe something in views changed between the version I was using when I created the view and the latest version (I just did a cvs update). I will get it working again and let you know.

I have a couple ideas about what is happening. I removed the taxonomy field from the view because depending on how it is set it could be keeping any results from showing up. Try the attached patch. If it does not work either, go to the view settings page and check whether the selected nodes match your location-enabled nodes. That is another place where it may be getting goofed up.

If that does not work, it may be the fact that I am trying to filter out only records that have location info by looking only for those with country data, and I may need to change that filter.

I added the cache-clearing function and also fixed the handlers to fix an escaping problem in the LIKE clause of the query. There are two remaining potential issues to be aware of:

1) Even though I added the function to clear the cache, it looks like it might be a good idea to manually clear your cache before trying to use this. Also delete any location view you may have previously created so you can start fresh (and clear the cache after doing that).

2) I occasionally saw a mismatch sql error related to the fact that my location table had a latin collation and the node module has a utf-8 collation. The location table needed to be updated to utf-8 for 4.7 anyway, so I did that and it fixed it. I don't know if anyone else will see this problem or not. I didn't see any such error any of the earlier times I was using this, so I don't really know what combination of things triggered it.

Once you have done that, you should be able to go to admin/views, select the 'add' option for the default location table, make any changes you want, save it, then go to location/views to see it.

Woops -- forgot to attach the patch.

I've made a few adjustments to what I previously submitted.

1) I've broken this out into a separate .inc file since it is large and not everyone is going to use it. I had to put a couple hooks into the location.module so the views module can get what it needs and to include this new file when necessary.

2) The collation mismatch is a real issue. If the location table fields are still set up with a latin collation (the default in the past) and have not been converted to utf-8 (the standard for Drupal 4.7), you will get a message like: 'Illegal mix of collations (latin1_general_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like' query: ...' when you try to run a query. There are two solutions. One would be to alter the views code to do some casting in the view, which would be very time-consuming and bulky. The other is just to warn people that they need to convert the table. Since the table conversion needs to be done anyway, I chose the second option, but added a warning in the default views description to alert people to do that.

The really elegant thing would be if the conversion would happen automatically, which is supposed to happen with the .install file update function, but it looks like the .install update operation is not always working as it should yet, so some people may need to do it manually. I tried lots of ways to force it to update my table with the .install file, but just couldn't get it to work. I have seen the same thing in other modules, so I think it is something in the install code rather than in this module that is creating the problem. I ended up altering the table manually, but if anyone has an idea how to do just make this change in the background somehow instead of telling the user about it, I would gladly alter this patch to do that.

Anyway I am attaching the new, much smaller, patch for location.module, and in my next post will attach the location_views.inc file that goes with it.

And here is the new location_views.inc file.

I've got all of this done except for the dependency code. Couldn't figure out what that was or where to get it, but I'll keep looking...

The problem with the location table update not working stemmed from some combination of the modules I have installed (and I know from various threads that others have had problems like this, so it isn't just me.) When I disabled all my contributed modules and then added them back one at a time, the location table update worked fine. So it is neither a location problem nor an install problem, but a problem caused by one or more of the contributed modules I had installed. That being said, I decided I'd better leave in some kind of check for the current version and bail out of the locations_views module if it isn't there (and give the user a message that the update.php program needs to be run).

So here is the patch for the location module -- just a couple small adjustments that are needed to clear the views cache if the default countries or location-enabled nodes are changed. I wrapped it in a 'if function_exists' clause so it won't do anything if the location_views module is not enabled.

I'll post the new location_views module as a separate item shortly.

I think this will do everything it needs to do. It checks that both the views and location modules are enabled and also checks whether the location table has been updated. If any of those conditions is missing, none of the location_views info will be displayed. I added a message that will appear only on the admin/views page if the location table needs an update, explaining what needs to be done to update the table.

OK, I figured out how the dependency-checking needed to work and added it in. It's pretty slick, if you later disable a required module it will also disable location_views, so it keeps things nice and clean. I also made the country field required rather than optional. This will only show records that actually have location information (otherwise you see any nodes in your selected types, whether or not they have location info). It is user-configurable, so you can override that setting, but that is probably the best setting for most people.

Anyway, the changed module is attached.

Oops, wrong file. I also fixed the sql queries to use %s which was only partially fixed in the previous file.