Sms Sender Bundle Laravel Package

Getting Started

The first thing to internalize: this is a Symfony2 bundle, deprecated since 2014, and it is a thin DI/config wrapper around the standalone kphoen/sms-sender library. It does nothing you cannot do directly with the library, so the real decision is whether you need the bundle at all. In a Laravel codebase the answer is almost always no — pull the underlying library (or a maintained provider SDK) and skip the bundle entirely. Only reach for the bundle if you are maintaining a legacy Symfony 2.x application that already has it in composer.json.

Minimal steps if you do need it:

1. composer require kphoen/sms-sender-bundle — expect the resolver to fight you. The package predates PHP 7 type hints and Symfony 3, so pin your PHP platform config and confirm the Symfony FrameworkBundle version constraint before assuming it installs.
2. Register new KPhoen\SmsSenderBundle\KPhoenSmsSenderBundle() in AppKernel::registerBundles().
3. Add the kphoen_sms_sender: block to app/config/config.yml with your provider name and credentials, and move the secrets into parameters.yml / environment variables immediately.
4. Inject the sender service into one controller and send a single message to your own phone.

Where to look first, in this order:

• DependencyInjection/Configuration.php — the authoritative list of config keys. The README is from 2014 and the config shape drifted across provider versions; trust the tree builder over the docs.
• Resources/config/services.xml — tells you the exact service ID to inject (typically the bundle ID, e.g. kphoen_sms_sender, aliased to the library's sender interface). Confirm with php app/console debug:container kphoen_sms_sender.
• The underlying library's ProviderInterface — this is the seam you'll mock in tests and the contract a custom provider must satisfy.

First use case: wire it to a single transactional event — an order confirmation or a password-reset OTP — behind your own SmsNotifier service, not directly in a controller. That wrapper is what makes the deprecation survivable: when you swap providers or replace the library, only one class changes.

Implementation Patterns

Wrap, don't inject the bundle service everywhere. Create an application-owned App\Services\SmsNotifier that takes the bundle's sender as a constructor dependency and exposes intent-revealing methods (sendOrderConfirmation($order), sendOtp($user, $code)). This keeps the abandoned API at the edge of your codebase, gives you one place to add logging, templating, and retry policy, and makes the eventual rip-and-replace a one-file diff.

Message construction stays boring. Build the recipient (normalize to E.164 yourself — the library does not reliably do it), the body from a template, and the optional sender/from value. Send, then branch on the returned result rather than assuming success; treat provider exceptions as a first-class outcome, not an edge case.

Move sending off the request cycle. SMS providers are synchronous HTTP calls with p95 latencies that will occasionally blow your response budget. In Symfony, dispatch a domain event and handle it in a listener backed by a queue; in Laravel, the direct analogue is a queued job or a Notification channel. Either way, the controller should enqueue, not send.

Use a console command as your smoke test. A sms:test <number> command that resolves the sender from the container and sends one message is worth more than any unit test for confirming credentials and provider config on a new environment.

Testing: never let a test hit a real provider. Because the bundle just wires the library, mock the sender service in the container (Symfony 2.8-era getMockBuilder / prophesize) or bind a fake ProviderInterface implementation that records messages. In Laravel, bind a fake implementation of your own SmsNotifier interface — this is another argument for the wrapper.

Provider swapping is a config change if you stay within the providers the library supports, and a new class implementing ProviderInterface if you don't. Keep the provider selection in config, not in code, so a staging environment can point at a logging/null provider.

Gotchas and Tips

• Assume it is unmaintained. Last release October 2014, zero dependents. No PHP 7.4/8 support, no Symfony 3+ compatibility, no security patches. Do not put it on a new project; budget for replacing it if you inherit it.
• Provider APIs have moved on. Twilio and Nexmo (now Vonage) have both changed endpoints, auth models, and SDKs since 2014. The library's provider classes may hit endpoints that are deprecated or have different error semantics. Verify against the provider's current API before trusting error codes.
• No retry, backoff, or rate limiting. A failed send throws and that's it. Add retry deliberately — and be careful: retrying a send that actually succeeded but timed out produces a duplicate SMS and a duplicate charge. Prefer a queue with idempotency keys on your side.
• Secrets in config.yml are a classic Symfony2 leak. Use parameters.yml (gitignored) or environment variables; never commit account_sid/auth_token/API keys. Rotate anything that has been in a repo.
• Phone numbers are the #1 source of silent failures. Normalize to E.164 before the library sees them, and validate country codes at input time. Unicode bodies get split into multiple segments and multiply cost — enforce GSM-7 or account for concatenation.
• Don't log message bodies or phone numbers at info level. PII in app/logs/ is an audit finding. Log the provider, message ID, and a hashed recipient.
• Debugging the wiring: debug:container <service_id> to confirm the alias, then a --env=dev run with a null/log provider to isolate "is it config or is it the provider?" Swap credentials for a known-good pair before assuming code is at fault.
• Extension points are the library, not the bundle: implement ProviderInterface for a provider the library doesn't cover, then alias that class to the sender's provider argument via a small compiler pass or a service override. If you find yourself patching the bundle, stop — fork the service definition into your own services.xml and drop the dependency.