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
Top comments (0)