Work-Related/search_core
Work-Related/search_core
1
0
mirror of https://github.com/Codappix/search_core.git synced 2024-11-22 03:36:11 +01:00
Code Releases Activity

TASK: Update / cleanup documentation

Browse source 
Code and docs have diverged a bit. We therefore need to update them.
This commit is contained in:
Daniel Siepmann 2018-03-08 08:17:41 +01:00
parent 89065305c4
commit 4756da5c5d
Signed by: Daniel Siepmann
GPG key ID: 33D6629915560EF4
23 changed files with 434 additions and 354 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
Documentation/source/changelog/20180406-120-facet-configuration.rst
View file

@ -1,4 +1,4 @@
Breacking Change 120 "Pass facets configuration to elasticsearch"
Breacking Change 120 "Pass facets configuration to Elasticsearch"
=================================================================
In order to allow arbitrary facet configuration, we do not process the facet configuration anymore.
@ -35,6 +35,6 @@ Instead you have to provide the full configuration yourself:
}
}
You need to add line 4 and 6, the additional level ``terms`` for elasticsearch.
You need to add line 4 and 6, the additional level ``terms`` for Elasticsearch.
See :issue:`120`.

33
Documentation/source/concepts.rst
View file

@ -3,33 +3,35 @@
Concepts
========
The extension is built with the following concepts in mind.
The main concept is to provide a foundation where other developers can profit from, to provide
integrations into search services like Elasticsearch, Algolia, ... .
Our code contains the following concepts which should be understand:
.. _concepts_connections:
Connections
-----------
It should be possible to use different search services like elasticsearch and solr out of the box.
If a service is not contained, it should be possible to implement the necessary part by implementing
the necessary interfaces and configuring the extension to use the new connection.
Different search services can provide integrations. ``search_core`` only provides abstractions and
interfaces. The main purpose is to provide a stable API between TYPO3 and concrete connection.
Also it should be possible to use multiple connections at once. This way multiple search services
can be used in the same installation.
Currently only :ref:`Elasticsearch` is provided.
For information about implementing a new connection, take a look at :ref:`development_connection`.
.. _concepts_indexing:
Indexing
--------
The indexing is done by one of the available indexer. For each identifier it's possible to define
the indexer to use. Also it's possible to write custom indexer to use.
Indexing is the process of collecting and preparing data, before sending it to a Connection.
The indexing is done by one of the available indexer. Indexer are identified by a key, as configured
in TypoScript.
Currently only the :ref:`TcaIndexer` is provided.
Currently :ref:`TcaIndexer` and :ref:`PagesIndexer` are provided.
.. _concepts_indexing_dataprocessing:
For information about implementing a new indexer, take a look at :ref:`development_indexer`.
.. _concepts_dataprocessing:
DataProcessing
^^^^^^^^^^^^^^
@ -39,4 +41,9 @@ known by :ref:`t3tsref:cobj-fluidtemplate-properties-dataprocessing` of :ref:`t3
The same is true for retrieved search results. They can be processed again by "DataProcessors" to
prepare data for display in Templates or further usage.
Configuration is done through TypoScript, see :ref:`dataProcessing`.
This should keep indexers simple and move logic to DataProcessors. This makes most parts highly
flexible as integrators are able to configure DataProcessors and change their order.
Configuration is done through TypoScript, see :ref:`dataprocessors`.
For information about implementing a new DataProcessor, take a look at :ref:`development_dataprocessor`.

10
Documentation/source/conf.py
View file

@ -51,7 +51,7 @@ master_doc = 'index'
# General information about the project.
project = u'TYPO3 Extension search_core'
copyright = u'2016, Daniel Siepmann'
copyright = u'2016 - 2018, Daniel Siepmann'
author = u'Daniel Siepmann'
# The version info for the project you're documenting, acts as replacement for
@ -59,9 +59,9 @@ author = u'Daniel Siepmann'
# built documents.
#
# The short X.Y version.
version = u'1.0.0'
version = u'0.0.1'
# The full version, including alpha/beta/rc tags.
release = u'1.0.0'
release = u'0.0.1'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
@ -133,7 +133,7 @@ html_theme_options = {
# The name for this set of Sphinx documents.
# "<project> v<release> documentation" by default.
#html_title = u'TYPO3 Extension search_core v1.0.0'
#html_title = u'TYPO3 Extension search_core v0.0.1'
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
@ -150,7 +150,7 @@ html_theme_options = {
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
# html_static_path = ['_static']
# Add any extra paths that contain custom files (such as robots.txt or
# .htaccess) here, relative to this directory. These files are copied

8
Documentation/source/configuration.rst
View file

@ -8,9 +8,9 @@ Configuration
Installation wide configuration is handled inside of the extension manager. Just check out the
options there, they all have labels.
The extension offers the following configuration options through TypoScript. If you overwrite them
through `setup` make sure to keep them in the `module` area as they will be accessed from backend
mode of TYPO3 for indexing. Do so by placing the following line at the end::
Everything else is configured through TypoScript. If you overwrite them through `setup` make sure to
keep them in the `module` area as they will be accessed from backend mode of TYPO3 for indexing. Do
so by placing the following line at the end::
module.tx_searchcore < plugin.tx_searchcore
@ -26,12 +26,10 @@ Here is the example default configuration that's provided through static include
.. literalinclude:: ../../Configuration/TypoScript/constants.txt
:language: typoscript
:linenos:
:caption: Static TypoScript Constants
.. literalinclude:: ../../Configuration/TypoScript/setup.txt
:language: typoscript
:linenos:
:caption: Static TypoScript Setup
.. _configuration_options:

11
Documentation/source/configuration/connections.rst
View file

@ -4,7 +4,7 @@ Connections
===========
Holds settings regarding the different possible connections for search services like Elasticsearch
or Solr.
or Algolia.
Configured as::
@ -22,15 +22,13 @@ Configured as::
Where ``connectionName`` is one of the available :ref:`connections`.
The following settings are available. For each setting its documented which connection consumes it.
The following settings are available.
.. _host:
``host``
--------
Used by: :ref:`Elasticsearch`.
The host, e.g. ``localhost`` or an IP where the search service is reachable from TYPO3
installation.
@ -43,13 +41,8 @@ Example::
``port``
--------
Used by: :ref:`Elasticsearch`.
The port where search service is reachable. E.g. default ``9200`` for Elasticsearch.
Example::
plugin.tx_searchcore.settings.connections.elasticsearch.port = 9200

2
Documentation/source/configuration/dataProcessing/RemoveProcessor.rst
View file

@ -1,7 +1,7 @@
``Codappix\SearchCore\DataProcessing\RemoveProcessor``
======================================================
Will remove fields from record, e.g. if you do not want to sent them to elasticsearch at all.
Will remove fields from record.
Possible Options:

36
Documentation/source/configuration/dataProcessing/availableAndPlanned.rst
View file

@ -1,36 +0,0 @@
The following Processor are available:
.. toctree::
:maxdepth: 1
:glob:
/configuration/dataProcessing/ContentObjectDataProcessorAdapterProcessor
/configuration/dataProcessing/CopyToProcessor
/configuration/dataProcessing/GeoPointProcessor
/configuration/dataProcessing/RemoveProcessor
The following Processor are planned:
``Codappix\SearchCore\DataProcessing\ReplaceProcessor``
Will execute a search and replace on configured fields.
``Codappix\SearchCore\DataProcessing\RootLevelProcessor``
Will attach the root level to the record.
``Codappix\SearchCore\DataProcessing\ChannelProcessor``
Will add a configurable channel to the record, e.g. if you have different areas in your
website like "products" and "infos".
``Codappix\SearchCore\DataProcessing\RelationResolverProcessor``
Resolves all relations using the TCA.
Of course you are able to provide further processors. Just implement
``Codappix\SearchCore\DataProcessing\ProcessorInterface`` and use the FQCN (=Fully qualified
class name) as done in the examples above.
By implementing also the same interface as necessary for TYPO3
:ref:`t3tsref:cobj-fluidtemplate-properties-dataprocessing`, you are able to reuse the same code
also for Fluid to prepare the same record fetched from DB for your fluid.
Dependency injection is possible inside of processors, as we instantiate through extbase
``ObjectManager``.

54
Documentation/source/configuration/indexing.rst
View file

@ -40,11 +40,7 @@ Contains a comma separated list of page uids. Spaces are trimmed.
Example::
plugin.tx_searchcore.settings.indexing.<identifier>.rootLineBlacklist = 3, 10, 100
Also it's possible to define some behaviour for the different document types. In context of TYPO3
tables are used as document types 1:1. It's possible to configure different tables. The following
options are available:
plugin.tx_searchcore.settings.indexing.pages.rootLineBlacklist = 3, 10, 100
.. _additionalWhereClause:
@ -55,16 +51,16 @@ Used by: :ref:`TcaIndexer`, :ref:`PagesIndexer`.
Add additional SQL to where clauses to determine indexable records from the table. This way you
can exclude specific records like ``tt_content`` records with specific ``CType`` values or
something else. E.g. you can add a new field to the table to exclude records from indexing.
something else.
Example::
plugin.tx_searchcore.settings.indexing.<identifier>.additionalWhereClause = tt_content.CType NOT IN ('gridelements_pi1', 'list', 'div', 'menu')
plugin.tx_searchcore.settings.indexing.tt_content.additionalWhereClause = tt_content.CType NOT IN ('gridelements_pi1', 'list', 'div', 'menu')
.. attention::
Make sure to prefix all fields with the corresponding table name. The selection from
database will contain joins and can lead to SQL errors if a field exists in multiple tables.
database might contain joins and can lead to SQL errors if a field exists in multiple tables.
.. _abstractFields:
@ -73,6 +69,10 @@ abstractFields
Used by: :ref:`PagesIndexer`.
.. note::
Will be migrated to :ref:`dataprocessors` in the future.
Define which field should be used to provide the auto generated field "search_abstract".
The fields have to exist in the record to be indexed. Therefore fields like ``content`` are also
possible.
@ -80,7 +80,7 @@ possible.
Example::
# As last fallback we use the content of the page
plugin.tx_searchcore.settings.indexing.<identifier>.abstractFields := addToList(content)
plugin.tx_searchcore.settings.indexing.pages.abstractFields := addToList(content)
Default::
@ -91,10 +91,10 @@ Default::
mapping
-------
Used by: Elasticsearch connection while indexing.
Used by: :ref:`connection_elasticsearch` connection while indexing.
Define mapping for Elasticsearch, have a look at the official docs: https://www.elastic.co/guide/en/elasticsearch/reference/5.2/mapping.html
You are able to define the mapping for each property / columns.
You are able to define the mapping for each property / column.
Example::
@ -112,7 +112,7 @@ makes building a facet possible.
index
-----
Used by: Elasticsearch connection while indexing.
Used by: :ref:`connection_elasticsearch` connection while indexing.
Define index for Elasticsearch, have a look at the official docs: https://www.elastic.co/guide/en/elasticsearch/reference/5.2/indices-create-index.html
@ -141,36 +141,12 @@ Example::
``char_filter`` and ``filter`` are a comma separated list of options.
.. _dataProcessing:
.. _indexing_dataProcessing:
dataProcessing
--------------
Used by: All connections while indexing, due to implementation inside ``AbstractIndexer``.
Configure modifications on each document before sending it to the configured connection. Same as
provided by TYPO3 for :ref:`t3tsref:cobj-fluidtemplate` through
:ref:`t3tsref:cobj-fluidtemplate-properties-dataprocessing`.
All processors are applied in configured order. Allowing to work with already processed data.
Example::
plugin.tx_searchcore.settings.indexing.tt_content.dataProcessing {
1 = Codappix\SearchCore\DataProcessing\CopyToProcessor
1 {
to = search_spellcheck
}
2 = Codappix\SearchCore\DataProcessing\CopyToProcessor
2 {
to = search_all
}
}
The above example will copy all existing fields to the field ``search_spellcheck``. Afterwards
all fields, including ``search_spellcheck`` will be copied to ``search_all``.
.. include:: /configuration/dataProcessing/availableAndPlanned.rst
Also data processors are available for search results too, see :ref:`searching_dataProcessing`.
Configure modifications on each document before sending it to the configured connection.
For full documentation check out :ref:`dataprocessors`.

166
Documentation/source/configuration/searching.rst
View file

@ -8,45 +8,50 @@ Searching
size
----
Used by: Elasticsearch connection while building search query.
Defined how many search results should be fetched to be available in search result.
Example::
plugin.tx_searchcore.settings.searching.size = 50
Default if not configured is 10.
Default is ``10``.
.. _facets:
facets
------
Used by: Elasticsearch connection while building search query.
Define aggregations for Elasticsearch, have a look at the official docs: https://www.elastic.co/guide/en/elasticsearch/reference/5.2/search-aggregations-bucket-terms-aggregation.html
Currently only the term facet is provided.
Example::
plugin.tx_searchcore.settings.searching.facets {
contentTypes {
field = CType
category {
terms {
field = categories
}
}
The above example will provide a facet with options for all found ``CType`` results together
with a count.
month {
date_histogram {
field = released
interval = month
format = Y-MM-01
order {
_time = desc
}
}
}
The above example will provide a facet with options for all found ``categories`` results together
with a count. Also a facet for ``released`` will be provided.
.. _filter:
filter
------
Used by: While building search request.
Define filter that should be set for all requests.
Define filter that should be set for all search requests.
Example::
@ -54,6 +59,9 @@ Example::
property = value
}
Also see :ref:`mapping.filter` to map incoming request information, e.g. from a ``select``, to build
more complex filters.
For Elasticsearch the fields have to be filterable, e.g. need a mapping as ``keyword``.
.. _minimumShouldMatch:
@ -61,9 +69,8 @@ For Elasticsearch the fields have to be filterable, e.g. need a mapping as ``key
minimumShouldMatch
------------------
Used by: Elasticsearch connection while building search query.
Define the minimum match for Elasticsearch, have a look at the official docs: https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl-minimum-should-match.html
Define the minimum match for Elasticsearch, have a look at the official docs:
https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl-minimum-should-match.html
Example::
@ -74,8 +81,6 @@ Example::
boost
-----
Used by: Elasticsearch connection while building search query.
Define fields that should boost the score for results.
Example::
@ -93,10 +98,9 @@ https://www.elastic.co/guide/en/elasticsearch/guide/2.x/_boosting_query_clauses.
fieldValueFactor
----------------
Used by: Elasticsearch connection while building search query.
Define a field to use as a factor for scoring. The configuration is passed through to elastic
search ``field_value_factor``, see: https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl-function-score-query.html#function-field-value-factor
Define a field to use as a factor for scoring. The configuration is passed through to Elasticsearch
``field_value_factor``, see:
https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl-function-score-query.html#function-field-value-factor
Example::
@ -119,34 +123,34 @@ E.g. you submit a filter in form of:
.. code-block:: html
<f:comment>
Due to TYPO3 7.x fluid limitations, we build this input ourself.
No longer necessary in 8 and above
</f:comment>
<select name="tx_searchcore_search[searchRequest][filter][month][from]" class="_control" >
<option value="">Month</option>
<f:for each="{searchResult.facets.month.options}" as="month">
<f:if condition="{month.count}">
<option
value="{month.displayName -> f:format.date(format: 'Y-m')}"
{f:if(condition: '{searchRequest.filter.month.from} == {month.displayName -> f:format.date(format: \'Y-m\')}', then: 'selected="true"')}
>{month.displayName -> f:format.date(format: '%B %Y')}</option>
</f:if>
</f:for>
</select>
<select name="tx_searchcore_search[searchRequest][filter][month][to]" class="_control" >
<option value="">Month</option>
<f:for each="{searchResult.facets.month.options}" as="month">
<f:if condition="{month.count}">
<option
value="{month.displayName -> f:format.date(format: 'Y-m')}"
{f:if(condition: '{searchRequest.filter.month.from} == {month.displayName -> f:format.date(format: \'Y-m\')}', then: 'selected="true"')}
>{month.displayName -> f:format.date(format: '%B %Y')}</option>
</f:if>
</f:for>
</select>
<f:comment>
Due to TYPO3 7.x fluid limitations, we build this input ourself.
No longer necessary in 8 and above
</f:comment>
<select name="tx_searchcore_search[searchRequest][filter][month][from]" class="_control" >
<option value="">Month</option>
<f:for each="{searchResult.facets.month.options}" as="month">
<f:if condition="{month.count}">
<option
value="{month.displayName -> f:format.date(format: 'Y-m')}"
{f:if(condition: '{searchRequest.filter.month.from} == {month.displayName -> f:format.date(format: \'Y-m\')}', then: 'selected="true"')}
>{month.displayName -> f:format.date(format: '%B %Y')}</option>
</f:if>
</f:for>
</select>
<select name="tx_searchcore_search[searchRequest][filter][month][to]" class="_control" >
<option value="">Month</option>
<f:for each="{searchResult.facets.month.options}" as="month">
<f:if condition="{month.count}">
<option
value="{month.displayName -> f:format.date(format: 'Y-m')}"
{f:if(condition: '{searchRequest.filter.month.from} == {month.displayName -> f:format.date(format: \'Y-m\')}', then: 'selected="true"')}
>{month.displayName -> f:format.date(format: '%B %Y')}</option>
</f:if>
</f:for>
</select>
This will create a ``distance`` filter with subproperties. To make this filter actually work, you
This will create a ``month`` filter with sub properties. To make this filter actually work, you
can add the following TypoScript, which will be added to the filter::
mapping {
@ -167,38 +171,36 @@ can add the following TypoScript, which will be added to the filter::
}
``fields`` has a special meaning here. This will actually map the properties of the filter to fields
in elasticsearch. In above example they do match, but you can also use different names in your form.
On the left hand side is the elasticsearch field name, on the right side the one submitted as a
filter.
in Elasticsearch. On the left hand side is the Elasticsearch field name, on the right side the one
submitted as a filter.
The ``field``, in above example ``released``, will be used as the elasticsearch field for
filtering. This way you can use arbitrary filter names and map them to existing elasticsearch fields.
The ``field``, in above example ``released``, will be used as the Elasticsearch field for
filtering. This way you can use arbitrary filter names and map them to existing Elasticsearch fields.
Everything that is configured inside ``raw`` is passed, as is, to search service, e.g.
elasticsearch.
Elasticsearch.
.. _fields:
fields
------
Defines the fields to fetch and search from elasticsearch. With the following sub keys:
Defines the fields to fetch and search from Elasticsearch. With the following sub keys:
``query`` defines the fields to search in. Default is ``_all`` from 5.x times of elasticsearch.
Configure a comma separated list of fields to search in. This is necessary if you have configured
special mapping for some fields, or just want to search some fields.
The most hits get ranked highest. The following is an example configuration::
``query`` defines the fields to search in. Configure a comma separated list of fields to search in.
This is necessary if you have configured special mapping for some fields, or just want to search
some fields. The following is an example configuration::
fields {
query = _all, city
}
The following sub properties configure the fields to fetch from elasticsearch:
The following sub properties configure the fields to fetch from Elasticsearch:
First ``stored_fields`` which is a list of comma separated fields which actually exist and will be
added. Typically you will use ``_source`` to fetch the whole indexed fields.
Second is ``script_fields``, which allow you to configure scripted fields for elasticsearch.
Second is ``script_fields``, which allow you to configure scripted fields for Elasticsearch.
An example might look like the following::
fields {
@ -221,7 +223,7 @@ In above example we add a single ``script_field`` called ``distance``. We add a
field should be added. The condition will be parsed as Fluidtemplate and is casted to bool via PHP.
If the condition is true, or no ``condition`` exists, the ``script_field`` will be added to the
query. The ``condition`` will be removed and everything else is submitted one to one to
elasticsearch, except each property is run through Fluidtemplate, to allow you to use information
Elasticsearch, except each property is run through Fluidtemplate, to allow you to use information
from search request, e.g. to insert latitude and longitude from a filter, like in the above example.
.. _sort:
@ -246,38 +248,14 @@ Example::
mode = filter
}
Only ``filter`` is allowed as value. Will submit an empty query to switch to filter mode.
Only ``filter`` is allowed as value, as ``search`` is default behaviour. Using ``filter`` will
trigger a search to provide data while visiting the page, possible :ref:`filter` allow you to build
pages like "News".
.. _searching_dataProcessing:
.. _searching_dataprocessing:
dataProcessing
--------------
Used by: All connections while indexing, due to implementation inside ``SearchService``.
Configure modifications on each document before returning search result. Same as provided by TYPO3
for :ref:`t3tsref:cobj-fluidtemplate` through
:ref:`t3tsref:cobj-fluidtemplate-properties-dataprocessing`.
All processors are applied in configured order. Allowing to work with already processed data.
Example::
plugin.tx_searchcore.settings.searching.dataProcessing {
1 = Codappix\SearchCore\DataProcessing\CopyToProcessor
1 {
to = search_spellcheck
}
2 = Codappix\SearchCore\DataProcessing\CopyToProcessor
2 {
to = search_all
}
}
The above example will copy all existing fields to the field ``search_spellcheck``. Afterwards
all fields, including ``search_spellcheck`` will be copied to ``search_all``.
.. include:: /configuration/dataProcessing/availableAndPlanned.rst
Also data processors are available while indexing too, see :ref:`dataProcessing`.
Configure modifications on each document before returning search result.
For full documentation check out :ref:`dataprocessors`.

25
Documentation/source/connections.rst
View file

@ -5,26 +5,25 @@ Connections
See Concept of :ref:`concepts_connections` for further background information.
The extension provides the following connections out of the box:
For information about implementing a new connection, take a look at :ref:`development_connection`.
.. _Elasticsearch:
The following connections were developed, or are in development, for ``search_core``:
.. _connection_elasticsearch:
Elasticsearch
-------------
Integrates `elastic Elasticsearch`_ using `elastica`_ into TYPO3.
Support for `Elasticsearch`_ is provided out of the box by `search_core` at the moment.
Provides basic support like indexing without mappings and full text search at the moment.
.. _Elasticsearch: https://www.elastic.co/products/elasticsearch
The connection is configurable through the following options:
.. _connection_algolia:
* :ref:`host`
Algolia
-------
* :ref:`port`
`search_algolia`_ will integrate `Algolia`_ and is currently under development by Martin Hummer.
* :ref:`mapping`
* :ref:`facets`
.. _elastic Elasticsearch: https://www.elastic.co/products/elasticsearch
.. _elastica: http://elastica.io/
.. _search_algolia: https://github.com/martinhummer/search_algolia/
.. _Algolia: https://www.algolia.com/

98
Documentation/source/dataprocessors.rst Normal file
View file

@ -0,0 +1,98 @@
.. _dataprocessors:
DataProcessors
==============
See Concept of :ref:`concepts_dataprocessing` for further background information.
For information about implementing a new DataProcessor, take a look at
:ref:`development_dataprocessor`.
Same as provided by TYPO3 for :ref:`t3tsref:cobj-fluidtemplate` through
:ref:`t3tsref:cobj-fluidtemplate-properties-dataprocessing`.
.. _dataprocessors_usage:
Usage
-----
All processors are applied in configured order. Allowing to work with already processed data.
They can be applied during indexing and for search results.
Example for indexing::
plugin.tx_searchcore.settings.indexing.pages.dataProcessing {
1 = Codappix\SearchCore\DataProcessing\CopyToProcessor
1 {
to = search_spellcheck
}
2 = Codappix\SearchCore\DataProcessing\CopyToProcessor
2 {
to = search_all
}
}
The above example will copy all existing fields to the field ``search_spellcheck``. Afterwards
all fields, including ``search_spellcheck`` will be copied to ``search_all``.
Example for search results::
plugin.tx_searchcore.settings.searching.dataProcessing {
1 = Codappix\SearchCore\DataProcessing\CopyToProcessor
1 {
to = search_spellcheck
}
2 = Codappix\SearchCore\DataProcessing\CopyToProcessor
2 {
to = search_all
}
}
The above example will copy all existing fields to the field ``search_spellcheck``. Afterwards
all fields, including ``search_spellcheck`` will be copied to ``search_all``.
.. _dataprocessors_availableDataProcessors:
Available DataProcessors
------------------------
.. toctree::
:maxdepth: 1
:glob:
/configuration/dataProcessing/ContentObjectDataProcessorAdapterProcessor
/configuration/dataProcessing/CopyToProcessor
/configuration/dataProcessing/GeoPointProcessor
/configuration/dataProcessing/RemoveProcessor
.. _dataprocessors_plannedDataProcessors:
Planned DataProcessors
----------------------
``Codappix\SearchCore\DataProcessing\ReplaceProcessor``
Will execute a search and replace on configured fields.
``Codappix\SearchCore\DataProcessing\RootLevelProcessor``
Will attach the root level to the record.
``Codappix\SearchCore\DataProcessing\ChannelProcessor``
Will add a configurable channel to the record, e.g. if you have different areas in your
website like "products" and "infos".
``Codappix\SearchCore\DataProcessing\RelationResolverProcessor``
Resolves all relations using the TCA.
This is currently done through indexer.
.. Of course you are able to provide further processors. Just implement
.. ``Codappix\SearchCore\DataProcessing\ProcessorInterface`` and use the FQCN (=Fully qualified
.. class name) as done in the examples above.
.. By implementing also the same interface as necessary for TYPO3
.. :ref:`t3tsref:cobj-fluidtemplate-properties-dataprocessing`, you are able to reuse the same code
.. also for Fluid to prepare the same record fetched from DB for your fluid.
.. Dependency injection is possible inside of processors, as we instantiate through extbase
.. ``ObjectManager``.

75
Documentation/source/development.rst
View file

@ -1,71 +1,16 @@
.. highlight:: bash
.. _contribution:
Contribution
============
Everyone is welcome to contribute, whether it's code, issues, feature requests or any other kind.
Below is a documentation what to respect during contributions.
.. _contribution_setup:
Setup
-----
To start contributions regarding code, make sure your environment matches the following
requirements:
* composer is executable
* PHP on CLI is executable
* MySQL is up and running with user *dev* and password *dev* on *127.0.0.1* or to overwrite the
environment variables, see :file:`Makefile`.
And MySQL is not set to strict mode as TYPO3 doesn't support strict mode, see
https://review.typo3.org/#/c/26725/3/INSTALL.md.
* Elasticsearch is installed and up and running on *localhost:9200*.
Then setup your system::
git clone git@github.com:DanielSiepmann/search_core.git \
&& cd search_core \
&& export typo3DatabaseName="searchcoretest76" \
&& export TYPO3_VERSION="~7.6" \
&& make install \
&& make unitTests \
&& make functionalTests
If all tests are okay, start your work.
If you are working with multiple TYPO3 versions make sure to export `typo3DatabaseName` and
`TYPO3_VERSION` in your environment like::
export typo3DatabaseName="searchcoretest62"
export TYPO3_VERSION="~6.2"
Also run the install command for each version before running any tests. Only this will make sure you
are testing against the actual TYPO3 Version and database scheme.
.. _contribution_development:
Development
-----------
===========
All changes are introduced through pull requests at `Github`_ and should contain the following:
There are some ways we will cover here. One is how you can develop own parts like Indexer,
DataProcessor and Connection. The other is how to contribute.
* Adjusted tests if tests existed before. Otherwise they will break on `travis-ci`_.
.. toctree::
:maxdepth: 1
:glob:
* New tests whenever possible and useful.
* Code has to follow `PSR-2`_.
* Adjusted documentation.
* Make sure to follow the documented :ref:`concepts`.
.. _Github: https://github.com/DanielSiepmann/search_core
.. _travis-ci: https://travis-ci.org/
.. _PSR-2: http://www.php-fig.org/psr/psr-2/
development/indexer
development/dataProcessor
development/connection
development/contribution

11
Documentation/source/development/connection.rst Normal file
View file

@ -0,0 +1,11 @@
.. _development_connection:
Develop a new Connection
========================
Make sure you understood :ref:`concepts_connections`.
Each Connection has to be a single class which implements
``Codappix\SearchCore\Connection\ConnectionInterface``.
Dependency Injection is working for custom Connections.

69
Documentation/source/development/contribution.rst Normal file
View file

@ -0,0 +1,69 @@
.. _contribution:
Contribution
============
Everyone is welcome to contribute, whether it's code, issues, feature requests or any other kind.
Below is a documentation what to respect during contributions.
.. _contribution_setup:
Setup
-----
To start contributions regarding code, make sure your environment matches the following
requirements:
* composer is executable
* PHP on CLI is executable
* MySQL is up and running with user *dev* and password *dev* on *127.0.0.1* or to overwrite the
environment variables, see :file:`Makefile`.
And MySQL is not set to strict mode as TYPO3 doesn't support strict mode, see
https://review.typo3.org/#/c/26725/3/INSTALL.md.
* Elasticsearch is installed and up and running on *localhost:9200*.
Then setup your system::
git clone git@github.com:DanielSiepmann/search_core.git \
&& cd search_core \
&& export typo3DatabaseName="searchcoretest76" \
&& export TYPO3_VERSION="~8.7" \
&& make install \
&& make unitTests \
&& make functionalTests
If all tests are okay, start your work.
If you are working with multiple TYPO3 versions make sure to export `typo3DatabaseName` and
`TYPO3_VERSION` in your environment like::
export typo3DatabaseName="searchcoretest62"
export TYPO3_VERSION="~6.2"
Also run the install command for each version before running any tests. Only this will make sure you
are testing against the actual TYPO3 Version and database scheme.
.. _contribution_development:
Development
-----------
All changes are introduced through pull requests at `Github`_ and should contain the following:
* Adjusted tests if tests existed before. Otherwise they will break on `travis-ci`_.
* New tests whenever possible and useful.
* Code has to follow `PSR-2`_.
* Adjusted documentation.
* Make sure to follow the documented :ref:`concepts`.
.. _Github: https://github.com/DanielSiepmann/search_core
.. _travis-ci: https://travis-ci.org/
.. _PSR-2: http://www.php-fig.org/psr/psr-2/

15
Documentation/source/development/dataProcessor.rst Normal file
View file

@ -0,0 +1,15 @@
.. _development_dataprocessor:
Develop a new DataProcessor
===========================
Make sure you understood :ref:`concepts_dataprocessing`.
Each DataProcessor has to be a single class which implements
``Codappix\SearchCore\DataProcessing\ProcessorInterface``.
Make sure you support both, Frontend and Backend, as processors can be called during searching and
indexing. Therefore do not rely on e.g. ``TSFE``, make sure dependencies are met and your code will
work in both environments.
Dependency Injection is working for custom DataProcessors.

21
Documentation/source/development/indexer.rst Normal file
View file

@ -0,0 +1,21 @@
.. _development_indexer:
Develop a new Indexer
=====================
Make sure you understood :ref:`concepts_indexing`.
Each indexer has to be a single class which implements
``Codappix\SearchCore\Domain\Index\IndexerInterface``.
The indexer should call the connection with all necessary information about the document(s) to
trigger indexing or deletion of whole index.
As this is the "indexer", deletion of single documents is directly processed by the connection.
``setIdentifier`` is called with the identifier of the current Indexer. This might be usefull to
fetch configuration, related to the indexing, from
``Codappix\SearchCore\Configuration\ConfigurationContainerInterface``.
Dependency Injection is working for custom indexers, therefore you are able to inject the
``ConfigurationContainerInterface``.

40
Documentation/source/features.rst
View file

@ -3,28 +3,34 @@
Features
========
The following features are currently provided:
The following features are available:
.. _features_indexing:
Indexing
--------
Indexing data to Elasticsearch is provided. The extension delivers an indexer for TCA with zero
configuration needs. Still it's possible to configure the indexer.
Indexing of data is possible. We deliver an indexer for TCA with zero configuration needs. You can
also provide custom indexer for arbitrary data which is not indexable through TCA.
Also custom classes can be used as indexers.
Also a finisher for TYPO3 Form-Extension is provided to integrate indexing after something was
update through the Form-Extension.
Furthermore a finisher for TYPO3 Form-Extension is provided to integrate indexing.
Indexing is done through Hooks and CLI. We therefore provide commands to index and delete indexed
data.
.. _features_search:
Searching
---------
Currently all fields are searched for a single search input.
.. note::
Currently only integrated for Elasticsearch with no abstraction.
If you need to implement your own search, please open an issue on Github and we will change the code
base.
Also multiple filter are supported. Filtering results by fields for string contents.
Via TypoScript it's possible to configure the fields to query, minimum match and script fields.
Also multiple filter are supported, filtering results by fields.
Facets / aggregates are also possible. Therefore a mapping has to be defined in TypoScript for
indexing, and the facets itself while searching.
@ -32,19 +38,25 @@ indexing, and the facets itself while searching.
.. _features_dataProcessing:
DataProcessing
==============
--------------
DataProcessing, as known from ``FLUIDTEMPLATE`` is available while indexing and for search results.
Each item can be processed by multiple processor to prepare data for indexing and output.
DataProcessing, as known from ``FLUIDTEMPLATE``, is available while indexing and for search results.
Each record and result item can be processed by multiple processor to prepare data for indexing and
output.
See :ref:`concepts_indexing_dataprocessing` in :ref:`concepts` section.
See :ref:`concepts_dataprocessing` in :ref:`concepts` section.
.. _features_planned:
Planned
---------
-------
The following features are currently planned and will be integrated:
#. Pagination
Add a pagination to search results, to allow users to walk through all results.
#. :issue:`25` Multi language.
#. :issue:`94` Respect access rights while indexing relations.
#. :issue:`75` Configuration of index name (for Elasticsearch).
For a full list, check out our `open issues`_.
.. _open issues: https://github.com/Codappix/search_core/issues

3
Documentation/source/index.rst
View file

@ -1,7 +1,7 @@
.. include:: readme.rst
Table of Contents
=================
-----------------
.. toctree::
:maxdepth: 1
@ -14,5 +14,6 @@ Table of Contents
concepts
connections
indexer
dataprocessors
development
changelog

39
Documentation/source/indexer.rst
View file

@ -5,6 +5,8 @@ Indexer
See Concept of :ref:`concepts_indexing` for further background information.
For information about implementing a new indexer, take a look at :ref:`development_indexer`.
The extension provides the following indexer out of the box:
.. _TcaIndexer:
@ -15,23 +17,12 @@ TcaIndexer
Provides zero configuration TYPO3 integration by using the :ref:`t3tcaref:start`. You just can
start indexing TYPO3.
The indexer will use the TCA to fetch all necessary information like relations. Currently the
implementation is very basic. In future it will also provide mapping for :ref:`Elasticsearch` and
further stuff.
Just add the indexer for a TYPO3 table. The indexer will use the TCA to fetch all necessary
information like relations.
The indexer is configurable through the following options:
.. note::
* :ref:`rootLineBlacklist`
* :ref:`additionalWhereClause`
* :ref:`abstractFields`
* :ref:`mapping`
* :ref:`index`
* :ref:`dataProcessing`
Not all relations are resolved yet, see :issue:`17`.
.. _PagesIndexer:
@ -42,23 +33,7 @@ Provides zero configuration TYPO3 integration by using the :ref:`t3tcaref:start`
start indexing TYPO3.
The indexer will use the TCA to fetch all necessary information like relations. Currently the
implementation is very basic. In future it will also provide mapping for :ref:`Elasticsearch` and
further stuff. Also all static content from each page will be concatenated into a single field to
improve search.
The indexer is configurable through the following options:
* :ref:`rootLineBlacklist`
* :ref:`additionalWhereClause`
* :ref:`abstractFields`
* :ref:`mapping`
* :ref:`index`
* :ref:`dataProcessing`
implementation is very basic.
.. note::

28
Documentation/source/installation.rst
View file

@ -4,23 +4,41 @@
Installation
============
Composer
--------
The extension can be installed through composer::
composer require "leonmrni/search_core dev-master as 1.0.x-dev"
composer require "codappix/search_core" "~1.0.0"
or by `downloading`_ and placing it inside the :file:`typo3conf/ext`-Folder of your installation.
In that case you need to install all dependencies yourself. Dependencies are:
Note that you have to allow unstable packages:
.. code-block:: json
{
"minimum-stability": "dev",
"prefer-stable": true
}
Download
--------
You can also `download`_ the extension and placing it inside the :file:`typo3conf/ext`-Folder of
your installation. In that case you need to install all dependencies yourself. Dependencies are:
.. literalinclude:: ../../composer.json
:caption: Dependencies from composer.json
:lines: 19-21
:dedent: 8
Setup
-----
Afterwards you need to enable the extension through the extension manager and include the static
TypoScript setup.
If you **don't** want to use the included elasticsearch integration, you have to disable it in the
If you **don't** want to use the included Elasticsearch integration, you have to disable it in the
extension manager configuration of the extension by checking the checkbox.
It's currently enabled by default but will be moved into its own extension in the future.
.. _downloading: https://github.com/DanielSiepmann/search_core/archive/master.zip
.. _download: https://github.com/codappix/search_core/archive/develop.zip

19
Documentation/source/readme.rst
View file

@ -1,5 +1,5 @@
TYPO3 Extension search_core's documentation!
============================================
TYPO3 Extension search_core
===========================
Introduction
============
@ -8,24 +8,21 @@ What does it do?
----------------
The goal of this extension is to provide search integrations into TYPO3 CMS. The extension will
abstract the concrete implementations to allow exchange of concrete backends like Elasticsearch or
solr.
provide a convenient API to allow developers to provide concrete implementations of backends like
Elasticsearch, Algolia or Solr.
The extension provides integration into TYPO3 like a frontend plugin for searches and hooks to
update search indexes on updates. Also a command line interface is provided for interactions like
reindexing.
re-indexing.
Current state
-------------
This is still a very early beta version. More information can be taken from Github at
`current issues`_ and `current projects`_.
`current issues`_.
We are also focusing on Code Quality and Testing through `travis ci`_, `scrutinizer`_ and `codacy`_.
We are also focusing on Code Quality and Testing through `travis ci`_, ``phpcs``, ``phpunit`` and
``phpstan``.
.. _current issues: https://github.com/Codappix/search_core/issues
.. _current projects: https://github.com/Codappix/search_core/projects
.. _travis ci: https://travis-ci.org/Codappix/search_core
.. _scrutinizer: https://scrutinizer-ci.com/g/Codappix/search_core/inspections
.. _codacy: https://www.codacy.com/app/Codappix/search_core/dashboard

18
Documentation/source/usage.rst
View file

@ -11,9 +11,10 @@ Manual indexing
You can trigger indexing from CLI::
./typo3/cli_dispatch.phpsh extbase index:index --identifier 'tt_content'
./typo3/cli_dispatch.phpsh extbase index:index --identifier 'pages'
./bin/typo3cms index:index --identifier 'pages'
This will index the table ``tt_content`` using the :ref:`TcaIndexer`.
This will index the table ``pages`` using the :ref:`TcaIndexer`.
Only one index per call is available, to run multiple indexers, just make multiple calls.
The indexers have to be defined in TypoScript via :ref:`configuration_options_index`.
@ -25,9 +26,10 @@ Manual deletion
You can trigger deletion for a single index from CLI::
./typo3/cli_dispatch.phpsh extbase index:delete --identifier 'tt_content'
./typo3/cli_dispatch.phpsh extbase index:delete --identifier 'pages'
./bin/typo3cms index:delete --identifier 'pages'
This will delete the index for the table ``tt_content``.
This will delete the index for the table ``pages``.
Only one delete per call is available, to run multiple deletions, just make multiple calls.
@ -53,7 +55,6 @@ A form finisher is provided to integrate indexing into form extension.
Add form finisher to your available finishers and configure it like:
.. code-block:: yaml
:linenos:
-
identifier: SearchCoreIndexer
@ -62,7 +63,7 @@ Add form finisher to your available finishers and configure it like:
indexIdentifier: 'fe_users'
recordUid: '{FeUser.user.uid}'
All three options are necessary, where
All three options are necessary, where:
``action``
Is one of ``delete``, ``update`` or ``add``.
@ -81,7 +82,7 @@ plugin. The plugin is named *Search Core*.
Please provide your own template, the extension will not deliver a useful template for now.
The extbase mapping is used, this way you can create a form:
The Extbase mapping is used, this way you can create a form:
.. code-block:: html
@ -95,11 +96,10 @@ The extbase mapping is used, this way you can create a form:
Filter
""""""
Thanks to extbase mapping, filter are added to the form:
Thanks to Extbase mapping, filter are added to the form:
.. code-block:: html
<!-- Case sensitive for fields of type keyword. -->
<f:form.textfield property="filter.exampleName" value="the value to match" />
.. _usage_searching_facets:

3
composer.json
View file

@ -37,6 +37,9 @@
]
},
"extra": {
"branch-alias": {
"dev-develop": "0.0.1"
},
"typo3/cms": {
"cms-package-dir": "{$vendor-dir}/typo3/cms",
"web-dir": ".Build/web"