Deutsche Version

Back to overview

Facebook Pixel: Installation and Operation

Live Demo: Try this and other plugins live — no installation, no risk: demo.markus-michalski.net

Installation

The repository is private and delivered through Packeton (https://packeton.markus-michalski.net). Credentials are provided after a license purchase or on request.

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

composer require mmd/sylius-facebook-pixel-plugin

1. Register the bundle in config/bundles.php:

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

2. Import the admin routes, for example in config/routes/mmd_sylius_facebook_pixel.yaml:

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

3. Run the setup command:

   bin/console mmd:facebook-pixel:setup
   

The plugin has no storefront routes of its own: the pixel is rendered through Twig hooks, and the Shop API resource registers itself (as long as API Platform is active in the shop).

mmd:facebook-pixel:setup executes only the open migrations of this plugin (four of them: the settings table, a Klaro catalog entry and two additional columns), never those of the app or of other plugins. The command is idempotent: without a new migration nothing happens, even after every composer update. If own migrations are open but migrations of Sylius (or, if installed, of mmd/sylius-klaro-consent-plugin) have not been executed yet, it stops and asks you to run doctrine:migrations:migrate first. It also checks that the admin routes from step 2 are imported and otherwise prints the matching snippet. It never writes into config/ itself. In scripts, add --no-interaction. The classic doctrine:migrations:migrate still works as an alternative.

Until a channel gets a row with a pixel ID in the admin (see Configuration), the plugin behaves as if it were not installed: nothing is rendered and nothing is sent to Meta. The admin grid, Twig hooks, Shop API resource, Messenger routing and Doctrine mapping register themselves.

For the server-side events (CAPI), a Messenger worker for the main transport must be running, see Technical Details.

Update

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

Running the setup command again after every update is safe: without a new migration nothing happens.

Uninstall

The order matters, because Doctrine only knows the migrations while the bundle is still registered. Roll back, newest first:

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'

Then remove the route import and the bundle entry from config/bundles.php and finish with:

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

When rolled back, the migration Version20261004110000 removes the facebook_pixel service including its translations from the consent catalog of mmd/sylius-klaro-consent-plugin (a no-op if its tables do not exist). This applies to any catalog entry with that code, even if it was edited by hand later. The third and fourth migrations only remove their respective column; the first one drops the plugin's settings table.