- Is minishlink/web-push-bundle compatible with Laravel?
- No. It is a Symfony bundle built on Symfony's DI extension and framework-bundle configuration, so it will not install or boot inside a Laravel application. The actual push functionality lives in the framework-agnostic minishlink/web-push library, which you can wire into Laravel in roughly 40 lines of a service provider.
- How do I send Web Push notifications from Laravel without the bundle?
- Require minishlink/web-push with Composer and bind a configured WebPush instance as a singleton in a service provider. Pass the VAPID subject, public key and private key from config/services.php backed by environment variables. Then inject that instance into a job or service, call queueNotification for each browser PushSubscription endpoint, and flush the batch.
- What does this bundle actually register in the Symfony container?
- It provides a DI extension plus service definitions for Minishlink\WebPush\WebPush, built from YAML under config/packages and populated with your VAPID credentials and defaults. That configuration shape is worth copying into Laravel config, but the package itself is not a dependency you need.
- How are VAPID keys configured with this bundle?
- Through bundle configuration you supply a subject plus the public and private VAPID keys, which are then injected into the WebPush service. In Laravel the equivalent is putting them in .env and config/services.php rather than in application code. Treat the private key as a long-lived secret, because rotating or losing it silently invalidates every existing subscription.
- Do I need symfony/framework-bundle to use this package?
- Yes, the bundle depends on Symfony's framework and dependency injection components. Pulling symfony/framework-bundle into a Laravel app just to satisfy one wrapper is not a reasonable trade when the upstream library already does all the work. Use the library directly instead.
- What changed in web-push-bundle v7.0.0?
- It follows minishlink/web-push v11.0.0, and the release notes point you to the upstream migration guide and a page on customizing the HTTP client rather than listing changes. Before upgrading, verify the minimum PHP version, whether legacy aesgcm support was dropped, whether constructor and queueNotification/send/flush signatures changed, and whether VAPID key loading changed.
- Why does this bundle's major version track web-push-php's major version?
- Because it is a thin wrapper around the library's API, so every web-push-php major release forces a bundle major release. Adopting the bundle therefore adds another upgrade axis, plus eventual Symfony major churn, without adding any capability you cannot get from the library itself.
- How do I test Web Push sending in a Laravel application?
- Bind a fake implementation of the WebPush client in the container and assert that notifications were queued with the expected endpoint, payload, TTL and VAPID options. Keep real encryption and HTTP tests in a small integration suite pinned to one library version, since the crypto and transport layer is where breakage hides.
- How should I handle 404 and 410 responses from push services?
- Push services return 404 or 410 when an endpoint has expired or the user has unsubscribed, so delete that subscription record and stop retrying it. Treat 429 and 5xx responses as transient and retry with backoff instead of pruning the subscription.
- What should I know about payload size, TTL and Urgency?
- Payloads must stay small and are encrypted with aes128gcm before being POSTed to the browser endpoint. TTL and Urgency are per-notification hints whose behavior varies between browsers and push services, so test them per endpoint family rather than assuming uniform support.