The Addressfield module stores country and state information in the database as abbreviations such as NY for New York and US for United States. Unfortunately, this is how the Search API indexes the information meaning that the an aggregated fulltext search filter will not return results for 'United States' and 'New York' but only for US and NY. The Search API faceted search blocks for the Addressfield's country field does show the full name of the country but only the abbreviated letters for the state.
The Search API does have an API hook to alter the values of the items being indexed, function hook_search_api_index_items_alter(array &$items, SearchApiIndex $index)
, however, I can not find a way to change the values of the country and state abbreviations to the full name using any Addressfield module's functions.
Comment | File | Size | Author |
---|---|---|---|
#34 | interdiff.txt | 3.34 KB | rcodina |
#34 | integrate_addressfield-1269608-34.patch | 5.41 KB | rcodina |
#25 | 1269608-25_search_api_integration.patch | 4.04 KB | temkin |
#22 | 1269608-22_addressfield_preprocessor.patch | 4.3 KB | temkin |
Comments
Comment #1
drunken monkeyIndeed, you can alter the values with a hook, or by writing a data alteration (or preprocessor) to do it. With a processor, you could also alter the data at search time, if you want.
For having the correct names in the facets, the Adressfield module is responsible to specify its field information correctly. It seems to only do that for the country, not the state.
And with the Adressfield functions you need, I can of course not help you. If you really don't find anything, ask in the issue queue for that module.
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis one belongs to me.
Comment #3
rooby CreditAttribution: rooby commentedRelated to this (I can open a new issue if you prefer):
When I include the addressfield 'Administrative area (i.e. State / Province)' as a field in my index I get the following error when doing a search on that content:
Comment #4
rooby CreditAttribution: rooby commentedActually, the problem mentioned in #3 occurs for all parts of the addressfield, not just Administrative area.
Comment #5
drewish CreditAttribution: drewish commentedOne other thing that'd be great is if we could get the name line indexed. Right now I'm combining them in a view field but the downside is it's un-sortable.
Comment #6
cthiebault CreditAttribution: cthiebault commentedAny news on this issue?
Comment #7
Robin Millette CreditAttribution: Robin Millette commentedSee also #1431592-4: Integrate with ApacheSolr/FacetAPI module as a facet
Comment #8
amarcus CreditAttribution: amarcus commentedAs an simple alternative, try out the addressfield_tokens module. Enabled the "Search index" display mode for your content type, and use the "Address components" field formatter to include the address components you care about for keyword searches.
Comment #9
rooby CreditAttribution: rooby commentedThanks for the module, it looks useful.
I'm guessing it isn't a full replacement for search api integration in addressfield though in that doesn't cover having search facets for different parts of the address? Like a post code facet or state/province facet.
Comment #10
amarcus CreditAttribution: amarcus commentedThat's true, addressfield_tokens does not provide any facet support for addresses. But the location_taxonomize module, referenced above (#7), looks pretty useful for that. I haven't tried it (we ended up writing our own module to do the same thing), but the idea is: turn addresses into a hierarchical taxonomy that can then be used as a search facet. This is much easier than creating a custom facet from scratch for address fields.
Comment #11
adam_b CreditAttribution: adam_b commentedI've used location_taxonomize with facets - there are some bits that don't seem to be working perfectly (though I don't have much experience with facets, so don't know where the fault lies) but it does give me a list of cities for 1200+ records so far.
Comment #12
rooby CreditAttribution: rooby commentedTo be honest I think this module should be providing its own usable search api integration.
A number of my sites tend to have a large amount of modules to begin with and I'm not into adding more (including more complexity and unwanted taxonomy in this case) just to work around bugs.
I will check out location taxonomise though at some stage. A lot of people have been asking for such a module for a very long time.
I really hope I can get some time to investigate a fix to this bug sometime.
Comment #13
javdich CreditAttribution: javdich commentedAny progress on this yet, or is the location_taxonomize module the only workaround at this point? It would be nice to have the option on how to store the state / province names
Comment #14
mrweiner CreditAttribution: mrweiner commented@jman05: I haven't found another way around this as of yet, and as such, so far, location_taxonomize seems like the way to go as far indexing goes. The problem still stands though that because data from address_filed is stored with the abbreviation, location_taxonomize grabs the state information in an abbreviated from as well. Unless I'm missing something, I can't get taxonomize to list the state in its full form.
Any ideas? I'm sure there are people who have gotten this working by now. The thread is 10 months old.
Comment #15
mrweiner CreditAttribution: mrweiner commentedSo, this doesn't fix anything on Address Field's end, but I came up with a workaround. Set up a view for your index, and add an exposed filter of type "Search: Fulltext Search". Under searched fields, select Aggregate Address (which will need to be enabled within your index). Then, add the below code into a custom module. It uses hook_form_alter to convert any instance of a full state name into its abbreviation before the search is sent. So, if a user searches for "California", the query is instead treated as "CA", which is how the data is indexed. I know it's another module to install, but is a much more lightweight alternative to using location_taxonomy.
Comment #16
javdich CreditAttribution: javdich commented@ mrweiner Thanks for the post! that seems like a logical lightweight alternative. Although I'm using search pages, not views for my output, so I may have to re-evaluate views vs search pages...
Comment #17
mrweiner CreditAttribution: mrweiner commentedI'm not familiar with using search pages instead of views, but if your search form has a form id, which I would assume it does, you can apply this to that as well.
Comment #18
javdich CreditAttribution: javdich commentedYes I believe in my case the form id for my search page = search_api_page_search_form
Comment #19
rszrama CreditAttribution: rszrama commentedJust updating this to point to #1829900: [meta] Address Field 2.x needs pluggable administrative areas and an actual API; this is a solid feature request, but as of right now we have no API to get at those full text administrative area names or any way to indicate that a module like Search API could make use of full text names for a given country.
Comment #20
kevinquillen CreditAttribution: kevinquillen commentedTo add to that, the values that get indexed are all lowercase. Why doesn't it get indexed the way it is in the database (PA, MD, etc)?
Comment #21
bojanz CreditAttribution: bojanz commentedWe now have an API for getting administrative area names: addressfield_get_administrative_areas().
So someone can write a patch for this issue.
Comment #22
temkin CreditAttribution: temkin as a volunteer commentedMoving this issue back to Search API module as it belongs there, since addressfield already provides necessary API for that.
Based on what I see country value is already indexed as an abbreviation and a full text ("US United States"), but administrative_area (states) are still indexed as abbreviation only. I've created a new preprocessor that appends full text value of administrative_area to its abbreviation in order to index both values.
Patch attached.
Comment #23
drunken monkeyThanks a lot for providing a patch!
However, since the code is specific to the Addressfield module, I'd prefer it if this could be committed there. I generally don't included processors which are just specific to a single module in the Search API. I also think it's more customary to have a plugin for module A specific to module B in module B, not module A.
Regarding the processor class itself: I think this will give the processor a "Fields" select list in its config form which will then just be ignored, which would be confusing to users. Instead, you should change the code to have only the applicable fields in that select list, and then override
processField()
instead ofpreprocessIndexItems()
, which will automatically only run on the fields selected by the user.Comment #24
temkin CreditAttribution: temkin as a volunteer commentedThanks drunken monkey,
I'm fine with moving this patch to addressfield module, if maintainers agree to that. Strictly speaking, the logic about modules A and B could be applied in both directions here, as this patch is relevant to Search API just as much as to Addressfield.
Personally, I think it should be a part of Search API with other processors as you have an infrastructure there and IMO they all should sit in one place. But as I said, I'm fine with moving it to addressfield also. Is there any other module that implements preprocess on its side?
I tried to use
processField()
before switching topreprocessIndexItems()
, but if I remember correctly there was no option for me to get country field value while preprocessing state field. It's needed for an API call. Technically, this patch only works for State field for now, as other fields are indexed fine. Therefore I'll probably hide field selection in admin UI all together as it doesn't make sense there.Thanks again for your review!
Comment #25
temkin CreditAttribution: temkin as a volunteer commentedHere is a new patch against Addressfield module vs. Search API as the previous one. I also removed field config settings as the patch only processes state field, therefore it doesn't make sense to give user any options to choose.
Comment #26
RAFA3L CreditAttribution: RAFA3L commentedThanks temkin,
Just what I was looking for today! the only thing is that I think the abbreviation in the facets is not necessary, but is easy to change. Thanks again.
Comment #27
rcodina CreditAttribution: rcodina commentedPatch on #25 doesn't work for me on addressfield 7.x-1.2+8-dev and search api 7.x-1.19.
Comment #28
rcodina CreditAttribution: rcodina commentedSorry, patch on #25 does work but there is a case it doesn't: when the address field is not directly on the node and you have to first add the related node to index the address field. Anyone can confirm this problem?
I also think abbreviation is not necessary on facets!
Thanks for the patch!
Comment #29
rcodina CreditAttribution: rcodina commentedI've solved problems with addressfield in related entities with this patch. Please test it!
Comment #30
rcodina CreditAttribution: rcodina commentedComment #31
rcodina CreditAttribution: rcodina commentedI upload the interdiff with patch on #25.
Comment #32
rcodina CreditAttribution: rcodina commentedI update a new patch to fix administrative areas of countries which doesn't have them. In these cases I replace the empty value with the translatable string ''Whole country". I upload the interdiff with patch on #25. Please, review the patch!
Comment #33
rcodina CreditAttribution: rcodina commentedComment #34
rcodina CreditAttribution: rcodina commentedI upload a new patch where I add again the abbreviation given I found out it's necessary when you want to filter views with contextual filters. I upload the interdiff with patch on #25. I also have replaced ''Whole country" for "All" which is translated by default on Drupal core. Please, review the patch!
Comment #35
chriscalip CreditAttribution: chriscalip commentedPatch #34
Shallow Review: +1
I enabled addressfield, search_api, search_api_algolia
I can see "field_cap_adress:administrative_area": "IL Illinois" on search index.
Works as advertised.
Anyone interested in similar patch drupal 8 address module needs help on RTBC.
https://www.drupal.org/node/2812659
Comment #36
kumkum29 CreditAttribution: kumkum29 commentedHello,
i have a similar problem on my site with search Api and adressField (from a related entity) (see https://www.drupal.org/node/2870433). The datas for the postal codes seems not to be saved when I reindexes the nodes.
Is this patch solves this problem?
Thanks.
Comment #37
mlncn CreditAttribution: mlncn at Agaric for Drutopia commentedThe original issue mentioned making this work for Facets. Has that goal been dropped from this issue?
With and without this patch, configuring a facet for "Administrative area" (state or province) to use "List item label" has no effect, and "Transform entity id into label" (which is the one i'd expect to work) causes a fatal error when viewing a page where facets should appear.
If that's not to be fixed in this issue, we should open another issue for it, as Facets thinks that should be fixed in Address: #2732379: ListItemProcessor doesn't work with some field properties
Comment #38
hargobindFrom #22, @temkin writes:
I may be missing something obvious, but I'm not seeing where country names are expanded to their full text name.
So I wrote a SearchAPI processor to handle the conversion of 2-letter country codes into full text country names. Check out my sandbox Search API Addressfield Country Name. Feel free to add this processor to the ongoing patch here. FYI, I took the "field" approach with my processor, but that can be easily converted into the approach from the previous patches.
Comment #39
ugintl CreditAttribution: ugintl commentedDoes your module provides the same functionality as the patch? Does it completely integrates searchapi with addressfield? I mean in addition to country, also indexes states and cities.
Have you used location taxonomize with addressfield?
Comment #40
ilericiler CreditAttribution: ilericiler commentedAddressfield_autocomplete / location_taxonomize problem. Could not get help from related module issue pages.
When addressfield_autocomplete module is active, location_taxonomize/location_taxonomize_af module can not parse location as taxonomy terms.
The alternative "addressfield_geocomplete" works normally but, it doesnt support map pinning.
The server is ready to debug and all necessary files are editable. I will be sending the password (Same for Drupal User & Folder Access) if you can help me. Thank you.
http://www.ilankar.com/_help.htm
Comment #41
jeffwpetersen CreditAttribution: jeffwpetersen commentedAdditionally the locality(city) facet is returning "New " and "York" and not "New York."
Comment #42
cmseasy CreditAttribution: cmseasy commentedPatch works ok
@jeffwpetersen: maybe you used full text and not strings in the search api field setting?