Weave Code
Tagcommander Bundle Laravel Package
steamulo/tagcommander-bundle
steamulo/tagcommander-bundle integrates Commanders Act TagCommander with Symfony/PHP applications, providing configuration and Twig helpers to embed tracking containers, manage consent/privacy modes, and send consistent analytics events.
Symfony Bundle for Tag-Commander
Frequently asked questions about Tagcommander Bundle
- Can I use steamulo/tagcommander-bundle in a Laravel application?
- It is shipped as a Symfony bundle, so it targets Symfony's bundle registration, configuration tree and Twig helpers rather than Laravel's service providers and Blade. Some of the underlying PHP classes may be reusable in a Laravel app, but the documented integration path assumes Symfony. For Laravel you should expect to write your own service provider and Blade rendering, or evaluate a Laravel-native analytics package instead. Treat this as a Symfony-first package that needs adaptation before it is a Laravel-first dependency.
- How do I install steamulo/tagcommander-bundle with Composer?
- Install it with composer require steamulo/tagcommander-bundle and pin the exact version, for example 1.0.0, rather than a floating constraint. Resolve it in a scratch branch first and diff the lockfile so you can see exactly which transitive symfony and psr packages are added or bumped. In Symfony you then register the bundle in config/bundles.php; in Laravel you would need to register the services yourself. Avoid adopting on ^1.0 until you have reviewed the source diff between the last 0.x tag and 1.0.0.
- Does steamulo/tagcommander-bundle support Laravel 9, 10 or 11 and PHP 8?
- That cannot be confirmed from the available data, because no composer.json or require block was provided. The 1.0.0 release note only says it adds Symfony 6 and PHP 8 support, which is the same baseline Laravel 9 and 10 sit on, so it is plausible but unproven. Inspect the exact php and symfony constraints before committing, and validate composer resolution against your pinned Laravel versions in CI. Any service still on PHP 7.4 or Laravel 8 should be treated as a hard stop.
- What does the TagCommander bundle actually do for Commanders Act tracking?
- It integrates Commanders Act TagCommander into Symfony and PHP applications, providing configuration plus Twig helpers to embed tracking containers. It also covers consent and privacy modes so tag firing can be gated on user choices, and it helps emit consistent analytics events from your application. In practice it is glue code between your templates and the TagCommander JavaScript container, not an analytics backend itself.
- How do I render the TagCommander container in Blade views instead of Twig?
- The package's helpers are Twig functions, so they will not work in Blade without adaptation. The practical options are to expose the same container snippet through your own Blade component or directive, or to call the bundle's configuration values from a view composer and pass them to a Blade partial. Either way you are reimplementing the Twig helper's output, so budget a small amount of integration work and test that consent state is respected.
- Does version 1.0.0 contain breaking changes from the previous 0.x releases?
- The release note is a single line stating Symfony 6 support, with no changelog, upgrade guide or deprecation list, so breaking changes cannot be ruled out. A jump from 0.x to 1.0.0 conventionally signals the first stable API commitment, and it may also carry undocumented changes. Read the source diff between the last 0.x tag and 1.0.0 rather than relying on the release note. Pin 1.0.0 explicitly and canary one low-traffic service before widening adoption.
- Does version 1.0.0 still support Symfony 5 and PHP 7.4, or were those dropped?
- Unknown from the available information. The note says the release adds Symfony 6 and PHP 8 compatibility, which is additive wording, but it does not state whether older Symfony and PHP lines were retained or removed. That detail decides whether one tagged version serves your whole estate or you need a per-service version fork. Check the require block in composer.json before planning a fleet-wide upgrade.
- Is steamulo/tagcommander-bundle tested, and is there a CI matrix?
- No test matrix is visible in the provided data, so PHP 8 compatibility claims should be verified rather than assumed. Look for a CI configuration covering PHP 8.0, 8.1 and 8.2 plus the Symfony versions you run. If coverage is missing or narrow, run your own smoke tests against the tagged release before adopting. Untested deprecation notices can surface as log noise, or as runtime failures under strict error handling.
- What are the production concerns when using this bundle for tracking and consent?
- Watch for per-request bootstrapping, service container work on every request, or synchronous I/O, since those patterns bite under load and are invisible in a one-line release note. Confirm that consent and privacy modes genuinely gate tag firing, because that has legal as well as analytics consequences. Also check that the emitted event payloads stay consistent across environments so your reporting does not silently drift. Load-test a staging instance before going live.
- Is steamulo/tagcommander-bundle actively maintained, and what are the alternatives?
- Maintainer count, issue response time and release cadence are not established here, and a 1.0.0 tag implies API stability rather than support responsiveness. Confirm commit recency, open issue backlog and license before making it a dependency of record, and consider vendoring or forking if it becomes load-bearing. Alternatives include a Laravel-native tag manager or analytics package, or a small in-house Blade component that renders the TagCommander container and reads consent from your own configuration.
Weaver
How can I help you explore Laravel packages today?