This page tries to answer questions frequently asked by new users, either in the issue queue or elsewhere.
- Why aren't my facets showing?
- Why don't data alterations reduce the number of items to index?
- Why can't I index field X? / Why can't I create a search index for entity type Y?
- Why don't Search API searches find partial matches/substrings?
Why aren't my facets showing?
First off, there are a number of reasons that apply for all facets. Check whether you've properly enabled the facet blocks to be shown somewhere (either in Admin > Structure > Blocks or using something like Panels), and that the facets are configured to be displayed for the search in question (using "Display for searches"/"Search IDs" in the facet display settings). Other settings (like "Minimum facet count" or a faulty field or workflow configuration in the index) might also lead to empty facets, depending on the site in question.
However, when your search isn't the main content on the page, or when you're using something like Panels to arrange the content on the page, there might be another, harder-to-solve problem, which has its source in the way the Search API Facets module works: the module provides blocks for all enabled facets (which can, of course, also be used by Panels or the like). When a block is requested, the module checks whether a (matching) Search API search was executed on this page request and, if so, provides facets for it. Otherwise, it returns an empty block, which won't be displayed.
However, when the search isn't the main page content, or the facets aren't in normal blocks, it can happen that the facet blocks will be requested before the search takes place. Then, they have no way of telling that a search will later be executed in the same page request, and act as if they weren't on a search page – i.e, the blocks aren't showing.
Regrettably, this problem cannot be fixed in the Search API. You have to make sure yourself, in some way, that the search on your page will be executed before the facet blocks are requested.
For further information and possible solutions, see #1066278-28: Problems with Context/Panels and facets and the rest of that issue.
Why don't data alterations reduce the number of items to index?
E.g., you have an index configured with the "Bundle filter" data alteration to only index nodes of type "Article". Still, on the index's status page the "Progress" note mentions the total number of nodes (of all content types) as the total number of items to index, and maybe even as the number of items already indexed. (This is also the same for all other data alterations that filter the items to be indexed, like "Exclude unpublished nodes" and "Language control".) Therefore, you might wonder whether the data alteration is working properly, or not filtering the indexed items at all.
However, this is not a bug, the data alteration is (most likely) working correctly! It is just a regrettable, but hard to remove restriction in the design of the Search API that data alterations won't change the listed total number of items, and that items filtered out from indexing will still count to the number of items indexed. If you want to know the number of items that are really indexed, and whether the data alteration is working correctly, you will have to create a search showing all items and look at the result count (or at the specific property which you are filtering).
Why can't I index field X? / Why can't I create a search index for entity type Y?
For achieving its aim of being as generic a search framework as possible and supporting as many types of data as possible, Search API relies on the Entity API for providing the metadata of search items, most importantly the fields/properties attached to them. However, this is no magic process, Entity API, too, can only know of fields and entity types if other modules expose this information to it. If you are a developer, see the Entity API documentation for how this is achieved.
Basically, the Entity API lets modules retrieve information of the properties of entity types it knows about. If a module defines a new entity type, but doesn't tell the Entity API about the properties entities of this type have, the Entity API – and, consequently, the Search API – knows nothing about the properties of this entity type. And therefore it will not be possible to index entities of this type with the Search API (without special integration).
Properties of entities aren't just defined by the module that creates them, though – the Field API also allows site builders to add custom fields to entities. The fields attached to an entity can easily be retrieved – however, the type of data stored in the field (whether an integer, a list of dates, a more complex structure or …) cannot be inferred so easily, here the Entity API (and, thus, the Search API) again has to rely on a module (in this case the one defining the field type in question) to specify what type of data these fields contain.
Since the Search API cannot index data of which it doesn't know the type (most importantly, because the data structures needed for single and for multiple values are inherently different), fields which don't specify that information will not appear in the index's Fields form.
So, in both cases, if you encounter a missing entity type / field, create an issue in the issue queue of the module responsible for that entity type / field. If the module maintainers don't know how to integrate with the Entity API, refer them to the corresponding handbook entry.
Why don't Search API searches find partial matches/substrings?
E.g., when searching for "break", why aren't items containing "breakpoint" (or "unbreakable") found.
This is not actually a problem of the Search API module itself. The Search API only supplies the framework, and passes the search string on to the service class (database, Solr, Xapian, etc.) for the actual searching. The service classes therefore determine whether partial matches will be returned or not. You should therefore refer to the service class' documentation or ask in their issue queue (if they aren't listed below).
For the Database search, this isn't yet implemented. See #1299238: Add option for partial matching for current work on this. As a substitute, there is the Fuzzy search service class which also uses the database but does support substring matches.
Solr search, see here.