TASK: Update / cleanup documentation

Code and docs have diverged a bit. We therefore need to update them.

Documentation/source/changelog/20180406-120-facet-configuration.rst

@@ -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`.

Documentation/source/concepts.rst

@@ -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.
+Different search services can provide integrations. ``search_core`` only provides abstractions and
-If a service is not contained, it should be possible to implement the necessary part by implementing
+interfaces. The main purpose is to provide a stable API between TYPO3 and concrete connection.
-the necessary interfaces and configuring the extension to use the new connection.
 
-Also it should be possible to use multiple connections at once. This way multiple search services
+For information about implementing a new connection, take a look at :ref:`development_connection`.
-can be used in the same installation.
-
-Currently only :ref:`Elasticsearch` is provided.
 
 .. _concepts_indexing:
 
 Indexing
 --------
 
-The indexing is done by one of the available indexer. For each identifier it's possible to define
+Indexing is the process of collecting and preparing data, before sending it to a Connection.
-the indexer to use. Also it's possible to write custom indexer to use.
+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`.

Documentation/source/conf.py

@@ -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

Documentation/source/configuration.rst

@@ -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
+Everything else is configured through TypoScript. If you overwrite them through `setup` make sure to
-through `setup` make sure to keep them in the `module` area as they will be accessed from backend
+keep them in the `module` area as they will be accessed from backend mode of TYPO3 for indexing. Do
-mode of TYPO3 for indexing. Do so by placing the following line at the end::
+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:

Documentation/source/configuration/connections.rst

@@ -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
-
-
-

Documentation/source/configuration/dataProcessing/RemoveProcessor.rst

@@ -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:
 

Documentation/source/configuration/dataProcessing/availableAndPlanned.rst

@@ -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``.

Documentation/source/configuration/indexing.rst

@@ -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
+    plugin.tx_searchcore.settings.indexing.pages.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:
 
 .. _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
+Configure modifications on each document before sending it to the configured connection.
-provided by TYPO3 for :ref:`t3tsref:cobj-fluidtemplate` through
+For full documentation check out :ref:`dataprocessors`.
-: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`.

Documentation/source/configuration/searching.rst

@@ -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 {
+    category {
-        contentTypes {
+        terms {
-            field = CType
+            field = categories
         }
     }
 
-The above example will provide a facet with options for all found ``CType`` results together
+    month {
-with a count.
+        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 search requests.
-
-Define filter that should be set for all 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 Elasticsearch
-
+``field_value_factor``, see:
-Define a field to use as a factor for scoring. The configuration is passed through to elastic
+https://www.elastic.co/guide/en/elasticsearch/reference/5.2/query-dsl-function-score-query.html#function-field-value-factor
-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
 
 Example::
 
@@ -146,7 +150,7 @@ E.g. you submit a filter in form of:
        </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.
+in Elasticsearch. On the left hand side is the Elasticsearch field name, on the right side the one
-On the left hand side is the elasticsearch field name, on the right side the one submitted as a
+submitted as a filter.
-filter.
 
-The ``field``, in above example ``released``, will be used as the elasticsearch field for
+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.
+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.
+``query`` defines the fields to search in. Configure a comma separated list of fields to search in.
-Configure a comma separated list of fields to search in. This is necessary if you have configured
+This is necessary if you have configured special mapping for some fields, or just want to search
-special mapping for some fields, or just want to search some fields.
+some fields. The following is an example configuration::
-The most hits get ranked highest. 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.
-
+For full documentation check out :ref:`dataprocessors`.
-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`.

Documentation/source/connections.rst

@@ -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`
+.. _search_algolia: https://github.com/martinhummer/search_algolia/
-
+.. _Algolia: https://www.algolia.com/
-* :ref:`facets`
-
-.. _elastic Elasticsearch: https://www.elastic.co/products/elasticsearch
-.. _elastica: http://elastica.io/

Documentation/source/dataprocessors.rst

@@ -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``.

Documentation/source/development.rst

@@ -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.
+   development/indexer
-
+   development/dataProcessor
-* Code has to follow `PSR-2`_.
+   development/connection
-
+   development/contribution
-* 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/

Documentation/source/development/connection.rst

@@ -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.

Documentation/source/development/contribution.rst

@@ -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/

Documentation/source/development/dataProcessor.rst

@@ -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.

Documentation/source/development/indexer.rst

@@ -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``.

Documentation/source/features.rst

@@ -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
+Indexing of data is possible. We deliver an indexer for TCA with zero configuration needs. You can
-configuration needs. Still it's possible to configure the indexer.
+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.
+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.
+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
+#. :issue:`25` Multi language.
-   Add a pagination to search results, to allow users to walk through all results.
+#. :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

Documentation/source/index.rst

@@ -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

Documentation/source/indexer.rst

@@ -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
+Just add the indexer for a TYPO3 table. The indexer will use the TCA to fetch all necessary
-implementation is very basic. In future it will also provide mapping for :ref:`Elasticsearch` and
+information like relations.
-further stuff.
 
-The indexer is configurable through the following options:
+.. note::
 
-* :ref:`rootLineBlacklist`
+  Not all relations are resolved yet, see :issue:`17`.
-
-* :ref:`additionalWhereClause`
-
-* :ref:`abstractFields`
-
-* :ref:`mapping`
-
-* :ref:`index`
-
-* :ref:`dataProcessing`
 
 .. _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
+implementation is very basic.
-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`
 
 .. note::
 

Documentation/source/installation.rst

@@ -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.
+Note that you have to allow unstable packages:
-In that case you need to install all dependencies yourself. Dependencies are:
+
+.. 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

Documentation/source/readme.rst

@@ -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
+provide a convenient API to allow developers to provide concrete implementations of backends like
-solr.
+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
-

Documentation/source/usage.rst

@@ -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:

composer.json

@@ -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"