Pinkfire Bundle Laravel Package

Getting Started

First, a reality check that matters more than any setup step: this is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/pinkfire.php. If you are on Laravel, there is nothing to install — the rest of this section assumes a legacy Symfony 2.x application, which is the only place this bundle ever worked.

Minimal steps on a Symfony 2.x app:

1. composer require pinkfire/pinkfire-bundle (expect this to fail on modern PHP/Symfony; see Gotchas).
2. Register the bundle in app/AppKernel.php — typically new Pinkfire\PinkfireBundle\PinkfireBundle() — inside the dev/staging if blocks only, never unconditionally.
3. Add the bundle config (usually an API key plus an endpoint) to app/config/config_dev.yml. Check DependencyInjection/Configuration.php first; the exact key names in the README drift from the code in bundles this old.
4. Clear the cache and hit a page.

Where to look first, in order:

• README.md for the intended wiring.
• DependencyInjection/Configuration.php — the authoritative list of config keys, not the docs.
• Resources/config/services.yml — the service ID of the client (something like pinkfire.client), which is the single object everything else hangs off.
• The event listener / data collector class, which is what actually does the day-to-day work.

The first real use case is narrow: send a per-request profile payload from a shared dev or staging environment to a hosted viewer, so a teammate can inspect a request without SSHing into your box. That was the entire value proposition — a remote, shareable profiler. If that isn't your problem, you don't need this bundle; you need the Symfony profiler.

Implementation Patterns

Automatic per-request profiling. The bundle's normal mode is a kernel event listener that serializes request/timing/query data and POSTs it at the end of the response. Turn this on only for the environments where you want it, via config_dev.yml / config_staging.yml. Do not enable it in prod or test — in test it will turn every functional test into an outbound HTTP call.

Manual instrumentation. The useful pattern is injecting the client service and bracketing a hot path:

$pinkfire->start('reindex');
// ... work ...
$pinkfire->stop('reindex');

This is how you profile a console command or a worker that never touches the kernel listener. Wrap it in a try/finally so a thrown exception doesn't leave an open timer.

Custom collectors. If the bundle exposes a collector tag (it mirrors Symfony's data-collector convention), register your own class with that tag to attach domain data — cache hit ratios, queue depth, third-party API timings — to the same payload. This is the only way to get anything out of it that the Symfony profiler doesn't already give you, and it's the strongest argument for a fork.

Environment-scoped configuration. The pattern that keeps this from becoming an incident:

# config_dev.yml
pinkfire:
  enabled: true
  api_key: "%pinkfire_key%"

with the key sourced from parameters.yml/env, never committed. In config_prod.yml, either omit the block entirely or set enabled: false.

Integration tip — run it beside the local profiler, not instead of it. Keep Symfony's web debug toolbar for interactive debugging; use Pinkfire only for the "someone else's request, on another machine" case. Trying to replace the profiler with a network round-trip is a strict downgrade.

If you're on Laravel anyway: the only viable pattern is a thin adapter — bind the bundle's client class in a service provider, add a terminable middleware that starts/stops it around the request, and let it fail silently. That is a day of work to recreate a feature laravel/telescope already ships.

Gotchas and Tips

• Abandoned and version-locked. This targets the Symfony 2.0–2.3 era. Composer will refuse to resolve it against Symfony 6/7 or PHP 8 on platform requirements. Getting it running means forking and pinning, at which point you are maintaining it.
• The backend is almost certainly gone. Pinkfire was a hosted service; the endpoint no longer resolves. A misconfigured or dead endpoint means every request blocks on a connect timeout. If you fork it, set an aggressive timeout (1–2s), disable retries, and make the send fire-and-forget after the response is flushed.
• Silent failure by design. A bad API key or unreachable host typically drops the payload without an exception — you'll see nothing in the viewer and nothing in the logs. Debug by logging the serialized payload locally before the send, and curl the endpoint by hand with the same key.
• Privacy and payload size. Request payloads include headers, cookies, session IDs, and SQL with bound parameters. On a shared staging box feeding a third-party endpoint, that's a data-exfiltration path. Strip Cookie/Authorization and parameterize before it leaves the process — or don't send it.
• Config key drift. Docs and Configuration.php disagree in bundles this old. Trust the code; run app/console config:dump-reference pinkfire to see what's actually accepted.
• Extension point worth knowing: the client service is the seam. Decorate or replace it with an implementation that writes JSON lines to a local file, and you keep the instrumentation call sites while dropping the dead network dependency — then ship those files to Blackfire, Tideways, XHProf, or spatie/laravel-ray/Clockwork equivalents.
• Zero dependents is the signal. No downstream packages and no maintainer activity means no one is testing this against current framework versions. Budget for it being broken in ways the README won't mention, and treat every step above as "verify before relying."

Bottom line for day-to-day leverage: for a modern Laravel or Symfony codebase, this is zero — the honest assessment is that you should use the Symfony Profiler, Laravel Telescope, or Blackfire/Tideways instead. The bundle is worth reading only as a reference for how to structure a request-level data collector and a decorator-based transport, which is a pattern you can reimplement in an afternoon without the dead service dependency.