- Can I use sly/pushover-bundle in a Laravel application?
- No. It is a Symfony2 bundle built around AppKernel registration, DI container extensions, and YAML/XML service definitions, and Laravel has no concept of bundles, so the registration hook never executes and the services are never wired. Laravel expects a service provider, a publishable config file, a facade, and a queueable notification channel. At best you can read the bundle's client class as a reference for the Pushover API call shape.
- How do I install and configure sly/pushover-bundle?
- You would run composer require sly/pushover-bundle, register the bundle in your Symfony AppKernel, and set your Pushover application token plus recipient user or group keys in config.yml. That workflow only exists in Symfony 2.x. Under Laravel there is nothing to register, so installation accomplishes nothing beyond adding an incompatible dependency tree.
- Is sly/pushover-bundle still maintained?
- There are no meaningful maintenance signals. Symfony 2 reached end of life in 2018, with 2.8 following in November 2019, and the repository shows roughly 8 stars, zero dependents, and a low package score. The repository name, Ph3nol/PushOverBundle, also does not cleanly match the Composer package name sly/pushover-bundle, which is a provenance warning rather than a cosmetic detail.
- What is the Laravel-native alternative for sending Pushover notifications?
- Evaluate laravel-notification-channels/pushover first, checking release recency, open issues, and maintainer activity before committing. The fallback is a small client of your own: an Http::withToken call or a Guzzle wrapper behind a PushoverNotifier interface, bound in a service provider. Wrapping that in a notification channel that implements send() lets it compose with the Notifiable trait and the queue system.
- Which Laravel and PHP versions does sly/pushover-bundle support?
- Effectively none of the modern ones. The bundle pins symfony/* at 2.x with PHP 5.x/7.x-era requirements, while current Laravel sits on Symfony 6/7 components and PHP 8.1 or newer, so Composer will report hard conflicts rather than soft warnings. Even with --ignore-platform-reqs the bundle still cannot boot inside Laravel.
- Does the bundle support Pushover priority, retry/expire, sound, and receipt polling?
- The overview lists title, message, priority, and sound, but advanced semantics such as emergency priority with retry and expire parameters, device targeting, and receipt polling for acknowledgement are almost certainly not exposed. You would have to extend or rebuild the client for those anyway. Since you are rebuilding regardless, implement them directly in your own Laravel channel.
- How do I send a Pushover push notification from Laravel without this bundle?
- Post to https://api.pushover.net/1/messages.json with your application token, the recipient user or group key, and the message, adding optional title, priority, sound, and device fields as needed. That is roughly 50 to 100 lines including error handling for the response codes. Put it behind an interface bound as a singleton in a service provider, and call it from a notification channel so queuing and retries come for free.
- How should I test Pushover notifications in a Laravel application?
- Use Http::fake() to intercept outbound requests and assert the endpoint, token, user key, and payload fields you expect. If you abstracted the client behind an interface, bind a fake implementation in the container and assert the notifier was called instead of asserting HTTP details. Both approaches keep tests fast and avoid hitting the live Pushover API.
- Is it risky to depend on unmaintained code that handles API credentials?
- Yes, and the risk here is supply chain rather than functionality. Unmaintained code that transmits an application token has no security-patch path and no community to catch defects, and the zero-dependents count means nobody else is watching either. Treat it as a review item even at this small size and keep credentials in environment variables regardless of the client you choose.
- Can I refactor or migrate sly/pushover-bundle into a Laravel package?
- You can, but the effort is equivalent to writing the package from scratch. Extract the endpoint, required fields, error handling, and response codes from the bundle's client class, then reimplement them as a service provider with a bound singleton and a notification channel. All the Symfony scaffolding gets discarded, leaving only the thin HTTP call you could have written in an afternoon.