Search API LocalSolr

This sandbox was merged back into the Search API Location project and is thus outdated now.

This is a fork of the Search API Location module. Comparison:

Major changes:

• Removed all javascript functionality.
• Geocoding now happens via Geocoder module, and is done on the backend when the search form is submitted.

Bug fixes:

• #1760828: Missing dependency on search_api_views?
• #1777048: Missing configuration fields
• #1430874: Undefined variable: kort in search_api_location_search_api_solr_search_results_alter()

Feature requests fulfilled:

• #1651094: How to add "Get location" action inside Submit action
• #1403452: Remove Gmaps and just use input fields.
• #1312040: Option to choose field for centred location
• #1591584: Default lat/long as logged in user?

I can add the google map back in, but I would so primarily for the sake of plotting results and geocoding dropped pins, but NOT geocoding address strings.

Follow issue here:#1798168: Major module modifications

My todo:

• Allow 'user location' to be used rather than address string
• Improve admin ui
• Improve method for passing spatial data to Search API classes, this should:
• Clean up URLs
• Ensure that local data is not lost in facets
• Integrate with Search API Sorts. Currently, this module overrides sort order by always prioritizing proximity
• Integrate with Search API Facets such that facet results are limited by spatial restrictions. Possibly add location as a facet?
• Integrate with Search API Autocomplete such that AC suggestions are limited by spatial restrictions
• Integrate with Search API Spellcheck such that AC suggestions are limited by spatial restrictions
• Optionally plot results on Gmap
• #1812528: Add proximity/distance information to search results
• Integrate with fledgling Services Search API -- integrated with fork of Services Search API
• Integrate with fledgling Geocluster project

Todo from drunken monkey in #1798168: Major module modifications

• Spatial option
  • Correct namespacing issues
    option should be properly namespaced, and therefore be called search_api_location, not just spatial
  • Allowing multiple location filters
    Make this an array of arrays.
  • Change radius parameter
    • Convert the radius to a defined uni t beforehand, not in each individual service class.
    • getting rid of the option and just defining some special handling for filters on location fields, for service classes which support the search_api_data_type_location feature
    • append the radius to the value. e.g., LAT,LON,RADIUS or the like (having operators other than = and <> would then be a bit useless, but that's a minor issue. You could define that other operators should just be ignored, or treated as <>).
  • Remove the radius units from the option
• Processor
  • Replace with implementation of hook_search_api_query_alter(). This would allow more than one location field per index.
• Check for server compatibility, and react appropriately.
  • warn the user that things will not work
  • degrade gracefully (the field will be indexed as a normal string and the query option, when present, ignored)
  • conditionally remove location configuration options (different Views handler, additional configuration for Pages)
• Write necessary documentation.
• Clean up coding standards violations, e.g., whitespace.