- Issue created by @thejimbirch
- π©πͺGermany a.dmitriiev
Issue β¨ Need a way to populate some config values with list of available entity bundles with config actions Active doesn't really contain any config actions, it was needed for Search Track in Drupal CMS 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 as it was before (excluded because with no setting set explicitly, rendered item plugin was not producing any output). This feature is very useful for Drupal CMS in particular, as users should not do anything when the new content type is added by for example another recipe. - π©πͺGermany a.dmitriiev
Changes from β¨ Expose Index and Server methods as config actions Active are the first part of actions that will be added to search api. These ones were the easiest, as they are just action methods from entity methods that already existed on Search API config entities Index and Server.
## Search Index Config Actions
### `setOption/setOptions` - Set index option(s) .
These actions 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:
```
config:
action:
search_api.index.example:
setOption:
cron_limit: 50
```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` - Remove datasource from index.
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. 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:
```
config:
action:
search_api.index.example:
removeDatasource: 'entity:user'
```### `removeProcessor` - Remove processor from index
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:
```
config:
action:
search_api.index.example:
removeProcessor: 'entity_status'
```### `renameField` - Rename index field
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` - Remove field from index
If the field is not needed anymore, it can be removed from index. This config action accepts 1 argument the field id in index:
```
config:
action:
search_api.index.example:
removeField: my_unique_pretty_name
```## Search Server
### `setBackendConfig` - Set backend config
This 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
```
This example shows what can be configured for Database backend - π©πͺGermany a.dmitriiev
More config actions will be added soon. This was only the first part.