Wanna Speak Bundle Laravel Package

Getting Started

• Install (with caution): composer require yproximite/wanna-speak-bundle. The last release was September 2021 and the repo is archived, so check the composer.json constraints for supported PHP/Symfony versions before adding it to a modern app. If you are on Symfony 6/7 or PHP 8.2+, expect to fork or vendor the handful of source files.
• Register the bundle: in Symfony Flex, add it to config/bundles.php (Yproximite\WannaSpeakBundle\WannaSpeakBundle::class => ['all' => true]); on legacy skeletons, add it to app/AppKernel.php. Then expose credentials via config/packages/wanna_speak.yaml with values pulled from %env()% — typically an account ID / API key pair and sometimes a base URL or sandbox flag.
• Read the source first, not the README. With ~zero stars and no dependents, docs are thin. Start with src/DependencyInjection/Configuration.php to learn the exact config keys, then the main client class under src/ to see which API operations are actually implemented (usually a handful of methods wrapping HTTP calls to the WannaSpeak REST endpoints).
• First use case — credential smoke test. Autowire the client into a one-off console command or controller and call the simplest read endpoint (account info, list of numbers, or a test SMS). This confirms your key, region/base URL, and HTTP transport wiring before you build anything real around it.

Implementation Patterns

• Wrap it in your own gateway. Rather than injecting the bundle's client across your codebase, define a small CallTrackingGatewayInterface in your domain and implement it with the bundle client. This is the single highest-value pattern here: it isolates you from the archived dependency and lets you swap in a hand-rolled HTTP client later without touching controllers.
• Config per environment. Keep dev/sandbox credentials and the production account separate (wanna_speak config blocks keyed by %kernel.environment%), and store secrets as env vars so they never enter the repo or a compiled container dump.
• Typical day-to-day calls: sending transactional SMS, triggering/inspecting outbound calls, and pulling call records for dashboards. Map the API's raw array responses into your own DTOs immediately at the gateway boundary — the API's field naming is unlikely to match your domain and you don't want it leaking into templates.
• Push outbound calls off the request cycle. Wrap SMS/call dispatch in a Symfony Messenger message with a handler that calls the client, so a slow or failing WannaSpeak API never blocks a user-facing request. Add retries with backoff at the Messenger transport level.
• Decorate for logging and metrics. Register a decorator on the bundle's client service (same interface) that logs request duration and outcome. Much easier than editing vendor code and survives a fork.
• Testing: if the bundle uses a PSR-18/Guzzle/Symfony HttpClient under the hood, inject a mock or use MockHttpClient with recorded fixtures. Assert on your gateway's behavior (e.g. "an SMS message was dispatched"), not on the bundle's internals.

Gotchas and Tips

• Archived = frozen. No security patches, no PHP 8.x or Symfony 6/7 fixes, and transitive dependency conflicts are likely (old Guzzle, old symfony/http-client). If composer require fights you, copy the small src/ directory into your app as an internal service and drop the dependency — the surface area is usually tiny.
• HTTP 200 with an error body is common in telephony APIs. Don't trust the status code alone; inspect the payload for an error/status field and throw a domain exception on failure.
• Credentials may travel in query strings or form bodies. Redact them before anything hits your logs or an exception tracker, and be careful with Symfony's HTTP client profiler panel in dev.
• Phone number formatting is the classic bug. Normalize to E.164 before sending, and remember this is a French provider — international numbers may not be supported or may bill differently.
• Timeouts and rate limits. Set explicit connect/read timeouts on the underlying HTTP client; the default can hang a worker indefinitely. If you're batching sends, add throttling rather than letting the API return 429s.
• Verify the base URL and sandbox flag in every environment. A misconfigured prod deploy pointed at the sandbox (or vice versa) is silent and easy to miss; assert the expected host at container boot in a health check.
• Extension points to look for: the service ID of the client (override via services.yaml alias), the Configuration tree for adding keys, and any Guzzle/HttpClient service injection you can replace with a customized client (proxy, retry middleware, logging middleware). These are the cleanest ways to bend it without forking.
• Budget an exit plan. Given the archived status and zero dependents, treat this as a thin convenience wrapper you may need to reimplement. Keeping the gateway interface narrow from day one makes that a half-day job instead of a refactor.