Laravel Livewire Kanban Laravel Package

Getting Started

• Confirm the runtime baseline before installing: PHP 8.3+, Laravel 13, and Livewire 4. This release does not add Laravel 14 support. If you are still on Laravel 12 or Livewire 3, stay on the prior package line.
• Install the Composer package, then decide how you will supply frontend styling:
  • Hosts already using DaisyUI 5.7.50 + Tailwind CSS 4.3.3: import resources/css/kanban.css from the Composer package into your global stylesheet. This is the recommended path because it includes package view source detection and inherits host theme tokens.
  • Hosts without DaisyUI: you may load the standalone resources/dist/kanban.css only after checking its Tailwind/DaisyUI bundle and global reset against the rest of your page.
• Do not load both the package CSS entry point and the standalone bundle. Choose one styling path and stick to it.
• Publish config and Blade views if you need to customize board behavior or markup. Review any existing published overrides immediately: this release switches presentation to DaisyUI classes while preserving behavior hooks.
• Check theme configuration. The inherited system mode now uses data-kb-theme="system"; it no longer emits data-theme="system". Explicit light/dark selections still set a local theme.
• First use case: start with one of the runnable demos — task, ticket, class, mixed-source, or compact model demos. They show the intended Eloquent model integration and give you a working board before you wire your own models.
• If you are only doing a static board, begin with a simple board definition and the published views. If you are integrating existing Eloquent models, go straight to the optional model trait, definitions, and explicit source registry described in the model integration guide.
• Where to look first: the upgrade guide (UPGRADE.md), the model integration guide, the multi-source guide, the performance guide, and the workflow/ranking guide. The customization guide documents host CSS tokens and selectors.

Implementation Patterns

• Host-themed DaisyUI integration. Treat the package as a DaisyUI consumer rather than an independent palette. Import resources/css/kanban.css into your global stylesheet, use host semantic colors and public DaisyUI radius tokens, and validate contrast against your own palette. Custom host palettes and provider-supplied stage colors need host-specific contrast checks.
• Model-backed boards. Use the optional model trait, model definitions, and explicit source registry to bind boards to Eloquent models. Keep the registry explicit per board rather than relying on implicit discovery; that is what enables scoped multi-source reads.
• Multi-source boards. Use scoped reads and authenticated keyset cursors when a board combines multiple model sources. The release adds bounded eager loading, SQL counts, and aggregate metrics; use those to keep board queries predictable rather than letting card rendering trigger N+1 queries.
• Transactional model actions. Wrap card moves, stage changes, and bulk operations in the package’s transactional model actions. Use operation recovery/deduplication where actions may be retried, and version checks to avoid lost updates.
• Ranking and WIP. Use numeric ranks with local rebalancing rather than assuming dense integer ordering. Enforce WIP limits through the package’s WIP enforcement path, and use atomic or partial bulk actions depending on whether partial success is acceptable.
• Presentation controls. For dense boards, use compact presentation, group selection, persistent column collapse, and bounded card render windows. These are the day-to-day levers for large boards; combine them with drag auto-scroll and touch handles for pointer and touch workflows.
• Blade overrides. Keep existing behavior hooks intact when adapting published Blade views to DaisyUI classes. Filters and appearance controls now sit inside disclosure panels, so overrides must preserve the trigger/panel relationship rather than exposing the controls directly.
• Workflow UI. Use the named dialog surfaces, focus containment/return, inert background content, Escape handling, and stage-form cancellation as the baseline for modal workflows. Floating forms are scrollable in this release.
• External calendar integration. Treat the Calendar package integration as an adapter contract. Implement against the documented contract, but plan to verify behavior against the actual Calendar installation because the release notes explicitly say it has not been verified externally.

Gotchas and Tips

• CSS double-loading is the most likely upgrade mistake. Importing resources/css/kanban.css and also loading resources/dist/kanban.css will duplicate styles and may apply the standalone bundle’s global reset unexpectedly. Pick one.
• Standalone CSS includes a global reset. If you use resources/dist/kanban.css, check its effect on the rest of the page before shipping. It is not a drop-in neutral stylesheet.
• Theme mode changed. Replace any reliance on data-theme="system" with data-kb-theme="system". Explicit light/dark choices continue to set a local theme, so mixed host/package theme logic needs review.
• Published Blade overrides need a real review. The DaisyUI migration is not only a class rename; filters and appearance controls are now behind disclosure panels. If your overrides assume those controls are always visible, tests and user workflows may break.
• Accessibility is improved but not certified. The release adds focus containment, keyboard Escape support, inert backgrounds, and named dialog surfaces, but it explicitly is not a WCAG conformance certification. Physical-device and full screen-reader testing have not been completed.
• Known workflow rough edges remain. Internal stage-ID entry in the card form, programmatic field-error association, card-menu clipping near scroll edges, and list/table accessibility semantics are called out as limitations. Design around them or plan follow-up work.
• Contrast validation is your responsibility. Host palettes and provider-supplied stage colors need host-specific contrast validation. Do not assume the package’s defaults guarantee contrast in your theme.
• No package database migration is required. That does not mean model integration is migration-free: your host application still owns the tables and columns behind the Eloquent models you register.
• Cursor and security behavior. Authenticated keyset cursors are part of the multi-source read path. If you expose board data through custom endpoints or Livewire actions, keep the same authentication and scoping assumptions.
• Performance verification. The release reports SQL counts and aggregate metrics. Use them when tuning eager loading and card render windows; large boards are where bounded rendering and scoped reads matter most.
• Version and retry behavior. Use version checks for concurrent edits and operation deduplication for retried actions. Bulk actions can be atomic or partial; choose deliberately and make the UI communicate partial success.
• Upgrade order. Read UPGRADE.md first, then the customization guide, then the model integration and multi-source guides. The frontend changes are the most visible, but the model adapter and action semantics are the parts most likely to affect day-to-day development.