1. Create a content type/entity type and add a location field to it (or to an existing node/entity)
2. Create a Node/Entity from new/updated type, filling in a valid address in the location field
3. Create a View aggregating your new/updated content/entity type
4. Choose Gmap as the Plugin
5. Choose the Location Field as one of the Views Fields
6. In the Gmap Plugin settings, Select 'Choose lat/lon fields' and then select your Location field as your lat and lon fields.
7. Opt to use the Location field as your marker
8. Present your Location Field as the Bubble text
9. View your View
10. Cry out in utter frustration at the inability to make it work.
I found it extremely frustrating that I couldn't tell the GMap plugin in views that my lat/lon info or my bubble/marker info came from the Location field. Isn't D7 all about fields? Personally, I love fields! Which is why I had to remedy this.
Here's the patch to fix this. I tried to retain as much of the current functionality as possible as a safe fallback. And I only wrote code that affected the 'fields' area when rendering the Gmap. Now it will look for lat/long, marker info and the rendered out put of the location field (for the bubble) when the info is applicable.
I did change how the field information was processed. I didn't think it was safe to use $row->{$field_alias} in instances when you need field data. There's a field handler object with a field_info property that is better at handling field information than an alias in a db field (remember, whether it's aliased or not, it's selected in the query). $field_handler_obj->field_info['field_name'] is more safe. Then you just use $row->{'field_'.$field_handler_obj->field_info['field_name']} instead.
Anyway, I haven't done too much testing with this. The patch attached worked for me and I hope it helps others as well. Please, someone, test test test. Can't wait for v3 to get in production. Anyone thinking about a way to tap into the DrivingDirections functionality?? I guess I could figure out a way using jQuery and the mapid.
Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | gmap-recognize_ocation_CCK_field-1955750-15.patch | 1.75 KB | jerenus |
| #12 | gmap-location_field_cck-12.patch | 1.36 KB | curiosity26 |
| #8 | gmap-location_field_cck-8.patch | 1.87 KB | curiosity26 |
| #1 | gmap-location_field_cck-0.patch | 10.01 KB | curiosity26 |
Comments
Comment #1
curiosity26 commentedBlah! Didn't attach the patch.
Comment #3
johnvv2.5 is an erroneous, outdated, version. Can you provide a patch against 7.x-2.x version?
It is hard to see which code is changed/reverted deliberately.
see #1955230: Tag for 7.x-2.5 is NOT correct. It publishes an OLD version!
Comment #4
podarokbumping version
Comment #5
podarok#1: gmap-location_field_cck-0.patch queued for re-testing.
Comment #7
podarok#1 needs reroll
+
lot of whitespace errors
http://drupal.org/coding-standards#indenting
Comment #8
curiosity26 commentedOk I noticed many updates in v2.7, but still leaving out the catch for the actual Location CCK Field. I don't see the dev branch in git, so I just will have to work with the latest release. Here's the newest patch. Can't seem to do an easy way with gmap extended. But! You can at least pull out the lat and long values individually in views if you had to use gmap extended.
Comment #9
curiosity26 commentedSCORE!!
Comment #10
johnvI'm glad you did the trick, curiosity26.
Some remarks:
if (is_array($custom_field_lat) && !empty($custom_field_lat['latitude'])) {- Isn't this always (TRUE && TRUE) for Field API fields? At least, if $custom_field_lat['latitude'] exists? This might be enough:
if (isset($custom_field_lat['latitude'])) {- A bit of documentation wouldn't hurt, for later reference.
- you still have problems with indentation, trailing spaces and tab's. Try the Coder module. After installation, you can activate it from admin/modules page.
- IMO below (untested) version would do the trick, too.
Comment #11
curiosity26 commentedI'm sorry. I know I have issues. I switch between Komodo Edit and vim (depending on where I'm working at the time). I agree that is_array might not bet the best solution. Perhaps just using the !empty($custom_field_lat['longitude']) is enough. I can add some additional documentation.
All in all I'm just getting used to this community thang. I've been a developer for about 10 years and Drupal is the first communal thing I've worked on. So I appreciate the helpful references.
Please let me know if you would like me to clean up and resubmit.
Thanks!
Comment #12
curiosity26 commentedOk I did some major cleanup. I realized a lot of the code I had was because of my attempt to port back in v 2.5. Many of the prerequisite fixes are in place in v 2.7 so not all of that code was necessary. I included comments and matched the indentation as defined by the document standard. I hope this is a more clean and refined patch than the previous.
Thanks!
Comment #13
podarok2 @curiosity26
If You uploading a patch , please tag it with needs review status https://drupal.org/node/156119 and latest dev version for testbot
Comment #14
podarokwhitespace errors
http://drupal.org/coding-standards#indenting
Comment #15
jerenus commentedRerolled it.
Comment #16
podarok#15 commited pushed to 7.x-2.x
this one needs rework to extended views plugin style so moving to critical!
nice work
thanks!
Comment #17
pearl.liang commentedJust want to share my experience. I had the same problem with 7.x-2.x updated in Oct 2013.
Later my problem is solved by unchecking "Use a Google Map to set latitude and longitude" under "admin/config/content/location". It automatic enable geocoding.