Ezehstart Laravel Package

Getting Started

ezehstart 2.2.1 is a non-breaking follow-up to 2.2.0 — no migrations, no renames. First step after upgrading is to rebuild the config cache so the new payments log channel is registered:

composer update
php artisan config:cache   # required if you cache config

Then look in three places:

1. config/logging.php — the new payments channel is registered here. Confirm it's present and that its path resolves to storage/logs/payments.log. If you have a custom logging config that overrides the package's stack, diff it against the published version.
2. the admin Logs screen — payments now appears as a selectable source alongside the main log. This is the fastest way to confirm the channel is wired up without tailing files.
3. your payment paths — checkout reconciliation and the hourly subscription sync now emit structured entries (record id, vendor, error) instead of only incrementing a command error count.

First use case: run the reconcile sweep and hourly sync in a staging environment and watch storage/logs/payments.log fill. Before 2.2.1 those failures were only visible as a number in the command output; now you get a line per failure you can actually act on.

Implementation Patterns

Reading the payments log. Use the channel explicitly rather than the default:

Log::channel('payments')->info('...');

For your own payment code, prefer writing to the same channel so the admin Logs screen shows one coherent stream. Keep the message shape consistent with the package's own entries — record id, vendor, error — so grep and the log viewer stay useful.

Wiring the log into alerting. Anything you previously tailed from laravel.log for payment problems needs to be re-pointed. The webhook-retRY-exhaustion, payment-trace-write-failure, and production signature-check-disabled warning all moved or were added to payments.log. If you ship logs to an external aggregator, add storage/logs/payments.log as a source; otherwise these failures become silent.

Monitoring the sweeps. The reconcile sweep and hourly sync now log each unverifiable checkout and each subscription that fails to refresh. Treat a non-zero count as a summary and the log lines as the detail — alert on count, triage from the log. This is the single biggest day-to-day win in the release.

Public pages are now full page loads. The home page, blog, site header, and two-factor challenge no longer use wire:navigate. Anything you attached to Livewire's navigation events on those pages will stop firing:

• livewire:navigated listeners for analytics pageviews, scroll restoration, or re-initialising third-party widgets
• Alpine state you expected to persist across internal navigation
• assumptions that the document <head> never reloads (script tags re-execute now)

Move those hooks to DOMContentLoaded / a plain load listener for public pages, and leave the Livewire navigation listeners for admin and member dashboard code where the behaviour is unchanged.

Two-factor challenge. It now loads as a full page. If you had custom redirect logic or JS that assumed a soft navigation into the challenge, re-test the 2FA flow end to end — especially any "return to intended URL" handling that relied on client-side state surviving navigation.

Extending. The admin Logs screen picking up payments for free means you don't need to build a payment-specific viewer. If you add your own channels later, register them the same way the package does and they should surface there too.

Gotchas and Tips

• Skipping config:cache is the one real trap. The channel registration lives in config; with a stale cache the payments channel won't exist, the admin Logs screen won't list it, and you may see a Log [payments] is not defined style error the first time a payment fails. Rebuild after every deploy that touches config.
• Failures that used to be invisible are now visible — expect noise on first deploy. The first reconcile sweep after upgrading may surface a backlog of unverifiable checkouts and stale subscriptions that were previously just error counts. Triage before pointing alerts at the new file.
• Two log destinations changed. A payment trace that can't be written and the production "signature checks disabled" warning previously went to Laravel's main log and now go to payments.log. Any alert rule or dashboard keyed on those strings in laravel.log will go quiet without warning.
• Don't re-add wire:navigate to public pages casually. The change looks cosmetic but is deliberate; reinstating it will bring back whatever problem prompted the revert, and your JS lifecycle assumptions will silently change again.
• Log rotation. A dedicated payments log means a second file to rotate and ship. If you use daily on the main channel, check the new channel's driver matches your retention policy.
• Admin and member dashboards are unchanged. Don't refactor their navigation — the wire:navigate behaviour still applies there, so keep those event listeners where they are. Splitting the two behaviours in your JS is the cleanest approach: full-load initialisation for public, Livewire navigation hooks for authenticated areas.
• Debugging tip. The log entries carry the record id, so you can jump straight from a line to the failing checkout or subscription instead of hunting the vendor API. Make that id copyable in the admin Logs screen if you customise it — it's the fastest path from symptom to record.