Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
I'm building a hobby project, and I've installed this module. Works well, but it still doesn't meet my requirements. I'd need 2 contextual filters:
1. the logged-in user geolocation
2. the distance and unit (km/miles).
I think this make a good use case, as it would allow users to browse/discover content close to them. I'm just sharing my need, I may work on it in the next few days and provide a patch. Thanks for any suggestion in advance.
Comment | File | Size | Author |
---|---|---|---|
#11 | geolocation_proximity_1171232-11_contextual_filter.patch | 4.87 KB | JKingsnorth |
#5 | geolocation_proximity_1171232_5_contextual_filter.patch | 22.18 KB | johnv |
Comments
Comment #1
kay.beissert CreditAttribution: kay.beissert commentedIf the logged-in user can input an address to define his geolocation (like in google maps), this is what I need. I stay tuned.
Comment #2
mariano.barcia CreditAttribution: mariano.barcia commented@bertoluci, thanks for the input.
I realized that I also need a field "distance" to display along each result, and also to be able to sort the results by "closest results first".
So, my priorities would be:
1. Support geolocation field stored in the logged-in user info
2. Provide a "distance" filter (exposable)
10. Provide a "distance" field for displaying and sorting
11. Support changing the origin geolocation, which should mimick the geolocation methods (gmaps, html5).
10. This can be partially achieved by displaying the distance once the user clicks on one of the rows.
11. I think now this use case is a nice-to-have, because a more common use case would use the geolocation pair already there in the user info, who should inform their geolocation once ie. in the registration/settings form. In the view, users may play with the distance filter. That's the way Badoo does it for instance.
I took a glimpse of the code, and it's difficult to understand. Probably because Views itself has become very difficult to understand :-/ For the time being, I need to postpone working on this until I can make some good progress in other areas of my project.
Comment #3
Open Social CreditAttribution: Open Social commentedMake sure to adjust the fields, module name and view name to your use case
Also I get the lat and long via $_GET, that is only avaiable when you have an exposed filter with no ajax enabled.
Comment #4
derjochenmeyer CreditAttribution: derjochenmeyer commentedComment #5
johnvPlease find attached a patch that contains a contextual filter, using the page argument as a filter.
Currently it mimics the proximity argument handler from the location module.
You can specify location + distance like this:
Options 2 and 3 need the Geocoder module to be installed, and use the Google Geocoding API.
It supports the following storage modules:
The patch might need some love, though:
- I have included earth.inc from the location module, because i did not understand the SQL-distance part from the other handlers. That might be removed by refactoring the sql-distance part (see code), or we might use it more.
- support more Geocoder features, by reusing/ the Geocoder from/to settings.
Attached patch can also be the basis for:
Comment #6
pinkonomy CreditAttribution: pinkonomy commentedIs this possible with this module/patch to search for nodes inside an area?E.g. a user to enter an area and as a result will return all nodes inside that area.Is this possible?
thanks
Comment #7
pinkonomy CreditAttribution: pinkonomy commentedIs this possible with this module/patch to search for nodes inside an area?E.g. a user to enter an area and as a result will return all nodes inside that area.Is this possible?
thanks
Comment #8
johnv@pinkonomy, this patch searches for nodes within the raius of the page argument. IIRC, the module already provides a search box in an exposed filter.
Comment #9
scalp CreditAttribution: scalp commentedI applied the patch at #5. The result I get is that the contextual argument options show up in the Views UI. I can set them, but when I do a preview using a lat,long argument it's not getting added to the query. Same results on a page view. Nothing regarding the argument is getting passed into the query. Any thoughts?
Comment #10
JKingsnorth CreditAttribution: JKingsnorth commentedI'm not sure if the patch in #5 is the right approach for the module. Geolocation field is supposed to be designed to be lightweight, and not rely on the many other solutions out there. I notice that there is also a lot of superfluous code in the patch, brought across from the filter handler.
I think in the first instance, to satisfy most use cases, we should look at creating a new argument that searches using the lat/long field of the currently viewed user or node (or argument), with a configurable distance.
I'm working on this at the moment, but I don't want to dissuade others by assigning the issue to myself :P
We can then look at the other bells and whistles in future iterations.
Comment #11
JKingsnorth CreditAttribution: JKingsnorth commentedHehe, this is proving very complicated. I thought I'd post how far I got, which 'works' for nodes, if used by itself. But tying in sort order and a field to display the distance relative to the contextual filter starting to get a bit barmy. Hopefully this might at least provide a starting point for somebody else?
Comment #12
doitDave CreditAttribution: doitDave commentedHi all,
I was also desperate for a working argument (Contextual filter) solution. As it turned out, this actually *is* a really nasty job, thanks to Views' complexity (which is basically good) and its horrible documentation (which actually is horrible). However, in the end I managed to rework the module to the following:
* Contextual filter, taking:
** Raw argument (lat,lng)
** Node + Field name (to extract these values from; extending the node_nid default argument plugin)
** Validating any provided argument with a dedicated argument validation handler (which does the same as the validation stubs already existing in the module)
* Filter:
** Aside of manually setting coordinates (existing behavior), any existing contextual filter can now be selected to filter on.
* Field:
** Streamlined (no longer with a "enter location" or "exposed" option, which IMO is now purely obsolete, because...)
** ...select any existing (contextual) filter as the distance location source for the field output, which makes it quite flexible (you can always provide a static default argument in filters or arguments).
** Also streamlined and removed the "extra options", which caused some flaws in the existing code right away (I did not check all existing issues).
* Sort handler
** Also allows to sort on every configured source (filter, argument), so you could even create multiple distance fields, filter on the first and order by the second, quite flexibly.
I do not want to hijack the issue nor the module, so I spare you a long patch for now. But if there's any interest, I'll gladly post it here or elsewhere.
Anyone interested?
Comment #13
attishu CreditAttribution: attishu commentedHi doitDave,
Yes I'm interested, also anyone who started working with Google Maps using this method. After a point we need a proximity - distance filter to show content properly.
I hope we can update the dev version with your patch.
Comment #14
ciss CreditAttribution: ciss at yousign GmbH commented@doitDave If you can spare the time please set up a sandbox (or other repo) with your modified code. Besides I don't think your patch would qualify as hijacking even if it theoretically contains out-of-scope changes for this issue.
Comment #15
ciss CreditAttribution: ciss at yousign GmbH commentedSetting status back to Needs Work as per #11.
Comment #16
peterbrot CreditAttribution: peterbrot commented@doitDave I'm interested to. Your solution could be very useful to me.