Contrib Config Actions List¶
The following config actions are available from contributed modules.
Search API¶
search_api.index.*
- setOption(s)
- removeDatasource
- removeProcessor
- renameField
- removeField
search_api.server.*
- setBackendConfig
setOption(s)
¶
Set index option(s) are for setting general options of index, such as immediate index, number of items to index on cron run, track changes in references, etc. There could be more options in the future, it all depends on the server backend that is used for search index.
Singular:
Plural (it is not the plural of action method setOption
, but a separate method
in Index class that is exposed on its own, that is why the syntax is different
as for other plurals):
config:
action:
search_api.index.example:
setOptions:
cron_limit: 50
index_directly: true
track_changes_in_references: true
removeDatasource
¶
For easier understanding datasource could be an entity type in Drupal (it can be
anything else, but in Drupal terms is common that each entity type is a separate
Datasource). The index can contain multiple datasources, for example the site
wide search can have Content (node) datasource and for example User datasource,
so that it is possible to search for content and users. The removeDatasource
from index config action accepts 1 argument, the id of the datasource. For
example if there are 2 datasource enabled Content ('entity:node') and User
('entity:user') and the task is to remove User datasource, the following config
action should be implemented:
removeProcessor
¶
Search API has a lot of processors (that are plugins) for different stages of search operation (indexing, quering, showing results, etc.). Each processor is a plugin with its own id. This config action allows to remove processor. The only argument is the processor plugin id. For example, if index has "Entity status" processor enabled, that disallows indexing unpublished entities, but you want to allow this:
renameField
¶
By default when the field is added to index, the machine name of field storage or base field definition is used, but it might be useful to have another name for clarity, or in case of multiple datasources the field names can be the same and Search API will add unique numeric suffix to one of the field names.
config:
action:
search_api.index.example:
renameField:
old_field_id: name_1
new_field_id: my_unique_pretty_name
removeField
¶
If the field is not needed anymore, it can be removed from index. The
removeField
config action accepts 1 argument the field id in index:
setBackendConfig
¶
The setBackendConfig
config action depends on the Search API Server backend
that is used, backend can be Database, Solr, Elastic, vector database, etc. All
backends have there own settings.
config:
action:
search_api.server.database:
setBackendConfig:
database: 'default:default'
min_chars: 3
matching: partial
phrase: bigram
Also of note for Search API Views¶
To set the view mode globally for field "Rendered Item", as it is not possible to know what content types are there in the system during the recipe installation. But the change from the issue allowed to use this snippet in the configuration of the Search Index:
field_settings:
rendered_item:
label: 'Rendered HTML output'
property_path: rendered_item
type: text
configuration:
roles:
- anonymous
view_mode:
'entity:node':
':default': search_index
With setting ':default': search_index
all existing and new content types that
will be added in the future will use the search_index view display, instead of
being excluded.