Search results are now processed through data processing by search
service. The result will be a SearchResult model from our domain. Also
SearchResult will execute new queries, e.g. from paginate widget,
through SearchService to apply data processing again.
Remove duplicate stub code to trait, to keep own logic and code clean.
Use own service to handle data processing. Classes like indexer should
not know anything about the structure and how to process the data.
Also rename record to data, as we can process just any data in form of
an array.
Relates: #116
This way injects will be resolved inside of processors, enabling
developers to inject dependencies.
We use inject instead of constructor as indexers mostly will change the
constructor and should not need to add the objectmanager.
Resolves: #117
Relations were inserted by TYPO3's DataHandler after indexing and were
therefore not indexed.
We now use a later hook after DataHandler has finished everything, so we
know that we can index. As it's not relevant, we do not differentiate
between add and update anymore, as both trigger "indexDocument" internal.
Resolves: #112
This extension currently ships with Elasticsearch integration which is
enabled by default. This behaviour is kept for backwards compatibility.
Still you now have the possibility to disable this integration in
extension manager, just check the "disable" box for elasticsearch.
In the future elasticsearch will become another extension and no default
is shipped with search_core. But for now, as we are still in alpha /
beta phase we keep things together to keep development fast.
Resolves: #111
This way we need no external service.
Each developer can fully run all tests and cgl on local environment.
Also this integrated better into IDEs and editors.
Before data processing was applied for TCA only, through tca table
service.
Now it's applied much later in process and in abstract indexer.
Therefore all indexer will run data processing if configured.
Add a new processor, with docs and tests, to allow removal of fields
before sending them to search service like elasticsearch.
E.g. remove sensitive information that should not be available.
This will be the case if you add a flexform to the plugin with no value.
Then an empty filter is configured and you will not be able to submit a
value for this filter.