Filament Tournament League Administration Laravel Package

Getting Started

1. Require the package and publish its assets/migrations:

   composer require maggomann/filament-tournament-league-administration
   php artisan vendor:publish --tag="filament-tournament-league-administration-migrations"
   php artisan migrate
   

2. Register the plugin in your Filament panel provider:

   ->plugin(TournamentLeagueAdministrationPlugin::make())
   

3. Look first at src/Filament/Resources and the package config. The TeamResource is the primary entry point for v0.6.0 because team forms now include optional address management.
4. First use case: open the Filament admin panel, create a league/tournament, add teams (address optional), and manage related matches/players. Day-to-day work mostly happens through the provided Filament resources rather than custom controllers.

Implementation Patterns

• Use the package resources as CRUD foundations. Extend TeamResource, TournamentResource, etc. in your app when you need custom fields, actions, or navigation grouping.
• Extend team forms for address use cases. v0.6.0 adds optional address fields to team forms. Add or adjust address fields by overriding the resource form schema or using a form extension pattern, and keep fields nullable so teams without addresses still save.
• Conditionally show address management. If addresses are only relevant for some clubs, use Filament’s ->visible() / ->hidden() callbacks based on team type or a toggle, rather than creating separate resources.
• Integrate authorization through policies. Register policies for the package models so Filament actions and resource access follow your app’s roles. This is usually the difference between a working demo and a production admin panel.
• Use relation managers for league workflows. Teams, players, matches, and standings are naturally relational; manage them through relation managers or custom actions instead of separate CRUD screens.
• Seed realistic data for local work. Create leagues, teams with and without addresses, and fixtures. This catches null-address edge cases introduced by v0.6.0 early.
• Customize via published config and resource overrides. Prefer extending package resources over editing vendor files so upgrades remain straightforward.

Gotchas and Tips

• Address fields are optional — treat them as nullable end-to-end. Ensure migrations, model casts, validation, and form components all accept null. Existing teams will not have address data after upgrading.
• Publish migrations before migrating. Running migrations without publishing the package migrations can leave you without the expected tables or with conflicting schema assumptions.
• Plugin registration is required. If resources do not appear, check that the plugin is registered on the correct Filament panel and that the panel is not cached.
• Clear Filament/Laravel caches after config or form changes: php artisan optimize:clear and, where relevant, php artisan filament:clear-cached-components.
• Avoid duplicating form fields when extending team forms. Override the resource form method or use schema composition carefully; duplicate field names cause silent validation and state issues.
• Check Filament version compatibility after upgrading. Filament’s form/table APIs change between major versions; pin compatible versions in composer.json.
• Authorization failures often look like missing resources. If a resource returns 403 or is hidden, inspect policies and canViewAny/canCreate methods before debugging the package itself.
• Use php artisan route:list and Filament’s panel inspection commands to confirm resource routes are registered when pages are missing.
• Address display in tables may need adjustment. If you add address columns or infolists, guard against null relations/attributes to avoid rendering errors for teams without addresses.