- Can I install exs/lander-tracking-house-bundle in a Laravel application?
- No. This is a Symfony bundle: it registers through AppKernel::registerBundles, configures via YAML under exs_lander_tracking_house, uses DI service tags (exs_tracking.parameter_extracter, exs_tracking.parameter_formatter) and ships a Twig extension. Laravel gets no service provider, no publishable config, no middleware and no Blade integration from it, so a Composer require will not produce a working setup. Treat the repository as a specification to port rather than a production dependency.
- What does the exs/lander-tracking-house-bundle actually do?
- It scans incoming requests for tracking parameters, persists them in cookies, and appends them to any URL through the appendTracking Twig filter or the getTracking function. The flow is a clean four-stage pipeline: request-scoped extraction, cookie persistence, formatter services, then template-time URL decoration. Built-in extractors cover cmp, cup, cu, cuvp, cuv, exid, product_id, uvp, uv and visit, and six formatters plus a placeholder replacer handle the outbound query string.
- How would I implement the same tracking behavior in Laravel?
- Port the pattern, not the code. Build a TrackParameters middleware that reads query and cookie values and queues a signed cookie on the response, a TrackingFormatter service with named formatters mirroring cu, cuv, cup, cuvp, uv and uvp, and a config file for defaults and formatter bindings. Expose it to views with a Blade directive or a Url::withTracking() helper, plus placeholder replacement for tokens like {cmp}, {exid} and {visit}. The functional surface is only a few hundred lines, so a single engineer can reproduce it in days.
- Which tracking parameters and compound formats are supported out of the box?
- The bundle ships roughly ten extractors: cmp, cup, cu, cuvp, cuv, exid, product_id, uvp, uv and visit. Several accept tilde-delimited compound strings, for example cup contains {cmp}~{exid}~{product_id} and cu contains {cmp}~{exid}, which are split into the internal parameters the formatters consume. That compound format is effectively the contract you must preserve when reimplementing, so inventory every parameter name and delimiter actually in use before you rewrite anything.
- How do I configure default values for cmp, exid and visit?
- In Symfony the defaults live in YAML under exs_lander_tracking_house, with keys default_cmp, default_exid (shipped as 'exid') and default_visit (shipped as 1). Extractors fall back to those values when the parameter is absent from both the request and the cookies. In a Laravel port, move the same three defaults into a config file backed by environment variables so marketing can change them without a deploy.
- Does this bundle support modern PHP, Symfony or Laravel versions?
- Unknown, and that is a real risk. The composer.json version constraints are not documented, and the AppKernel registration plus Travis CI badge point to a Symfony 2/3-era codebase. Even in a Symfony shop you should verify the PHP and Symfony version pins before assuming it installs cleanly. Under Laravel the question is moot because there is no architectural fit at all.
- Is this package actively maintained and safe to depend on?
- The signals are weak: zero stars, zero dependents, a long-deprecated Travis CI build, and documentation that contradicts itself (appendParameter versus appendTracking, a misconfigured priotirty tag key). That is evidence of low ongoing stewardship rather than a nitpick. Before forking, check whether an existing analytics or CDP platform already solves cross-domain attribution for you, because maintaining your own copy has an ongoing cost.
- Does it handle cookie consent and GDPR or ePrivacy requirements?
- No. The README describes writing tracking cookies with no mention of consent, cookie lifetime, Secure, HttpOnly or SameSite flags, or PII handling. For an EU or UK audience that is a compliance gap, not a detail, and it is the kind of decision that needs a named owner in legal or marketing. Any Laravel port should add a consent gate, explicit cookie lifetimes and hardened cookie attributes from day one.
- Can visitors spoof or inject tracking parameters through this bundle?
- Yes. Inbound query and cookie values become outbound query strings with no signing, allowlisting or validation, so anyone can append cmp= themselves and the value persists for the cookie lifetime. Attribution is therefore trivially forgeable, and reflected values flow into href attributes, where safety depends entirely on the template layer escaping correctly. A hardened port should sign the stored cookie, allowlist known parameter names and validate value formats before they reach a URL.
- How do I test a tracking parameter pipeline end to end?
- Write feature tests that hit routes with tracking query strings, assert the expected Set-Cookie header, then make a follow-up request with that cookie and assert the rendered URLs contain the formatted parameters. Add cases for compound values like cup, for default fallbacks when cmp or visit are missing, and for placeholder replacement of {cmp}, {exid} and {visit}. Watch for the silent failure mode above all: attribution quietly disappearing is the hardest bug to spot in a marketing funnel, so assert on links rather than trusting manual checks.