Nova Calendar Tool Laravel Package

Getting Started

composer require czemu/nova-calendar-tool
php artisan vendor:publish --provider="Czemu\NovaCalendarTool\NovaCalendarToolServiceProvider"
php artisan migrate

Then register the tool in app/Providers/NovaServiceProvider.php:

public function tools()
{
    return [
        new \Czemu\NovaCalendarTool\NovaCalendarTool,
    ];
}

Where to look first: the published config/nova-calendar-tool.php (if present) and the migration that ships with the package — that schema tells you which columns the calendar actually reads (title/start/end or similar). Then skim the tool's src/ in vendor/czemu/nova-calendar-tool before trusting the README; the package is small and low-traffic, so the source is the real documentation.

First use case: point the tool at a single model, land an event on today's date, and confirm it renders before wiring up create/edit. A calendar that renders existing rows is the 10-minute smoke test that validates column names, timezone handling, and asset registration all at once.

Implementation Patterns

• Bind a model, don't fight the schema. The tool is fundamentally a read view over an events table with start/end/title-ish columns. Either accept its published table or add the required columns to your own model and bind it. Do the latter if events are already a first-class domain concept.
• Scope per user/team. Wrap the tool's query with a ->where('team_id', ...) or a model global scope. Without this, every authenticated Nova user sees every event — a common and embarrassing default.
• Rely on Nova policies for authorization. If the tool delegates create/update/delete to a Nova resource, your existing EventPolicy gates it for free. Verify the tool actually respects the policy rather than mutating directly.
• Categories/colors are typically a color column or a config map keyed off a type field. Prefer a column so per-event colors survive edits; use the config map only for fixed palettes.
• Link out to the Nova resource. Use Nova's index/detail URL helpers on click handlers so the calendar acts as a dashboard that hands off to the full CRUD UI rather than reimplementing it.
• Seed/import in bulk. The calendar is just a renderer; a scheduled command or importer that upserts events is the normal way to populate it from iCal, Google, or an internal source. Keep the calendar dumb.
• Multi-calendar, if needed, means multiple tool instances (or a filterable single instance). Don't expect true multi-model support from a 28-star package — if you need overlays, plan to fork the query layer.

Gotchas and Tips

• Last release was August 2021. Check vendor/czemu/nova-calendar-tool/composer.json for the Nova constraint. On Nova 4/5 expect Vue 2→3 and asset-pipeline breakage; the practical path is usually to fork into nova-components/ and patch the tool, not to chase the upstream.
• Missing JS/CSS? Run php artisan nova:publish and php artisan optimize:clear. Nova caches tool assets and routes aggressively; most "calendar is blank" reports are stale caches, not bugs.
• Silent empty calendar is almost always a data-shape problem. If the query returns rows but nothing renders, the column names or date casts are wrong. Tinker the model and inspect the tool's JSON endpoint (usually /nova-vendor/...) in the network tab before editing any JS.
• Timezones will bite. Calendar libraries typically render in browser-local time while your DB stores UTC. Store UTC, and sanity-check events that cross midnight and DST boundaries — this is the #1 source of "my event is on the wrong day."
• Don't blindly run the published migration in an environment where a calendar_events-style table already exists or name-collides. Review it, rename it, or skip publishing if you're binding your own model.
• start/end are usually required and non-nullable, and all-day vs timed events may be distinguished by a boolean or by a time-less start. Check the migration; a nullable end often causes the last day to drop off a multi-day event.
• Extension points are thin. Expect the config file, the bound model, and maybe a single query/resolver callback. Anything richer (custom event modal, recurring events, drag-to-create) means a fork — budget for it up front rather than after you've built around the package.
• Pin the version in composer.json. With a single 2021 release, a future composer update could pull an incompatible patch or a yanked tag; an exact constraint keeps your calendar stable while you decide whether to maintain a fork.