Forem: BuildWithTall

How to Extend Filament v5's Register Page

BuildWithTall — Fri, 01 May 2026 13:41:43 +0000

Filament v5 ships a native register page. Some plugins ignore it and roll their own controller. Here's how we added captcha, honeypot, role assignment, and event bridging — entirely through Filament's documented hooks, without touching register() itself.

Filament is one of the best backend frameworks for Laravel. It builds admin panels fast, looks great out of the box, and is deeply extensible. But most non-trivial projects don't stop at the backend. If you're building a SaaS, a web app with a public-facing portion, or anything with real users signing up, you eventually need authentication that lives outside the admin shell.

A common answer is to reach for one of Laravel's official starter kits. The modern lineup — React, Vue, and Livewire flavours, all with auth scaffolding baked in — is the path most teams take today, and earlier kits like Breeze and Jetstream from the Laravel 10.x era are still maintained and widely deployed. They're battle-tested, beautifully documented, and a great fit for many projects: they handle public-facing auth completely while letting Filament focus on the admin side. For plenty of teams that separation is exactly what you want, and these kits absolutely deserve their place in the Laravel ecosystem.

That said, if you'd rather harden your authentication and roll your own using Filament, you don't need to reach outside the framework — Filament v5 already has everything you need to extend. It ships a complete auth flow — \Filament\Auth\Pages\Login, \Filament\Auth\Pages\Register, email verification, password reset, and multi-factor authentication — and these aren't just admin-panel utilities. They're real, themable, extensible pages you can put in front of your users.

The catch: the register page in particular needs work before it's production-ready. Out of the box there's no captcha, no honeypot, no role assignment, no Laravel-event bridge for listeners that other parts of your app already depend on. Most plugins solve this by reaching for a custom Laravel controller, a Blade form, and manual validation — abandoning Filament's auth flow entirely.

We took the other approach while building tallcms/filament-registration(Link). Every production feature — captcha, honeypot, rate limiting, default role assignment, post-registration redirect — landed inside Filament's documented extension points. We never overrode register(). These patterns apply to any Filament v5 project that needs a public register page without leaving the framework.

The Core Idea: Two Hooks, Not One Override
Filament's Register page exposes two extension points :

mutateFormDataBeforeRegister(array $data): array — runs after validation but before User::create(). The place for anything that should gate registration.

handleRegistration(array $data): Model — wraps user creation. The place for anything that should run after the user exists.

The temptation, especially if you're porting from a legacy controller, is to override register() and rebuild everything inside one method. Don't. Filament's register() already orchestrates throttling, validation, email verification, response dispatch, and event firing. You won't get all those right by rewriting it. You don't need to.

class Register extends \Filament\Auth\Pages\Register
{
    public function form(Schema $schema): Schema
    {
        return $schema->components([
            $this->getNameFormComponent(),
            $this->getEmailFormComponent(),
            $this->getPasswordFormComponent(),
            $this->getPasswordConfirmationFormComponent(),
            HoneypotField::make(),
            CaptchaField::make(),
        ]);
    }

    protected function mutateFormDataBeforeRegister(array $data): array
    {
        $this->checkHoneypot($data);
        $this->throttleCaptcha();
        $this->verifyCaptcha($data);

        unset($data[$this->honeypotField], $data[$this->tokenField]);
        return $data;
    }

    protected function handleRegistration(array $data): Model
    {
        $user = parent::handleRegistration($data);

        $this->maybeMarkEmailVerified($user);
        $this->maybeAssignDefaultRole($user);
        event(new \Illuminate\Auth\Events\Registered($user));

        return $user;
    }
}

That's the entire shape. Everything below is what goes inside those methods.

Layer 1: Honeypot via Validation, Not Stealth
The legacy approach to honeypots is to silently render a fake success page when the field is filled, hoping the bot logs a false positive. It works, until it doesn't — modern bots roll their own success-page detectors.

A cleaner approach inside Filament: throw a ValidationException. Filament catches Laravel's validation exceptions automatically and surfaces the message on the form. Bots that don't fill the honeypot get through validation; bots that do see a generic "Bot check failed" message attached to the honeypot field.

if (! empty($data[$this->honeypotField])) {
    throw ValidationException::withMessages([
        $this->honeypotField => 'Bot check failed. Please try again.',
    ]);
}

Layer 2: Rate-Limit Before You Verify
Layer 3: Pluggable Captcha via a Contract
Layer 4: Two-Layer Config (Env + Admin UI)
Layer 5: Container-Bound Redirects

We have shared this in details on this blog

Going Full Native: How to Extend Filament v5's Register Page

tallcms.com

How to Turn Filament v5's Rich Editor Into a Full Block Editor

BuildWithTall — Wed, 29 Apr 2026 03:43:26 +0000

Filament v5's RichEditor is powerful out of the box. It is built on Tiptap, which means it's natively extensible, and it now supports *custom blocks out of the box . Here's how to extend it into a categorized, searchable block editor — without forking a single line of Filament core.

With the release of Filament v5, one of the biggest improvements is the switch to a Tiptap-powered Rich Editor which means it's natively extensible, and crucially it now supports custom blocks out of the box via the RichContentCustomBlock base class.

This is a huge deal. You can define structured, configurable content blocks that live inside the rich text flow — not bolted on as a separate Builder field, but inline with your prose. Each block gets a unique ID, a modal form schema, and preview/render methods. For most applications, this is more than enough.

But once you're past a handful of blocks — say you've got 15+ block types across categories like Content, Media, Social Proof, and Forms — the default flat list becomes unworkable. There's no search, no categorization, no visual cues to tell a Hero apart from a FAQ. Your editors start scrolling through a wall of block names.

While building a Laravel CMS, we hit exactly this wall. Rather than build a page builder from scratch, we extended Filament's block system layer by layer. These patterns are applicable to any Filament project with non-trivial block usage — CMS or not.

Layer 1: Extending the Editor Component

The first step is surprisingly clean. Create a class that extends RichEditor and swap in your own Blade view:

`<?
class EnhancedRichEditor extends RichEditor

{
protected function setUp(): void
{
parent::setUp();
if (static::isFilamentCompatible()) {
$this->view = 'filament.forms.components.enhanced-rich-editor';
}
}
}`
No monkey-patching, no service container tricks. Filament lets you override the view on any form component, so you get full control over the block panel UI while the editor internals stay untouched. The version check provides a graceful fallback to the standard panel on unsupported versions.

Layer 2: Auto-Discovery With Override Precedence

If your project is a package or supports plugins, you'll want blocks from multiple sources. A discovery service with reflection-based auto-discovery solves this — scan directories for classes extending RichContentCustomBlock, then deduplicate by block ID so that later sources override earlier ones:

Package blocks (base defaults)
App blocks (developer overrides)
Plugin blocks (override all)

A developer drops a CallToActionBlock in their app/Filament/Blocks/ directory and it automatically replaces the package default. No configuration, no registration — just convention.

The discovery service also collects metadata from each block — label, icon, description, search keywords, category, sort priority — which powers the enhanced UI in the next layer.

Layer 3: Composable Block Traits

Once you have more than a few blocks, you'll notice they share a lot of form fields — button styles, background colors, spacing, animations. Copy-pasting across blocks is a maintenance nightmare. Traits solve this:

`<?php
class CallToActionBlock extends RichContentCustomBlock

{
use HasBlockMetadata; // Category, icon, description, keywords
use HasBlockIdentifiers; // Anchor IDs, CSS classes
use HasContentWidth; // Per-block width control
use HasStylingOptions; // Button variants, colors, spacing
use HasAnimationOptions; // Scroll-triggered entrance effects
}`
Each trait provides both form schema sections (for the editor modal) and rendering helpers (for the frontend). Adding a new block becomes mostly about defining its unique content fields — the styling, animation, and metadata layers come free.

If you're using a component library like daisyUI, you can map styling options directly to its semantic classes btn-primary, bg-base-200). This gives you theme switching for free — every block re-skins automatically when the theme changes.

Please read the rest of this article here https://tallcms.com/blog/extend-filament-v5-rich-editor-block-editor

The SEO-era CMS is dead. Here's what comes next.

BuildWithTall — Mon, 06 Apr 2026 15:24:22 +0000

Search visibility still matters. But the next advantage is making content structured, attributable, and maintainable.

WordPress became the dominant CMS by solving a real problem: making it easy to publish crawlable, keyword-targetable content. Install Yoast, fill in the meta description, hit publish. Google does the rest. That playbook still works — but it's no longer sufficient.

When someone asks ChatGPT, Perplexity, or Claude a question, the answer isn't a list of ten blue links. It's a synthesised response drawn from sources that were readable, attributable, and trustworthy. Your content either makes it into that synthesis — or it doesn't.

The right question isn't "how do we optimise for AI?" That framing chases the wrong things. The better question is: what does it mean for content to be genuinely legible in 2025?

What "legible" actually means

Legibility isn't a new concept. It's what good semantic HTML has always been about — content that's meaningful to the medium it travels through, not just to the human reading it in a browser.

In the SEO era, legibility meant clean URLs, descriptive title tags, heading hierarchy, and internal links. These still matter. But AI systems extract meaning differently than crawlers do. They look for:

Structured data — not just as an SEO signal, but as a machine-readable contract about what this content actually is
Attributability — who wrote this, when, and what makes them credible
Extractability — does a paragraph answer a specific question, or does it meander?
Freshness signals — when was this last verified? Is it still accurate?

A CMS that makes these easy to produce by default — not via plugins bolted on afterward — has a structural advantage in the current landscape.

What to be careful about

Before going further, some of the "AI-optimised CMS" conversation is moving faster than the evidence warrants. A few claims worth scrutinising:

"llms.txt is the new robots.txt" is an interesting emerging convention, but not yet a stable enough foundation to build a product strategy around. Worth supporting if it matures. Not a core thesis today.

"AI tools consume content via APIs, not browsers" is overstated. Many AI systems still rely on crawlable, rendered HTML. API-first is genuinely valuable — but clean public HTML remains equally critical.

"Structured content will be cited by AI more reliably" involves factors well outside any CMS's control. The honest version: structured, well-attributed content is more extractable and more likely to survive summarisation intact. That's still a meaningful claim — but it's not a guarantee.

These cautions matter because the worst version of this thesis is a CMS that chases AI hype instead of building something durable. The best version focuses on what has always mattered: clear, structured, trustworthy content. AI legibility is a consequence of doing those things well, not a separate goal.

Content maintenance is the missed layer

Almost every CMS treats content creation as the primary workflow. Content maintenance — reviewing, updating, verifying — is an afterthought.

AI systems are exposing this gap. Stale content isn't just an SEO liability anymore. It's a trust signal. A well-maintained corpus that reflects current reality is more useful as a source than a site that published 400 posts in 2021 and stopped updating.

A CMS that surfaces stale content proactively — "this article was last reviewed 18 months ago, here are five that haven't been touched in two years" — is doing something valuable that almost nobody has built well yet.

The winning CMS in this era makes content maintenance as easy as content creation. That's a smaller, more tractable problem than "building an AI CMS" — and a more durable one.

What this means for TallCMS

We're building TallCMS around the idea that content should be legible to humans, search engines, and AI systems alike. Concretely, that means:

Schema-first content types. When you add an FAQ block, a how-to guide, or a product page, the appropriate structured data is generated automatically. Schema.org markup is a primitive, not a plugin.
First-class attribution and review metadata. Author credentialing, last-reviewed dates, and expert attribution are real fields in the editor — not custom meta buried in settings.
Maintenance workflows over AI gimmicks. Stale content detection, review reminders, and freshness indicators built into the editorial experience.

TallCMS's block system already stores content as typed, structured data — not WYSIWYG blobs. The leap from structured blocks to structured data output is small. That's a genuine architectural advantage, not a marketing claim.

What we're deliberately not doing

Saying no is as important as saying yes. Here's what we're choosing not to build:

AI content generation in the editor. We're not adding a "write this for me" button. AI-assisted quality — flagging thin content, suggesting structure — is useful. AI-replacing-authorship is not a CMS feature, it's a crutch.
Headless-only architecture. TallCMS is full-stack by default: admin panel, frontend, themes. The API is strong and well-documented for when you need it. But we're not abandoning the integrated experience to chase a trend.
Chasing llms.txt as a centrepiece. We'll support it if the convention stabilises. We're not building our product story around it.
Promising AI citeability. We can make content more extractable, more structured, and more trustworthy. We can't control what any AI system decides to surface. We won't pretend otherwise.

What to look for in any CMS

Regardless of which CMS you use, here's what matters most in the current landscape:

Schema-first content types — structured data as a primitive, not a plugin
Author and expert attribution — first-class fields, not custom meta
Last-reviewed / last-verified metadata — surfaced to editors, not just stored
FAQ and Q&A blocks with clean semantic output — automatic Schema markup
Clean API output — headless-capable without being headless-only
Stale content detection — proactive, not on-demand
llms.txt generation — a nice extra, not the centrepiece

The bottom line

WordPress won because it made publishing accessible. The next era rewards something different: making content genuinely trustworthy and extractable at every level of the stack.

The CMS that wins isn't the one that bolts on AI features. It's the one that makes structured, well-attributed, well-maintained content the path of least resistance.

Built for how content gets discovered now — not how it got indexed then.

Why I Built My Own CMS (Again) — This Time with Laravel + Filament

BuildWithTall — Sat, 04 Apr 2026 14:35:53 +0000

Most developers don’t wake up thinking:

“You know what the world needs? Another CMS.”

And yet… here we are.

The Problem with Existing CMS (From a Developer’s POV)

I’ve worked with a lot of CMS platforms over the years — from WordPress to headless setups.

They all work… until you try to do something slightly different.

That’s when things get messy:

You fight plugins instead of building features
You bend your architecture around the CMS
You inherit years of legacy decisions you didn’t sign up for

At some point, I realized:

I wasn’t building products — I was working around the CMS.

The “What If” Question

So I started asking:

What if a CMS was built the way we build modern Laravel apps today?

Not constrained by legacy.
Not pretending to be everything for everyone.

Just:

Clean architecture
Developer-first
Extensible by design
Actually enjoyable to work with

Why Laravel + Filament?

If you’re in the Laravel ecosystem, this part will make sense.

Laravel gives you:

Structure without being restrictive
A clean service layer
First-class DX

Filament gives you:

A powerful admin panel out of the box
Forms, tables, actions — already solved
A consistent UI layer

Together, they solve 80% of what a CMS needs.

The remaining 20%?
That’s where things get interesting.

The Hard Parts (That No One Talks About)

Building a CMS isn’t about CRUD.

It’s about abstractions.

1. Content as Blocks (Not Fields)

What I wanted:

Flexible, composable content blocks

But that introduces problems:

How do you store them?
How do you version them?
How do you render them cleanly?

2. Editor Experience vs Developer Control

There’s always tension between:

Giving non-tech users flexibility
Keeping developers sane

Too flexible → chaos
Too strict → unusable

Finding that balance is harder than it sounds.

3. Plugin Architecture

I didn’t want:

“Just hack it into the codebase”

I wanted:

A system where features can be dropped in cleanly

Which means:

Discovery
Registration
Isolation
Extensibility points

I ended up building TallCMS, an open-source CMS powered by Laravel + Filament.

Current features:

Block-based page builder
Pages & posts
Publishing workflow (draft → scheduled → published)
Revision history
Media library
Menu builder
Plugin architecture

Still early. Still evolving.

Unexpected Lessons

1. Frameworks Matter More Than You Think

Working within Laravel + Filament constraints actually made things better.

It forced:

Consistency
Reusability
Less over-engineering

2. Agentic Coding Is Powerful… But Dangerous

I’ve been experimenting with AI-assisted development.

What I learned:

Without structure → chaos
With a clear plan → massive acceleration

I now always:

1. Generate a plan
2. Review it
3. Execute in controlled steps

3. CMS Is a Systems Problem

It’s not:

“Build pages”

It’s:

“Design a system that lets others build anything”

That shift changes everything.

Where This Is Going

I’m still exploring:

Better block composition
AI-assisted content creation
Multi-site architecture
Developer experience improvements

Curious What Others Think

If you’ve ever:

Built your own CMS
Fought with one
Or are happily using one

I’d love to hear:

What’s the one thing your CMS does really well — or really badly?

Closing

I’m building this as an open-source project called TallCMS.

Not trying to replace everything.

Just trying to make something that feels right for modern Laravel developers.

If you’re curious, happy to share more.