DEV Community: Nasrul Hazim Bin Mohamad

Making a datatable keyboard-usable: focus traps and arrow-key row reorder

Nasrul Hazim Bin Mohamad — Fri, 03 Jul 2026 08:48:36 +0000

TL;DR

Shipped two a11y wins in laravel-livewire-tables v4.1.0: focus traps on popovers and a keyboard alternative to drag-reorder.
Focus trap = Alpine's x-trap. One directive gives you focus-in, Tab-wrap, and ESC-to-close-and-return.
Drag handles are now focusable buttons that move rows with ArrowUp/ArrowDown — mouse is no longer mandatory.
Bonus: an opt-in client-side column toggle that flips visibility via x-show with zero Livewire round-trips.

Drag-and-drop and mouse-only popovers are the two spots where datatables quietly lock out keyboard and screen-reader users. Both got fixed today. Here's the how and the why.

Focus traps without writing a focus manager

When a filter or column dropdown opens, focus should move into it, Tab should cycle within it, and ESC should close it and hand focus back to the button that opened it. Writing that by hand means tracking the first/last focusable element, listening for Tab at the boundaries, and stashing the trigger to restore later. It's fiddly and easy to get subtly wrong.

Alpine's x-trap does the whole dance in one directive:

<div x-trap="filterPopoverOpen" ...>
    {{-- popover contents --}}
</div>

Bind it to the same boolean that controls the popover's visibility. When the expression flips true, focus moves in; ESC and Tab-wrapping come for free; when it flips false, focus returns to the trigger. Same pattern on the column-select and bulk-actions popovers — three popovers, one mental model.

TL;DR of this section: don't hand-roll focus management. x-trap is a battle-tested primitive; wiring it to your existing open/close state is a one-line change per popover.

Keyboard row reorder

Drag-to-reorder is the classic "works great with a mouse, impossible without one" feature. The fix isn't to replace drag — it's to give the drag handle a keyboard mode too. While reordering is active, the handle becomes a real button and listens for arrow keys:

<x-livewire-tables::table.td.plain
    x-show="currentlyReorderingStatus"
    role="button"
    aria-label="{{ __('Reorder') }}"
    x-bind:tabindex="currentlyReorderingStatus ? 0 : -1"
    x-on:keydown.arrow-up.prevent.stop="moveRow(event, -1)"
    x-on:keydown.arrow-down.prevent.stop="moveRow(event, 1)">
    {{-- handle icon --}}
</x-livewire-tables::table.td.plain>

Three things make it correct, not just present:

Detail	Why it matters
`role="button"` + `aria-label`	The icon-only handle now announces itself as an actionable control with a name.
`tabindex` bound to reorder state	The handle is only in the tab order while reordering — no dead stops otherwise.
`.prevent.stop` on arrow keys	Stops the page from scrolling and the event from bubbling when a row moves.

Same moveRow() logic backs both the drag and the keyboard path, so behaviour stays consistent.

Prove it with a test

Interactive focus behaviour ultimately needs a real browser (and a screen-reader pass), but the markup contract is cheap to lock down in Pest so a refactor can't silently drop the hooks:

it('renders keyboard-operable reorder handles while reordering', function () {
    livewire(PetsTable::class)
        ->call('enableReordering')
        ->assertSeeHtml('role="button"')
        ->assertSeeHtml('aria-label="Reorder"')
        ->assertSeeHtml('moveRow(event, -1)')
        ->assertSeeHtml('moveRow(event, 1)');
});

it('traps focus inside the filter popover (x-trap)', function () {
    livewire(PetsTable::class)
        ->assertSeeHtml('x-trap="filterPopoverOpen"');
});

These aren't a substitute for testing actual focus movement — they're a guard rail. If someone rewrites the reorder cell and forgets the ARIA hooks, the suite goes red before review.

Bonus: client-side column toggle

Same release, different itch. Toggling a column normally costs a Livewire round-trip. There's now an opt-in mode — setUseClientSideColumnVisibilityEnabled() — where every selectable column renders up front and the dropdown flips it via Alpine x-show, entangled with selectedColumns. Toggling feels instant; the selection still syncs and persists on the next Livewire request. It's opt-in on purpose (rendering every column has a cost) and it steps aside on the Flux theme, whose native cells carry no Alpine hooks.

Takeaway

Accessibility on a complex widget isn't one big lift — it's a handful of small, correct primitives: x-trap for focus, role/aria-label/tabindex for keyboard controls, and a markup-contract test so none of it rots. Reach for the framework's primitive before you write your own focus manager.

Dev Log: 2026-07-02 — disable means drain, and case never matters

Nasrul Hazim Bin Mohamad — Fri, 03 Jul 2026 08:48:23 +0000

TL;DR

"Disable" should drain, not delete. Turning off a gateway route or an upstream target now blocks/redirects traffic gracefully instead of yanking config out from under live requests.
Case should never decide identity. Directory lookups and auth flows now normalise case so UPPER() mismatches stop causing phantom "user not found" and duplicate-account bugs.
A couple of sharp framework gotchas: a Blade compile quirk and a pgBouncer + PDO prepared-statement trap.
Standout of the day is a public one — accessible datatables — written up on its own.

Disable is a state, not a delete

Across an API-gateway management app I work on, the recurring theme today was the difference between removing something and disabling it.

Disabling a route shouldn't quietly deregister it and let in-flight requests fall through to nothing. It should install an explicit guard that terminates (or redirects) traffic while the route sits disabled — an off switch, not a shredder. Same idea for upstream targets: an Enable/Disable toggle now drains a target instead of deleting it from the pool, so connections finish instead of getting cut.

The lesson generalises: any "on/off" on live infrastructure wants three states in your head — active, draining, off — not a binary that maps "off" to "gone".

Case should never decide identity

The other thread ran through an enterprise identity portal. Directory backends are merciless about case: an Oracle-backed username, an LDAP attribute, and an email typed at login can all differ only in capitalisation and still be the same person. That mismatch shows up as "user not found", duplicate accounts, or a password reset that silently targets the wrong row.

The fix is boring and correct: normalise case at the boundary.

// Match on a case-folded column, not the raw input.
User::whereRaw('UPPER(email) = ?', [Str::upper($email)])->first();

Do it consistently — lookups, login sync, password reset — and a whole category of "works for me / not for them" bugs disappears. If you can, back it with a functional index on UPPER(column) so the normalised lookup stays fast.

Two gotchas worth pocketing

Symptom	Cause	Fix
Number field renders invisible in a component	`@if` placed inside a component tag's attributes skips compilation	Move the conditional outside the tag, or use `:attribute` binding
Query fails behind a connection pooler	`pdo_pgsql` server-side prepared statements clash with pgBouncer (transaction pooling)	Disable server-side prepares on the connection

Both cost more debugging time than they should because the failure looks like something else — a styling bug, a flaky query — not a config mismatch.

Takeaway

Two ideas carried the day: disable is a lifecycle state, so drain don't delete, and case is not identity, so normalise at the edge. Neither is glamorous; both quietly remove an entire class of production surprises.

Dev Log: 2026-07-01

Nasrul Hazim Bin Mohamad — Thu, 02 Jul 2026 01:09:55 +0000

TL;DR

Public Livewire tables package: extracted a theme-class seam so Blades stop branching per theme (full write-up in a separate post).
Analytics dashboard: fixed timezone-bucketed charts and exact request counts past Elasticsearch's 10k cap.
Identity sync: nailed an Active Directory password-set gotcha that needed a model re-fetch.
Membership platform: shipped white-label branding driven by settings.

Four threads today, one public, three anonymized.

1. Public: a theme-class seam for Livewire tables

The big one. Blade partials that branched @if($isTailwind)/@elseif($isBootstrap) for CSS classes don't scale when you add a third theme. I pulled all class strings into one static, cache-safe map and gave Blades a single themeClasses('key') accessor — new themes override keys instead of re-implementing templates, guarded by characterization tests. Repo: cleaniquecoders/laravel-livewire-tables. Separate focused post covers it.

2. Analytics dashboard: timezone and count correctness

Two subtle reporting bugs, both generic enough to be worth naming.

Peak-hours bucketing. Hourly charts bucketed on raw UTC, so "peak hour" was off by the app's offset. Fix: bucket by the application timezone at the metrics-provider layer, not in the app on top of a UTC result.

The 10k ceiling. Elasticsearch caps hits.total at 10,000 by default, so "Total Requests" plateaued and error-rate math went wrong on busy days. The fix is one flag:

// exact totals instead of the lower-bound 10k estimate
$params['body']['track_total_hits'] = true;

Bug	Root cause	Fix
Wrong peak hour	Bucketed on UTC	Bucket on app timezone
Requests capped at 10k	ES default `track_total_hits`	Set it to `true`
Chart drill-down 500	`array_sum` over mixed shape	Normalize series first

Also settled the timezone at the package level and dropped the per-app override — the fix belongs where the data is shaped, not patched downstream.

3. Identity sync: the AD password gotcha

Syncing users into Active Directory, setting the password threw unicodePwd: No such attribute. Cause: the directory model was stale between create and the password write. Fix: re-fetch the model right before setting the password so the write targets a live object. Wrote it up as a support note because it's the kind of thing you rediscover painfully six months later.

Also moved pending-sync reconciliation to be source-of-truth-first: reconcile against the authoritative HR system before touching the directory, so orphaned attempts heal instead of pile up.

4. Membership platform: white-label branding

Footer credit, contact email, and brand colours are now settings-driven instead of hardcoded, so one codebase can present as different brands. Standard move: a typed settings object, a config fallback, and a Blade partial reading from it.

Thread of the day

Correctness in the boring layer. Three of four items were "the code ran fine and returned the wrong thing" — a timezone offset, a silent 10k cap, a stale directory model. None throw. All caught by asking whether the number is actually true.

Killing @if($isTailwind) in Blade: a theme-class seam for Livewire tables

Nasrul Hazim Bin Mohamad — Thu, 02 Jul 2026 01:09:23 +0000

TL;DR

Blade templates that branch @if($isTailwind) ... @elseif($isBootstrap) for CSS classes don't scale. Adding a Flux theme meant a third branch in every file.
I moved all class strings into one static map (ThemeStyles) and gave Blades a single seam: themeClasses('key'). Themes now override keys, not re-implement templates.
Kept it closure-free so it survives config:cache, and guarded every migration with characterization tests that assert the rendered HTML is byte-for-byte unchanged.

This is from the public cleaniquecoders/laravel-livewire-tables v4 fork.

The problem

The package ships Tailwind and Bootstrap themes. Every Blade that needed styling did this:

@class([
  'px-3 py-2 ...' => $isTailwind,
  'p-2 border ...' => $isBootstrap,
])

Fine for two themes. But I was adding a Flux theme, and the honest question was: do I really want a third @elseif in every one of ~40 Blade partials? That's the smell. When adding a variant means editing every template, your variation axis is in the wrong place.

Analogy: this is a light switch wired directly to the bulb. Want a dimmer? You rewire every room. Better to run everything through one panel.

The seam

One static class holds per-theme class strings, keyed by a dotted name:

class ThemeStyles
{
    protected static array $classes = [
        'tailwind' => [
            'table.wrapper' => 'shadow overflow-y-auto border-b ... sm:rounded-lg',
            // ...
        ],
        'flux' => [ /* only the keys Flux overrides */ ],
    ];

    public static function for(string $theme, string $key): string { /* ... */ }
}

Blades stop branching and just ask for a key:

{{-- component trait: themeClasses() delegates to ThemeStyles::for() --}}
<td @class([$this->themeClasses('td.collapsed.base')])>

The trait behind it is three lines:

public function themeClasses(string $key): string
{
    return ThemeStyles::for($this->getTheme(), $key);
}

Two design choices matter here.

Flux falls back to Tailwind. Flux is Tailwind-based — it only differs on a handful of keys (dropdown panels, pills, empty state). So for() resolves the theme's key, and if it's missing, falls back to the tailwind map. A new theme defines only its diffs, not the whole surface.

No closures in the map. Tempting to store fn () => ... for dynamic classes. Don't — closures can't be serialized, so php artisan config:cache (and Octane) chokes. Plain strings keep it cache-safe. Anything genuinely dynamic stays in the Blade around the seam, not inside the map.

	Before	After
Add a theme	Edit ~40 Blades	Add one map entry, override diffs only
Class source	Scattered inline	One file
Cache-safe	n/a	Yes (no closures)
Blade job	Branch per theme	Ask for a key

Don't trust yourself — guard with characterization tests

Migrating 40 templates by hand is exactly where you silently drop a class and shift a border 1px. So before touching a Blade, I pinned its current output:

it('renders the collapsed cell identically after the seam migration', function () {
    $html = BooleanColumn::make('Active')
        ->render(/* ... */)
        ->toHtml();

    expect($html)->toContain('p-3 table-cell text-center');
});

A characterization test doesn't care whether the output is good — only that it didn't change. Migrate one Blade group, run the per-theme visual suite, confirm green, commit, next group. One slice at a time.

One real find along the way: an empty-string class key rendered subtly differently through @class() than an inlined blank — the kind of thing you only catch because the test compares exact output, not intent.

Takeaway

When adding a variant forces you to edit every file, extract the variation into a seam the files consult. For a Blade UI package that's a keyed class map plus a one-line themeClasses() accessor. Keep the map serializable so it survives config caching, and let characterization tests carry the risk of a large mechanical migration. The payoff: the Flux theme landed as a set of key overrides, not a fourth copy of every template.

Dev Log: 2026-06-30

Nasrul Hazim Bin Mohamad — Tue, 30 Jun 2026 16:16:06 +0000

TL;DR

Three threads today: a public Livewire tables package jumped to Laravel 13 + Livewire 4, an identity portal got a cleaner audit-log datatable, and an IAM system got defensive plumbing — whitespace-safe status, read-only DB guards, and ops tooling.

1. Public package: Laravel 13 + Livewire 4

I forked laravel-livewire-tables to a v4 line after upstream declined Livewire 4. Today it landed Laravel 13 support, dropped Livewire 3, moved tests to Pest 4, and got a Testbench workbench demo. Full write-up in a separate post — short version: when upstream says no, fork it, but bring the test harness.

2. Identity portal: collapsing a wide datatable

An audit-log datatable had drifted into per-service columns — one column per service, which doesn't scale and reads badly on mobile. The fix was to merge them into a single Services cell with inline pills, and pair the user into one cell and status+services into another.

TL;DR: fewer, denser columns beat many thin ones. Lesson: when a Livewire table grows a column per entity, that's the signal to collapse into a composed cell (a Blade partial rendering pills) instead of widening the table forever.

Before	After
One column per service	One Services cell, inline pills
Separate user/email columns	One composed user cell
Faded status colours	Solid status colours

3. IAM: defensive plumbing

The bigger thread was hardening an identity & access management system. Three lessons worth keeping:

Whitespace-insensitive status. A stored status string with a stray space (think "ACTIVE -X" instead of "ACTIVE-X") silently failed a downstream eligibility gate. The root-cause fix was to normalize on the way in and compare insensitively, then backfill the bad rows.

// normalize before persisting, compare without trusting whitespace
$canonical = Str::of($raw)->squish()->upper()->value();

A status string is a contract. If a space can break a gate, the comparison is too trusting.

Read-only DB guard. A failover left the DB read-only, and the scheduler kept firing jobs that all failed — a cascade of noise. The fix: detect read-only mode and stop the cron cascade early, with a notification instead of a flood of exceptions.

Ops tooling over the app. Added audit + remediation tools (status audit, resync, normalize) so on-call can inspect and fix state without raw DB access, plus permission-gated access to queue/dashboard internals. Exposing safe, gated operations beats handing out database credentials.

Takeaway

Different repos, one theme: make the source of truth tolerant of messy input, then guard the edges — whitespace, failover, and access all count as edges.

Forking laravel-livewire-tables for Laravel 13 + Livewire 4

Nasrul Hazim Bin Mohamad — Tue, 30 Jun 2026 16:15:38 +0000

TL;DR

Upstream rappasoft/laravel-livewire-tables marked Livewire 4 support wontfix, so I forked it.
The fork now targets Laravel 13 (keeps 12), runs on Livewire 4, and drops Livewire 3.
Tests moved to Pest 4 (old PHPUnit classes still run via interop), with a Testbench workbench demo app.
Takeaway: when an upstream says no, a fork is fine — but only if you bring the test harness with you.

Why fork at all

I lean on this package across projects: sortable, searchable, filterable tables for Livewire. The problem: upstream declined Livewire 4 support (wontfix) and hadn't shipped Laravel 13. I didn't want to be stuck on Livewire 3 forever, so I started a v4 line in my fork at cleaniquecoders/laravel-livewire-tables.

A fork is like renovating a rented house you've decided to buy — worth it only if you're committed to maintaining it. I am, so the roadmap lives in GitHub milestones M1–M8.

What landed today

Milestone	Change
M1	Laravel 13 + Livewire 4 support; drop Livewire 3
M2	Migrate test suite to Pest 4 + Testbench workbench demo
M3	Upstream bug-fix cluster + regression tests
CI	Replace L10/L11 workflows with a v4 matrix
—	Pint formatting pass under the upgraded toolchain

The constraint matrix

The dependency floor moved up. Here's the before/after:

	Before	After
PHP	8.1+	8.2+
Laravel	10 / 11	12 / 13
Livewire	3	4 (3 dropped)
Tests	PHPUnit	Pest 4 (PHPUnit interop)

CI now runs the cross-product so a regression on any combo shows up fast:

# .github/workflows/ci.yml
matrix:
  php: ['8.3', '8.4', '8.5']
  laravel: ['12.*', '13.*']
# ...
- run: composer require "laravel/framework:${{ matrix.laravel }}" --no-interaction --no-update
- run: vendor/bin/pest --no-coverage

Pest without a big-bang rewrite

The trick to migrating tests is don't rewrite them all at once. Pest runs class-based PHPUnit tests unchanged via its interop layer, so the ~hundreds of existing test_* methods keep passing while new tests are written Pest-native.

The bind is one line in tests/Pest.php:

uses(TestCase::class)->in('Unit', 'Visuals', 'Feature');

And new tests read the way Pest tests should — fluent, no class boilerplate:

use function Pest\Livewire\livewire;

it('builds a configurable column fluently', function () {
    $column = Column::make('Name', 'name')->sortable()->searchable();

    expect($column->getTitle())->toBe('Name')
        ->and($column->isSortable())->toBeTrue()
        ->and($column->isSearchable())->toBeTrue();
});

So the migration is incremental: old suite stays green, new work goes Pest-first.

A workbench you can actually click

Testing a UI package against assertions only gets you so far. M2 adds an Orchestra Testbench workbench — a tiny real Laravel app inside the package you can boot and click through:

composer build   # testbench workbench:build
composer serve   # testbench serve

It ships demo models (Owner, Species, Breed, Pet), a seeder, and a DemoPetsTable Livewire component, so you can see the table render against real data instead of imagining it from a test name. For a component library, that's the difference between "tests pass" and "it actually looks right."

What's next

The heavy refactor is still ahead (M6): the component composes ~26 load-order-dependent With* traits and inlines theme branches across ~59 Blade files. That sprawl is the real target — but the rule is behaviour-preserving and test-guarded. Today's job was getting onto Laravel 13 + Livewire 4 with a green Pest suite first, so the refactor has a safety net.

If you're maintaining a package and upstream says no to the version you need: fork it, but bring the tests. The test harness is what makes a fork maintainable instead of a liability.

Resolve the tenant from the user, not the request

Nasrul Hazim Bin Mohamad — Tue, 30 Jun 2026 00:04:56 +0000

TL;DR

A multi-tenant app was resolving the active tenant from the request (subdomain/header) instead of the authenticated user.
That makes the client the source of truth for "which tenant am I" — the wrong place for it.
Fix: derive the tenant from the user's organization membership, enforce it in middleware, and fail closed. One test locks the behaviour.

The bug, in one sentence

The request was telling the app which tenant to load, and the app believed it.

In a multi-tenant SaaS, every query is implicitly scoped: "give me this tenant's dashboards." If the tenant ID comes from something the client controls — a subdomain, a header, a route param — then the scoping is only as trustworthy as the client. That's a leak waiting to happen.

Where the trust should live

Think of it like a building pass. The request is someone saying "I'm here for floor 9." The membership record is the pass that says which floors you're actually allowed on. You check the pass, not the claim.

	Before	After
Source of truth	request (subdomain / header)	user's organization membership
Who decides the tenant	the client	the server
Failure mode	user can land in a tenant they don't belong to	resolution fails closed
Testable?	hard — depends on request shape	yes — depends on the user

The shape of the fix

Resolve the tenant from the authenticated user's organization, in one middleware, before anything tenant-scoped runs:

final class SetTenantContext
{
    public function handle(Request $request, Closure $next): Response
    {
        $org = $request->user()?->currentOrganization();

        // No org, no tenant context. Fail closed, never guess.
        abort_if($org === null, 403, 'No organization context.');

        Tenancy::setCurrent($org->tenant);   // server-derived, not request-derived

        return $next($request);
    }
}

The key line isn't the setCurrent() — it's that the value comes from $request->user(), not from $request. The user is authenticated; the subdomain is not.

  request ──> [auth] ──> [SetTenantContext] ──> tenant-scoped routes
                              │
                              └── tenant = user's org  (NOT the URL/header)

Lock it with a test

A leak like this is exactly the kind of thing that silently regresses. So the fix isn't done until a test would scream if someone reintroduces it:

it('never resolves a tenant the user does not belong to', function () {
    $userA = User::factory()->inOrganization($orgA = Organization::factory()->create())->create();
    $orgB  = Organization::factory()->create();

    // Even if the request "asks" for org B, user A must stay in org A.
    actingAs($userA)
        ->withHeader('X-Tenant', $orgB->tenant->getKey())
        ->get('/dashboards')
        ->assertOk();

    expect(Tenancy::current()->is($orgA->tenant))->toBeTrue();
});

Takeaway

If a value scopes data, it has to come from something the client can't forge. For tenant resolution that means the authenticated user's membership — verified server-side, failing closed when it's missing. Resolve identity from who you are, not from what you ask for.

When a KPI reads 163 billion instead of 819

Nasrul Hazim Bin Mohamad — Tue, 30 Jun 2026 00:04:21 +0000

TL;DR

A metrics engine had two query paths — a SQL push-down for big datasets, an in-memory aggregator for small ones. They drifted.
The push-down path bound a metric parameter but never added it to the WHERE. With several metric series in one dataset, every query summed across all of them.
A KPI that should read 819 read 163,667,603,769.
Fix: put the metric_key predicate in the shared base WHERE so every compile path inherits it, and regression-test both paths assert it.

The setup: two paths, one contract

A lot of analytics layers compute the same number two ways. For a big dataset you push the aggregation down to the database. For a small one — a preview, a draft dashboard — you pull the rows and aggregate in memory. Faster path, correct path. Both are supposed to return the same value. That's the contract.

The dataset stores rows keyed by a metric_key, because one dataset can hold several series at once — say a plain row count and a count-distinct. Each series lives in the same table, told apart only by its key.

The bug: a bound param is not a filter

The in-memory aggregator filtered by metric_key correctly. The SQL compiler bound a metric parameter into the query... and never referenced it in the WHERE.

With a single series in the dataset, it worked by accident — there was nothing else to sum. Add a second series and the math quietly breaks: the query sums across every series. In this case the second series stored hashed values around 1.9 billion each, so the KPI ballooned from 819 to 163 billion.

	Before	After
`metric` value	bound, unused	bound
`WHERE` predicate	(none on metric)	`metric_key = {metric:String}`
1 series in dataset	correct (by luck)	correct
N series in dataset	sums across all	isolated

The lesson is small and easy to miss: binding a parameter only makes the value available — it does nothing until a predicate references it. When one path already returns sane-looking numbers, nobody goes looking.

The real fix is parity, not a patch

You could bolt the predicate onto the one broken query and move on. Better: put shared predicates in one place so every compile path inherits them by construction.

            ┌─────────────────────┐
 query  ──▶ │  basePredicates()   │  ◀── metric_key = {metric}
            │  (shared WHERE)     │      tenant_id  = {tenant}
            └──────────┬──────────┘
                       │
        ┌──────────────┴──────────────┐
        ▼                             ▼
  push-down SQL                 in-memory aggregator
  (big datasets)                (preview / small)
        └──────────────┬──────────────┘
                       ▼
                same number

When two code paths must agree, pin the agreement in a test — don't just test each path alone.

it('isolates every metric query by metric_key', function () {
    foreach ([CompilePath::PushDown, CompilePath::InMemory] as $path) {
        $sql = (new MetricCompiler($path))->compile(
            metricKey: 'record_count',
            tenantId: 'acme',
        );

        expect($sql->wherePredicates())
            ->toContain('metric_key = {metric:String}');
    }
});

Takeaway

Any time you have a fast path and a correct path for the same value, write the test that asserts they produce the same filter — and the same answer. The gap between "works on my one-series sample" and "sums a billion rows in production" is exactly one missing predicate. Drift between two paths is where the absurd-number bugs live.

Dev Log: 2026-06-29

Nasrul Hazim Bin Mohamad — Tue, 30 Jun 2026 00:03:59 +0000

TL;DR

Two threads today: an organization layer on top of an existing multi-tenant app, and driver-based password-reset backends in an identity portal. Both came down to the same idea — put the source of truth in the right place, then test it.

Multi-tenant app: an organization layer above tenancy

The product already had tenancy. What it lacked was a human-friendly layer on top: organizations users actually belong to, can switch between, and manage.

What landed:

Area	Change
Org switcher	A sidebar switcher to move between organizations you belong to
Management	Create/update org, invitations, ownership transfer
Tenancy	Resolve the active tenant from the user's org — closed a leak
UI	Dark-mode pass + responsive fixes across the org views
Dashboards	Richer per-widget configuration from the UI

The standout is the tenancy fix: the active tenant was being resolved from the request instead of the authenticated user. I pulled that into its own focused post — "Resolve the tenant from the user, not the request." Short version: if a value scopes data, it can't come from something the client controls.

Identity portal: make the reset backends swappable

The password-reset flow needed to support more than one backend, and let an admin decide the order they run in. Classic case for a driver-based abstraction — a contract plus interchangeable drivers, picked at runtime from config.

interface PasswordResetBackend
{
    public function reset(User $user, string $password): void;
    public function name(): string;
}

Two optional backends came back as drivers behind that contract, and the run order is now admin-reorderable instead of hard-coded. Adding a third backend later is a new class + a config line — no touching the flow itself.

The other half of the day was unglamorous but necessary: the test suite had drifted — stale tests for removed features, and env leakage between tests (one test's state bleeding into the next). Fixed the leakage, deleted the dead tests, and the suite is honest again.

Takeaway

Two different apps, one lesson repeated: decide where the truth lives (the user's org; the config-driven driver), make the boundary explicit, and pin it with a test. Everything else is UI.

Dev Log: 2026-06-28

Nasrul Hazim Bin Mohamad — Tue, 30 Jun 2026 00:03:45 +0000

TL;DR

Centred a sidebar brand mark in the collapsed rail (open-source starter kit) — pure CSS, no JS.
A CRM app got a "daily cockpit" dashboard (hot leads + overdue follow-ups) plus a full favicon/PWA icon set.
An analytics product's ingest pipeline learned to handle messy uploads — files with no date column and no numeric measure — and a nasty metrics bug got squashed.

A spread day across three repos. Quick tour.

Centring a collapsed sidebar logo (CSS only)

Kickoff, my open-source Laravel starter kit, had a small visual snag: when the sidebar collapses to a narrow rail, the header switches to a column — but the brand mark sat off-centre. The content area is ~72px, yet the logo kept its width and a leftover space-x margin, nudging it left of the nav icons.

No JavaScript needed. Make the logo and toggle full-width, centre their content, and zero the leftover child margins when collapsed:

[data-flux-sidebar][data-collapsed] .sidebar-header .app-logo {
    width: 100%;
    justify-content: center;
    padding-inline: 0;
}
/* kill the leftover space-x margin pushing it off-centre */
[data-flux-sidebar][data-collapsed] .sidebar-header .app-logo > * {
    margin: 0;
}

Lesson: when a flex container changes direction, old horizontal margins don't disappear — they just push things in the new axis. Tag the element, scope the override to the collapsed state, done.

A CRM "daily cockpit"

A CRM app I work on got a dashboard rebuild: instead of a generic landing screen, the first thing you see is what needs action today — hot leads and overdue follow-ups. The cockpit framing matters more than the widgets: surface the work, don't make people hunt for it. Also shipped a full favicon/PWA icon set and a branded responsive landing page, with feature tests so the brand pass didn't quietly break routing.

Ingest that survives real-world files

The bigger chunk of the day went into an analytics/dashboard product's ingest pipeline. Real uploads are messy, so the pipeline now copes with the awkward shapes:

Awkward file	Handling
No date/period column	Derive the snapshot period from the filename (`report-2026-06.xlsx` → `2026-06`), else ask or use upload time
No numeric measure	Let the user choose the aggregation (e.g. count rows) instead of failing
Dirty columns	A data-quality panel flags blanks, near-duplicate "variant clusters" (`A & B` vs `A And B`), and encoding mojibake before anything reaches a dashboard

The upload flow also got simpler: drop a file → instant clean dashboard, with column mapping tucked behind an Advanced step for the cases that need it.

And the bug of the day — a metrics query that summed across every series in a dataset and turned an 819 KPI into 163 billion. That one earned its own write-up: "When a KPI reads 163 billion instead of 819."

What's next

More ingest edge cases (filename date formats, transforms), and rolling the centred-rail fix into the other apps that share the sidebar.

Dev Log: 2026-06-27

Nasrul Hazim Bin Mohamad — Sat, 27 Jun 2026 15:44:00 +0000

TL;DR

Shipped a composer share command + reverse-proxy trust so a local Laravel app can be tested over a public HTTPS tunnel without mixed-content errors.
Built a self-serve onboarding flow: upload a spreadsheet, a wizard maps the columns and auto-builds a metric and a dashboard.
Added a CRM intake pass: bulk contact import (paste/CSV/Excel) with duplicate detection + merge, web lead capture via UTM, and an activity timeline feeding a lead-scoring engine.

Busy day across four repos. Grouping by theme, not commit order.

Public tunnels for local apps

The standout (full write-up: cleaniquecoders/kickoff): sharing a local app over a Cloudflare/ngrok tunnel kept breaking on mixed content because php artisan serve is HTTP behind an HTTPS proxy. Fixes — trustProxies(at: '*') so X-Forwarded-Proto is honoured, plus pointing APP_URL/ASSET_URL at the tunnel URL. Bundled into one composer share command that restores .env on exit.

Self-serve data onboarding

Across an analytics app, the theme was killing setup anxiety. The win: an upload-to-dashboard wizard where you drop a spreadsheet and it does the rest.

Step	What it does
Upload	Accept an `.xlsx`, show a raw-data preview
Map columns	Smart defaults + guidance; each value column becomes its own metric
Validate	Friendly errors for duplicate metric key / board slug instead of a DB exception
Build	Auto-create the metric + a starter dashboard from the mapping

Two details I liked: auto-deriving a Title-Cased label from the column name, and shipping ~30 industry sample datasets so a new user can click "try an example" instead of hunting for a file.

CRM intake + lead scoring

On the CRM side: getting leads in and ranking them.

Bulk import — paste, CSV, or Excel. Missing name? Derive a Title-Cased one from the email; keep existing app users out of the funnel; map Status/Type and Source columns.
Web lead capture — a UTM-aware intake endpoint with duplicate detection and a merge tool.
Activity timeline + scoring — each logged activity raises a contact's score via a listener; a scheduled command decays stale scores so the ranking reflects recent engagement, not all-time noise.

The package-worthy bit is the scoring flow: event (ActivityLogged) → listener (AwardScoreForActivity) → a service applying rule-based points, with a scheduled decay command. Side effects stay out of the controller.

Also landed a small "MCP Tokens" settings page across apps — mint/revoke personal access tokens for MCP access.

What's next

A Pest pass on the wizard's column-mapping edge cases (duplicate keys, empty columns), and a driver-based abstraction for the scoring rules so point values aren't hard-coded. Tomorrow's problem.

Share Your Local Laravel App on a Public URL Without Mixed-Content Hell

Nasrul Hazim Bin Mohamad — Sat, 27 Jun 2026 15:43:17 +0000

TL;DR

Exposing a local Laravel app over a public HTTPS tunnel breaks two ways: assets load from your localhost (teammate sees no CSS), and php artisan serve speaks plain HTTP behind the HTTPS proxy, so Livewire/Flux emit http:// URLs that the browser blocks as mixed content.
Fix the protocol with trustProxies(at: '*'), and fix the asset origin by pointing APP_URL + ASSET_URL at the tunnel URL.
I wrapped the whole thing in a composer share command that builds assets, opens the tunnel, rewrites .env, and restores it on exit. It's in cleaniquecoders/kickoff.

The problem

You want a teammate to click through your work-in-progress without deploying. The classic move: cloudflared tunnel (or ngrok) gives you a public https://... URL pointing at your local php artisan serve.

Then two things go wrong.

Symptom	Cause	Fix
Teammate sees raw HTML, no styling	`@vite` points at the Vite dev server on your localhost (`public/hot` exists)	Build assets, delete `public/hot`
Console: "mixed content blocked", random 419s	Proxy is HTTPS but `artisan serve` is HTTP → `request()->isSecure()` is `false` → `http://` asset/script URLs	Trust the proxy + set `ASSET_URL`

Fix 1: trust the proxy

The tunnel terminates TLS and forwards plain HTTP to your app with an X-Forwarded-Proto: https header. Laravel ignores that header unless you tell it the proxy is trustworthy.

// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    // Honour X-Forwarded-Proto from the tunnel so isSecure() is true
    // and Livewire/Flux emit https:// URLs (no mixed-content blocks).
    $middleware->trustProxies(at: '*');
    // ...
})

at: '*' trusts any proxy. That's fine for a throwaway tunnel on your own machine. In production, trust specific load-balancer IPs instead — a wildcard there lets a client spoof the forwarded headers.

Fix 2: point assets at the tunnel

Even with HTTPS detected, @vite and asset helpers resolve against APP_URL. If that's still http://localhost, the public visitor's browser tries to fetch your localhost. So rewrite both to the tunnel URL once it's up:

# wait for the tunnel to print its public https URL, then:
set_env APP_URL   "$PUBLIC_URL"
set_env ASSET_URL "$PUBLIC_URL"
php artisan config:clear

The one habit that saves you: back up .env first and restore it on exit, so a throwaway URL never gets left behind in your config.

ENV_BACKUP="$(mktemp)"; cp .env "$ENV_BACKUP"

cleanup() {
    rm -f public/hot
    cp "$ENV_BACKUP" .env   # restore APP_URL / ASSET_URL verbatim
    php artisan config:clear >/dev/null 2>&1 || true
}
trap cleanup EXIT
trap 'exit 130' INT TERM

One command

Wrapped together, composer share does the boring sequence every time: npm run build → rm public/hot → php artisan serve → open a Cloudflare (or ngrok) tunnel → scrape the public URL → set APP_URL/ASSET_URL → stream output until Ctrl+C → restore .env. Cloudflare's quick tunnel needs no account, so it's the default.

composer share
  │
  ├─ npm run build         (real assets, not the dev server)
  ├─ rm public/hot         (stop @vite pointing at localhost)
  ├─ php artisan serve     (:8000)
  ├─ cloudflared tunnel    -> https://xxxx.trycloudflare.com
  ├─ set APP_URL+ASSET_URL -> that url, config:clear
  └─ Ctrl+C -> restore .env, drop public/hot

Takeaway

The tunnel was never the hard part — the protocol mismatch was. Trust the forwarded proto, anchor your asset URL to the public host, and always restore .env. Bundle it into one command so "send me a link" takes five seconds, not five minutes of debugging blank CSS.

Code lives in cleaniquecoders/kickoff.