tracking/Documentation/Recordview.rst
Daniel Siepmann 5f0490f493
WIP|Add flags feature
Allow each tracking record to contain arbitrary tags.
Those tags are generated via an API and can be extended by foreign
extensions or for individual projects.
Existing operating_system was moved to this new feature.
The update command allows to migrate existing records to this new
feature.

Those flags can be used when configuring widgets.

A new flag was added bot:yes and bot:no.
Bots are now tracked but flagged.

That new feature allows to build fine grained reports and makes the
extension way more flexible. Possible new implications:
    - Show visits from none bots
    - Show visits from bots
    - Show visits from specific bot
    - Add color to page views per page (bar chart)
      to color bot or none bot

WIP:
    - Update Yaml file to work like before, no bots in widgets
    - Add documentation (widgets)
    - Add documentation (migration *.yaml)
2022-09-21 17:33:27 +02:00

3.4 KiB

Recordview

Many installations will have custom records beside TYPO3 pages. E.g. one uses EXT:news or EXT:tt_address to display news or personal information.

Those typically are displayed via a Plugin content element leading to the same Page for all records. This part allows to track views of individual records.

All configuration happens via t3coreapi:DependencyInjection inside of Services.yaml of your Sitepackage.

Note

In contrast to pageview, there is no default rule. No record is tracked by default as no TYPO3 installation has any default records to track.

In order to start tracking records, the rules need to be configured.

Screenshot of list view of created "recordview" records.
Screenshot of edit form view of created "recordview" records.

Saved record

Whenever a recordview is tracked, a new record is created. The record can be viewed via TYPO3 list module. That way all collected information can be checked.

Configure tracking

Let us examine an concrete example:

services:
  _defaults:
    autowire: true
    autoconfigure: true
    public: false

  DanielSiepmann\Tracking\Middleware\Recordview:
    public: true
    arguments:
      $rules:
        news:
          matches: >
              request.getQueryParams()["tx_news_pi1"] && request.getQueryParams()["tx_news_pi1"]["news"] > 0
              and not (context.getAspect("backend.user").isLoggedIn())
              and not (context.getAspect("frontend.preview").isPreview())
          recordUid: 'traverse(request.getQueryParams(), "tx_news_pi1", "news")'
          tableName: 'tx_news_domain_model_news'

The first paragraph will not be explained, check out t3coreapi:configure-dependency-injection-in-extensions instead.

The second paragraph is where the tracking is configured. The PHP class DanielSiepmann\Tracking\Middleware\Recordview is registered as PHP middleware and will actually track the request. Therefore this class is configured. The only interesting argument to configure is $rules. The argument itself is an array. That way one can configure multiple rules, e.g. one per record. The above example includes a single rule for topics, but further can be added.

Each rule has the following options which are all mandatory:

matches

A Symfony Expression, which is used to check whether the current rule should be processed for current request. Check pageview to get further information, as it is the same implementation and concept.

recordUid

A Symfony Expression, which is used to fetch the UID of the actual record from current request. Only the request itself is provided within the expression. Check PSR-7: HTTP message interfaces.

tableName

A simple string which defines the actual database table name where records are stored.

Widgets

The extension does not provide any widgets, but providers for widgets of EXT:dashboard. That way widgets of EXT:dashboard can be combined with all providers of this extension.

The concepts are not documented here, check t3dashboard:start instead.

RecordviewWidgets/*