Login Notify Laravel Package

Getting Started

• Install the package with Composer and publish its config (check the README for the exact vendor:publish tag). The config controls the cookie name/lifetime, the location resolver, and the new Cookie Monster cleanup.
• Register the package’s middleware (globally in app/Http/Kernel.php or on a route group). This is what remembers location in a cookie and triggers cookie maintenance.
• First use case: protect a route group with the middleware, then read the remembered location via the package’s facade/helper in a controller or Blade view. For local development, v1.1.0 removes the hard failure when no location can be resolved—but you should still define a fallback location in config so your UI has something to render.
• If you were previously working around local-development errors by mocking geolocation or disabling middleware, you can remove that workaround after upgrading.

Implementation Patterns

• Middleware-first integration. Attach the middleware to the routes that need location awareness (e.g. storefront, pricing, content localisation). The middleware resolves the location, stores it in a cookie, and on subsequent requests reads the cookie before doing another lookup.
• Cookie Monster cleanup. v1.1.0 adds automatic removal of expired remembered cookies to prevent browser cookie build-up. Enable it in config and either let the middleware prune on each request or schedule the provided command:

  // app/Console/Kernel.php
  $schedule->command('cookie-monster:clean')->daily();
  

  If the package prunes automatically, keep the schedule as a belt-and-braces option for low-traffic apps where middleware may not run often.
• Fallback handling. Because the location-not-found bug is fixed, local development no longer throws. Still design your code to handle a null location:

  $location = Location::current(); // consult README for exact facade/helper name
  $currency = $location?->currency ?? config('app.default_currency');
  

• Testing. Bind a fake location resolver in your test service container, or use withoutMiddleware for tests that don’t care about location. Add a test that simulates “location not found” to lock in the v1.1.0 behaviour. Assert that cookies are set/cleared as expected.
• View integration. Use a view composer to inject the remembered location into layouts, so you don’t repeatedly call the resolver in Blade templates.

Gotchas and Tips

• Cookie build-up. Before v1.1.0, expired remembered cookies could accumulate in the browser. After upgrading, confirm the Cookie Monster is enabled in config. You can verify in browser devtools that old cookies are being removed; if not, check that the middleware or scheduled command is actually running.
• Location not found. The v1.1.0 fix means local development no longer errors, but the resolver may return null. Treat null as a first-class state and always provide a config fallback. Don’t assume the bug fix means a location will always be available.
• Config quirks. Cookie name collisions with other packages are common. Set a unique cookie name and review secure, httponly, and same_site settings, especially if you serve the app over both HTTP and HTTPS in local development.
• Debugging. Log the resolved location and whether the cookie was read or written. Use php artisan route:list to confirm the middleware is attached where you expect. Clear cookies between test runs to avoid stale location data.
• Extension points. The package likely lets you swap the location resolver and customise the cookie jar. If you need to support a custom geolocation provider, bind your own resolver implementation rather than editing vendor code. Listen for any package events around location resolution if you need to hook in analytics or caching.