Matomo Analytics: Extensibility

Matomo Analytics for Sylius - replaceable interfaces, service IDs and events, an example of a decorated resolver, and which classes are not part of the stable extension API

Deutsche Version

Back to overview

Matomo Analytics: Extensibility

This documentation always describes the latest published version.

What you can depend on

The plugin offers few, targeted extension points. The interfaces, service IDs and events on this page count as stable. The constructors and internals of the concrete classes are explicitly not part of the extension API and may change in a minor release.

Do not extend the concrete classes (form type, listener, Twig extension, repository, resolver). Decorate the interfaces below instead, or plug in your own implementation.

Interfaces

Interface	Purpose
`Mmd\SyliusMatomoIntegrationPlugin\Tracking\TrackingConfigResolverInterface`	Resolves the tracking configuration of a channel (`forChannelCode(string): ?TrackingConfig`). Storefront and Shop API both go through it, which makes it the natural point to decorate. Service ID: `mmd_sylius_matomo.tracking_config_resolver`
`Mmd\SyliusMatomoIntegrationPlugin\Settings\ChannelSettingsRepositoryInterface`	Reads the settings of a channel from the database (service ID `mmd_sylius_matomo.channel_settings_repository`)
`Mmd\SyliusMatomoIntegrationPlugin\Entity\ChannelSettingsInterface`	The type of the settings in the signatures of the repository, the Klaro integration and the tracking configuration. The model itself cannot be replaced, see below
`Mmd\SyliusMatomoIntegrationPlugin\Klaro\KlaroAvailabilityInterface`	Decides whether the Klaro plugin is available
`Mmd\SyliusMatomoIntegrationPlugin\Klaro\ConsentServiceCatalogInterface`	The interface to the Klaro catalog. A custom implementation can connect a different consent manager

The settings model cannot be replaced

The class ChannelSettings is hard-wired in several places: in the repository, in the admin form, in the grid and in the registration as a Sylius resource. A custom implementation of ChannelSettingsInterface would therefore not be used by any of them. You cannot add extra fields with this plugin. If you need additional data per channel, create your own entity in your project for it.

Events and tags

The plugin dispatches no events of its own. It listens to these existing ones:

Event	Who reacts	Effect
`sylius.menu.admin.main`	plugin	Adds the group MMKreativ Plugins with the entry Matomo Analytics
`mmd_sylius_matomo_integration_plugin.channel_settings.post_create`	plugin	Creates the Klaro service if Klaro gating is on
`mmd_sylius_matomo_integration_plugin.channel_settings.post_update`	plugin	Same, when editing

The two resource events are Sylius's usual lifecycle events for the resource channel_settings. You can register your own listeners on them, for example to clear a cache after saving.

For logging, the resolver uses the Monolog channel mmd_matomo, which you can route separately in monolog.yaml.

Example: decorating the resolver

You want to suppress tracking for a test channel with the code STAGING in general, even if an entry exists there:

services:
    App\Matomo\NoTrackingForStagingResolver:
        decorates: Mmd\SyliusMatomoIntegrationPlugin\Tracking\TrackingConfigResolverInterface
        arguments:
            - '@.inner'

final class NoTrackingForStagingResolver implements TrackingConfigResolverInterface
{
    public function __construct(private TrackingConfigResolverInterface $inner)
    {
    }

    public function forChannelCode(string $channelCode): ?TrackingConfig
    {
        return 'STAGING' === $channelCode ? null : $this->inner->forChannelCode($channelCode);
    }
}

If the resolver returns null, the storefront and the Shop API behave as for a channel without tracking.

Installing a second MMKreativ plugin

The sidebar group MMKreativ Plugins is set up identically in every MMKreativ plugin and merged through the code mmd_plugins. You do not have to configure anything for this.