Warriorfolio Laravel Package

Getting Started

This release is mostly a maintenance and test-coverage pass, so the first thing to do is update and run the test suite rather than reading changelogs line by line:

composer update
php artisan migrate
php artisan test

Start by looking at the feature tests added for Mail, Project, Settings, application routes, and access control. They are now the most reliable documentation of expected behaviour and will show you the intended request/response flows faster than exploring the source.

A sensible first use case is to seed a local environment and exercise the main routes:

touch database/database.sqlite
php artisan migrate:fresh --seed
php artisan serve

Then log in with a seeded user, open the project and settings screens, and trigger a mail-sending flow. The HeroSectionSeeder now reflects version 2.2.3, which is useful for confirming you are running the current release.

Implementation Patterns

• Treat the feature tests as integration contracts. The new tests around routes and access control are the best place to copy middleware, guard, and policy expectations from when adding your own routes.
• Extend rather than edit seeders. HeroSectionSeeder is version-stamped. If you customise seeded content, add your own seeder or override published data instead of editing the package seeder, otherwise the next release will overwrite your bumper/title changes.
• Mail flows: use Mail::fake() in your own tests, mirroring the package's Mail feature tests. Assert on mailable classes and queued mail rather than rendered HTML.
• Settings: centralise reads/writes behind the package's settings service or repository rather than querying the settings table directly. This keeps caching and serialisation behaviour consistent.
• Projects: use route-model binding and the existing access-control middleware for project routes. If you add nested resources, follow the same authorisation pattern the feature tests demonstrate.
• Local SQLite: database/database.sqlite is now ignored. Keep a local file for day-to-day work and let the test suite manage its own database; do not commit the file.
• Upgrade workflow: run composer update, then php artisan test, then php artisan migrate in staging. The dependency bumps in this release are minor, but the test suite is your safety net.

Gotchas and Tips

• Do not commit database/database.sqlite. It is now intentionally ignored. If you previously tracked it, remove it from Git history or at least from the index with git rm --cached database/database.sqlite.
• Test database seeding changed. The obsolete SQLite test database was removed and seeding adjusted. If your own tests relied on a pre-built SQLite fixture, switch to RefreshDatabase/DatabaseMigrations and seed explicitly.
• Seeder version strings are cosmetic but useful. HeroSectionSeeder now says 2.2.3. Do not assert on that string in application tests unless you want to update tests every release.
• Access-control tests are the quickest debugging aid. If a route unexpectedly returns 403 or redirects, compare your middleware stack against the new route/access-control feature tests before digging into policies.
• Mail testing pitfalls: queued mailables require Mail::assertQueued() rather than assertSent(). Check whether the package mailable implements ShouldQueue before writing assertions.
• Settings caching: if settings changes do not appear immediately, check whether the package caches settings and whether your write path clears that cache. The Settings feature tests should reveal the expected invalidation behaviour.
• Dependency updates are minor but not risk-free. Re-run the full suite after composer update, particularly the Mail tests, since mailer/library patches can change serialisation.
• Extension points: prefer publishing config and migrations over modifying vendor files, and hook into package events or service bindings for custom behaviour. This keeps future patch releases such as 2.2.3 low-friction.