- Can I install micronax/prowl-bundle in a Laravel application?
- No. micronax/prowl-bundle is a Symfony2 bundle that ships a Bundle subclass and DI service definitions intended for AppKernel::registerBundles(), and Laravel has no bundle registry or shared Symfony DI container in that form. Composer also pins symfony/framework-bundle to the 2.x line, which conflicts with the Symfony 6/7 components modern Laravel requires. The realistic path is to read the roughly 50 lines of intent and implement a Laravel-native notification channel instead.
- Does micronax/prowl-bundle support Laravel 10 or Laravel 11?
- No. The bundle targets the Symfony 2 era and has no service provider, facade, publishable config, or extra.laravel block. Laravel 10 and 11 depend on Symfony 6/7 components, so Composer will not resolve both dependency trees in one application. Forcing it with --ignore-platform-reqs would drag an unmaintained Symfony 2 container into your runtime, which is not acceptable for production.
- How do I install micronax/prowl-bundle with Composer?
- For a Symfony2 application you would run composer require micronax/prowl-bundle and register the bundle in AppKernel. There is no supported Laravel installation path because the framework-bundle pin blocks resolution against current Laravel versions. Avoid --ignore-platform-reqs and replace shims, since they pull an abandoned Symfony 2 container into the same process as Laravel's own.
- Does micronax/prowl-bundle include a service provider or publishable config for Laravel?
- No. It provides Symfony DI service definitions and bundle configuration, not a Laravel service provider, facade, or vendor:publish config file. The reusable parts are only the configuration keys, the API call shape, and the response codes. In Laravel you would recreate those as config/prowl.php with api_url, api_key, application, priority default, timeout, and queue settings.
- How do I send a Prowl push notification from Laravel?
- Use Laravel's Http facade to POST form data to https://api.prowlapp.com/publicapi/add with apikey, application, event, description, and priority fields. Wrap that in a notification channel class whose send() method returns via() key prowl. Use Http::asForm()->timeout(5)->retry(3, 200, throw: false)->post(...) rather than curl, and log the Prowl response codes.
- Is micronax/prowl-bundle maintained and safe for production?
- It is effectively abandoned: eight stars, zero dependents, no release cadence, no PHP 8.x assurance, and no security response commitment. The Symfony 2 pins lock your application out of current framework and PHP versions. Separately, Prowl itself is a legacy one-person push service with an aging iOS client and no meaningful SLA, so any product dependency on it is a strategic exposure regardless of wrapper quality.
- Why do Prowl notifications fail silently, and how do I detect that?
- The Prowl API returns HTTP 200 with an error body for several failure classes, including invalid key, unapproved application, unregistered device, and rate limiting. A naive integration loses those notifications without alerting anyone. Map Prowl's codes explicitly: 200 success, 400 bad request, 401 invalid key, 406 not approved, 409 not registered, and 500/503 server or rate limit, then emit log events and a metric for each.
- What are the best Laravel alternatives to micronax/prowl-bundle?
- Build an internal Laravel notification channel or a package such as acme/laravel-prowl with config/prowl.php and a ProwlChannel class implementing Laravel's notification contract. If you are choosing a channel rather than a wrapper, evaluate Pushover, ntfy, direct APNs, or an in-app inbox as migration targets. Put the channel behind an interface and a config-driven selector so Prowl can be swapped without touching call sites.
- Can I queue Prowl notifications so web requests are not blocked?
- Yes, and you should. Implement ShouldQueue on the notification or dispatch a dedicated job so the single POST to api.prowlapp.com/publicapi/add never runs inline in a web request. Pair that with a five-second timeout and limited retries to keep third-party latency out of your response path. This is a half-day of work and eliminates the entire dependency-graph problem.
- How do I test a Prowl notification channel in Laravel?
- Use Http::fake() to assert the POST to api.prowlapp.com and verify the apikey, application, event, description, and priority form fields. Cover success, invalid key, not approved, rate-limit, and timeout branches so silent failures are caught in CI. Use Notification::fake() or Queue::fake() to confirm the channel dispatches without blocking requests.