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.In geofield_handler_filter.inc, the user has the option to choose from a few different types of data input. This option changes how our input widget takes in data. For example, by selecting manual entry of points, we expose our custom geofield lat/lon element, while a geocoded option will expose a textfield. Currently, when this is switched, the admin will not swap the input widget. If the user saves the filter and reopens it, the widget renders correctly, but might have some issues depending on the value set from the previous filter.
This should be solvable via Form API's AJAX callbacks (http://api.drupal.org/api/drupal/includes%21ajax.inc/group/ajax/7), but I've noticed while working on geofield's handlers that Views/CTools has it's own way of handling AJAX which may provide a better way to handle this.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | geofield-views_filter_widget_does_not_respond_to_source-1594640-9-7.x.patch | 6.83 KB | GuyPaddock |
| views-proximity-ajax.jpg | 70.12 KB | Brandonian | |
Comments
Comment #1
Brandonian CreditAttribution: Brandonian commentedSo, Views exposed filters (and by extension, this admin form) don't play well with #ajax, my preferred solution to this problem because Views strips the form id and hash out of the form. Drupal core ajax system doesn't like that... There's a potential solution at #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback, but I'm not sure I fully grok what they're suggesting, and it seems like it's potentially fragile.
Second option that I explored was attempting to prerender the form elements and place them into Drupal.settings, but I've had trouble rendering a single FormAPI element. *brainstorm* - I might be able to create a form callback, pull the rendered data, and parse out the necessary data with jQuery!
Comment #2
Brandonian CreditAttribution: Brandonian commentedhttp://drupalcode.org/project/geofield.git/commit/66677a5
So, last comment was way off base. It would have worked, if Drupal didn't do any validation on form items... Finally dawned on me that we're basically wanting to do the same thing that the 'expose filter' checkbox does within Views UI does, which is change a form after a single form element performs a modification. The above commit works locally for me, but could use some testing.
Potential pain points are likely to be in data validation within the UI. For example, if you switch from a lat/lon widget to a geocoded widget, the proximity element is likely to get values from the previous widget.
Comment #3
jpstrikesback CreditAttribution: jpstrikesback commentedJust a quick note that the operator selection doesn't change the distance2 hidden state
Comment #4
Brandonian CreditAttribution: Brandonian commentedRefactored views integration should have fixed this.
Comment #6
IWasBornToWin CreditAttribution: IWasBornToWin commentedIs this issue the same as this one? http://drupal.org/node/1887122 If so, I do not see it fixed.
Comment #8
GuyPaddock CreditAttribution: GuyPaddock commentedThis is still an issue in 7.x. I see no patches in the thread, so I'm setting this to Active.
Comment #9
GuyPaddock CreditAttribution: GuyPaddock commentedAttached is my attempt at a patch for this one. It seems to correct it for both the views admin area as well as for the exposed filter.
Comment #10
ptmkenny CreditAttribution: ptmkenny commentedComment #11
Rhodungeon CreditAttribution: Rhodungeon commentedThat fixed my problem! Will it be committed?