English Version

Zurück zur Übersicht

Facebook Pixel: Installation und Betrieb

Live Demo: Teste dieses und weitere Plugins live — ohne Installation, ohne Risiko: demo.markus-michalski.net

Installation

Das Repository ist privat und wird über Packeton (https://packeton.markus-michalski.net) ausgeliefert. Die Zugangsdaten gibt es nach Lizenzkauf oder Freigabe.

{ "repositories": [{ "type": "composer", "url": "https://packeton.markus-michalski.net" }] }

composer require mmd/sylius-facebook-pixel-plugin

1. Bundle in config/bundles.php registrieren:

   Mmd\SyliusFacebookPixelPlugin\MmdSyliusFacebookPixelPlugin::class => ['all' => true],
   

2. Admin-Routen importieren, z. B. in config/routes/mmd_sylius_facebook_pixel.yaml:

   mmd_sylius_facebook_pixel_admin:
       resource: "@MmdSyliusFacebookPixelPlugin/config/routes/admin.yaml"
   

3. Setup-Command ausführen:

   bin/console mmd:facebook-pixel:setup
   

Das Plugin hat keine eigenen Shop-Routen: Der Pixel wird über Twig Hooks gerendert, die Shop-API-Resource registriert sich selbst (sofern API Platform im Shop aktiv ist).

mmd:facebook-pixel:setup führt nur die offenen Migrationen dieses Plugins aus (vier Stück: Settings-Tabelle, Klaro-Katalog-Eintrag und zwei zusätzliche Spalten), nie die der App oder anderer Plugins. Der Command ist idempotent: Ohne neue Migration passiert nichts, auch nach jedem composer update. Sind eigene Migrationen offen, aber Migrationen von Sylius (oder, falls installiert, von mmd/sylius-klaro-consent-plugin) noch nicht ausgeführt, bricht er ab und bittet zuerst um doctrine:migrations:migrate. Er prüft außerdem, ob die Admin-Routen aus Schritt 2 importiert sind, und gibt sonst den passenden Snippet aus. Er schreibt nie selbst in die config/. In Skripten --no-interaction ergänzen. Das klassische doctrine:migrations:migrate funktioniert weiterhin als Alternative.

Bis ein Channel in der Admin-Oberfläche eine Zeile mit Pixel-ID erhält (siehe Konfiguration), verhält sich das Plugin, als wäre es nicht installiert: Nichts wird gerendert, nichts an Meta gesendet. Admin-Grid, Twig Hooks, Shop-API-Resource, Messenger-Routing und Doctrine-Mapping registrieren sich selbst.

Für die serverseitigen Events (CAPI) muss ein Messenger-Worker für den main-Transport laufen, siehe Technische Details.

Update

composer update mmd/sylius-facebook-pixel-plugin
bin/console mmd:facebook-pixel:setup --no-interaction
bin/console cache:clear

Der erneute Aufruf des Setup-Commands nach jedem Update ist gefahrlos: Ohne neue Migration passiert nichts.

Deinstallation

Die Reihenfolge ist wichtig, denn Doctrine kennt die Migrationen nur, solange das Bundle noch registriert ist. Zurückrollen, neueste zuerst:

bin/console doctrine:migrations:execute --down 'Mmd\SyliusFacebookPixelPlugin\Migrations\Version20261004130000'
bin/console doctrine:migrations:execute --down 'Mmd\SyliusFacebookPixelPlugin\Migrations\Version20261004120000'
bin/console doctrine:migrations:execute --down 'Mmd\SyliusFacebookPixelPlugin\Migrations\Version20261004110000'
bin/console doctrine:migrations:execute --down 'Mmd\SyliusFacebookPixelPlugin\Migrations\Version20261004100000'

Danach Routen-Import und Bundle-Eintrag aus config/bundles.php entfernen und abschließend:

composer remove mmd/sylius-facebook-pixel-plugin
bin/console cache:clear

Die Migration Version20261004110000 entfernt beim Zurückrollen den Dienst facebook_pixel samt Übersetzungen aus dem Consent-Katalog von mmd/sylius-klaro-consent-plugin (ein No-Op, falls dessen Tabellen nicht existieren). Das gilt für jeden Katalog-Eintrag mit diesem Code, auch wenn er später von Hand bearbeitet wurde. Die dritte und vierte Migration entfernen nur die jeweilige Spalte, die erste löscht die Settings-Tabelle des Plugins.