Resized Column Laravel Package

Getting Started

1. Install and confirm what you actually got. The package is a Filament panel plugin (asmit/resized-column). Before wiring anything up:

composer require asmit/resized-column
composer show asmit/resized-column   # note the exact version + license block

Require ^4.0.2 at minimum. v4.0.2 is a bugfix, not a feature release, but the bug it fixes is one you will otherwise spend an afternoon on: a column manager or filter set to ->modal() / ->slideOver() renders behind the topbar. If your panel uses modal-based filters (very common), 4.0.1 and below are visibly broken.

Read the LICENSE file in vendor/asmitnepali/resized-column before you ship this to a client. The registry reports NOASSERTION, which means Composer could not identify a standard license — that is a legal question, not a technical one, and you need it answered before this lands in a commercial panel. (v4.0.2 dropped the Buy Me a Coffee link; GitHub Sponsors remains. Funding is unrelated to licensing — do not read the chore as clarification.)

2. Where to look first. In order:

• src/ — the plugin class and any Table/Column macros. This tells you whether resizing is panel-wide, per-table, or per-column.
• resources/dist/ (or resources/js) — the drag JS. This is where you find the localStorage key format, the Livewire hooks, and the CSS that gives .fi-ta-header-ctn a stacking context. Read this file before you trust the feature; it is ~100 lines and answers every gotcha below.
• README.md — exact plugin registration snippet. Filament plugin APIs changed between v3 and v4; this release line is Filament v4, so copy the registration from the README that matches your major, not from a blog post.

3. Register the plugin in your panel provider alongside your other plugins:

// app/Providers/Filament/AdminPanelProvider.php
public function panel(Panel $panel): Panel
{
    return $panel
        ->plugins([
            \Asmit\ResizedColumn\ResizedColumnPlugin::make(),
        ]);
}

Then clear caches and rebuild assets, because this package ships compiled CSS/JS that Filament must register:

php artisan filament:assets
php artisan optimize:clear

4. First use case. Pick your worst table — the one with 12 columns where name and email get clipped to John Sm…. Drag the header divider, reload the page, and confirm the width persisted. Then open your column manager (if it's a modal/slide-over) and confirm it opens above the topbar with its heading visible. That second check is the v4.0.2 acceptance criterion. If either fails, stop there.

Implementation Patterns

Enable panel-wide, then opt out where it hurts. The low-friction pattern is to turn the plugin on globally so every resource table gains handles, then disable it on tables where resizing is nonsense (dashboards, tiny 3-column pivot tables, anything with a ->grow()-heavy single column). Check the source for whether the opt-out is ->resizable(false) on the table or a plugin ->tables([...]) allowlist — the allowlist form is safer, because a new resource silently gaining drag handles is a support ticket waiting to happen.

Treat column widths as a user preference, and be explicit about scope. These packages almost universally persist to localStorage, which means:

• widths are per-browser, per-device — not per-user;
• clearing site data resets them;
• a user on a 27" monitor and the same user on a laptop get the same pinned pixel widths.

Say this out loud in your release notes. If the client expects "my column layout follows me," you will need to persist widths server-side against auth()->id() — and that is a UserPreference table plus a custom JS listener, not a config toggle. Decide this before the client asks.

Pair it with the column manager, don't fight it — and smoke-test the layering. Resizing and toggling must agree on column identity. Verify that hiding then showing a column restores its width rather than resetting to default. If it resets, key your widths on column name (->name('email')) rather than on position — position-based keys break the moment a column is toggled or a resource gains a column in a deployment.

v4.0.2 is specifically about the toolbar interaction: the package wraps the table header in its own z-index: 21 stacking context so dropdowns clear the sticky thead, and that context previously trapped a modal overlay (z-index: 40) beneath Filament's topbar (z-index: 30). The fix lifts the toolbar context above the chrome only while a toolbar modal is open. So add this to your standard pattern: any panel using ->modal() or ->slideOver() on the column manager, filters, or bulk actions gets a manual check that the overlay and its heading render on top. Do this once at install and once per package upgrade, not per table.

Order columns for the workflow, then let users resize. This package is at its best when you have already narrowed the table to "the 8 columns people actually scan" and the remaining problem is purely that description needs more room than id. Do the column curation in code; use the package for the last mile. Resizing is a comfort feature, not a substitute for hiding the columns nobody reads.

Compose with filters and sorting normally. Because widths are applied as CSS rather than as server-side column config, they should survive search, sort, filter and pagination. Verify each of those four explicitly — pagination is the one that breaks, because it triggers a full Livewire re-render. Then open a filter that lives in a slide-over, apply it, and close it: the v4.0.2 context lift must be reversed cleanly, or you'll get dropdowns floating above modals afterwards.

Give testers a script. Livewire/PHPUnit cannot meaningfully assert a drag. What you can assert is that the table renders the wrapper/handle class and that your registration is active:

it('renders the resizable table wrapper', function () {
    livewire(ListUsers::class)
        ->assertSeeHtml('data-resizable-columns'); // confirm the real attribute from resources/dist
});

Manual QA checklist: drag → paginate → sort → search → toggle a column → open a slide-over filter → reload → change device width. Eight steps, catches everything including the v4.0.2 regression surface.

Gotchas and Tips

The header stacking context is now load-bearing — don't override it casually. The package promotes .fi-ta-header-ctn to z-index: 21 so toolbar dropdowns clear the sticky thead. Anything you add in that subtree inherits that context. If you later add a modal, a @teleport-less overlay, or panel CSS with its own z-index, be aware of what it's nested inside. Symptom of getting it wrong is exactly the v4.0.2 bug: a slide-over panel whose body and footer show but whose heading sits under the topbar, or a click that lands on the topbar instead of the overlay. If your theme sets z-index on .fi-topbar, .fi-sidebar, or .fi-ta-header-ctn, re-test modals after upgrading — the relative order is what matters, not the absolute numbers.

Livewire morph can wipe inline widths. This is the #1 failure mode for DOM-mutating table plugins. The width lives as an inline style on a <th>/<col>; Livewire's morphdom pass after a search or pagination replaces those nodes and the widths snap back to default mid-session. If you see widths reset after interacting (but not after a page reload), the fix is in the package's JS: it must re-apply widths on livewire:navigated and on morph completion, not only on DOMContentLoaded. Check the dist file for those listeners before you file the bug.

table-layout: fixed is doing the real work. Column pixel widths are advisory under table-layout: auto — the browser keeps re-measuring content and ignoring you. If dragging feels like it "half works" or springs back, inspect the table element's computed table-layout. The package needs to set fixed, and your own table config (especially ->grow() on a single column, or a TextColumn with ->wrap()) can pull it back to auto. Resolve by removing ->grow() from the columns you want users to control.

Never let the bulk-select column be resizable. Same for any sticky/frozen column and the row-action column. A user who drags the checkbox column to 8px has an unrecoverable table and no idea how to fix it. If the package doesn't exclude these by default, exclude them explicitly and consider a min-width floor in your CSS.

Mobile is a different layout entirely. Filament stacks tables into cards below the breakpoint; drag handles there are meaningless or actively broken. Hide the handles under your mobile breakpoint with CSS rather than relying on the package to know. Test at 390px wide — that is where these plugins look worst. Check modal/slide-over layering at that width too; v4.0.2's context lift interacts with the mobile topbar differently than the desktop one.

localStorage keys collide across panels and tenants. If you run more than one panel (admin + app) or use Filament tenancy, and the width key does not include a panel/tenant discriminator, two different tables that happen to share a name will overwrite each other's widths. Symptom: widths are correct on /admin/users and mysteriously wrong on /app/users. Fix by namespacing the key yourself if the package doesn't expose a key prefix.

Pin the version — 0 dependents and a handful of stars is a real signal. This is a small, single-maintainer package with no downstream ecosystem, so nobody else is discovering its breakage for you. v4.0.1 → v4.0.2 being a CSS z-index fix is the clearest possible evidence that patch releases can visibly change your panel chrome. Protect yourself:

"asmit/resized-column": "4.0.*"

and, ideally, wrap it behind a config flag (config('features.resizable_columns')) so that if a Filament minor release breaks it, you can ship a toggle-off in five minutes instead of a hotfix. Budget for the possibility that you maintain your own fork; the whole feature is ~a few hundred lines of CSS/JS, so replacing it is a day of work, not a project.

Asset staleness after deploy. Because the behaviour lives in compiled assets, an upgrade followed by a plain php artisan config:cache will serve the old CSS/JS and produce "the fix didn't work" ghost reports. Make php artisan filament:assets part of your deploy script and run php artisan optimize:clear before debugging anything. This matters more than usual for 4.0.2 — the fix is entirely in shipped CSS, so a stale asset means the modal still renders behind the topbar and you'll conclude the release is broken.

Debugging checklist. (1) DevTools → Application → Local Storage: find the key, confirm it holds your widths. (2) Inspect the <th>: is there an inline style="width:…". (3) Is the computed table-layout fixed. (4) Console errors on morph/pagination. (5) For layering bugs, inspect .fi-ta-header-ctn and read the computed z-index on it, the overlay, and .fi-topbar — confirm the numbers are in the order you expect and that the context lift is actually toggling during open/close. (6) Confirm the plugin registered — php artisan about and the compiled asset paths list. That sequence separates "package is broken" from "our table config or theme is fighting it" in about two minutes.

Extension point to know. If the package doesn't expose width persistence, the cleanest extension is a small Livewire hook in your own layout that reads the package's localStorage key on save and POSTs it to a user-preference endpoint. Read the exact key format from resources/dist, and keep that coupling isolated in one file — it is the thing most likely to break on upgrade. Same rule for the z-index behaviour: if you need your own layering adjustments, put them in one override file next to this hook rather than scattering z-index through your panel theme.