Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Filament Rich Editor Extra Laravel Package

mohamedsabil83/filament-rich-editor-extra

A Filament plugin that extends the RichEditor form field with extra toolbar buttons and formatting options, making it easier to build content-rich Laravel admin panels. Lightweight, configurable, and designed to drop into existing Filament forms with minimal setup.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Rich content authoring in admin panels without building an editor stack. If the product runs on Filament, this package extends the native RichEditor with authoring-quality-of-life tools rather than replacing it — a low-risk way to close the gap between "we have a rich text field" and "our editors actually enjoy writing in it."
  • Feature/roadmap trade-offs around editor investment. v1.4.0 adds Fullscreen and Sticky Toolbar extensions. Both are pure authoring-UX wins: fullscreen supports long-form drafting (articles, docs, policy pages, email bodies) where the standard field height becomes a constraint; sticky toolbar removes the "scroll up to find bold" friction on long content. These are the kinds of small additions that let a PM defer a much more expensive custom editor or third-party CMS integration by another quarter.
  • Build vs. buy, resolved cheaply. Two editor behaviours that would otherwise be a small internal engineering project arrive as configuration-level extensions. Each capability is a discrete product decision — enable fullscreen for long-form fields, sticky toolbar for any field that scrolls — rather than an all-or-nothing editor commitment.
  • Segmenting the editing experience by field type. Because the extensions can be applied per-editor, a PM can differentiate short fields (titles, captions) from long-form fields (body copy, notes, descriptions) without a second editor implementation.
  • Use cases that map directly to these features: editorial/blog workflows, internal knowledge bases and help centers, CMS-style page copy, customer-facing long descriptions, and any admin surface where non-technical staff write more than a sentence.

When to Consider This Package

Consider it when:

  • The product's admin surface is built on Filament and uses the built-in RichEditor — this package extends it rather than competing with it.
  • Content authors are non-technical and the length of what they write makes viewport and toolbar ergonomics a real complaint.
  • You want editor improvements incrementally and reversibly, field by field, without owning a fork of the editor.
  • The team is small and would rather absorb a maintained extension than staff ongoing editor maintenance.

Look elsewhere when:

  • The stack is not Filament, or the editor is a custom TipTap/ProseMirror build where these extensions would be re-implemented directly anyway.
  • Requirements include real-time collaboration, structured/block editing, digital asset management, or editorial workflow approvals — this package is an ergonomics layer, not a content platform; those needs point to a dedicated CMS or a much larger editor investment.
  • The content model is compliance-sensitive and you need vendor guarantees, SLAs, or audited output sanitization rather than a community-maintained extension.
  • You need a stable, frozen dependency surface — this is a small, single-maintainer package whose value is pace of small additions; teams that can't absorb periodic minor upgrades should treat it as optional polish, not infrastructure.

Practical guardrail: this is a UI enhancement package with a narrow blast radius. Treat adoption as a reversible product experiment — enable it on the highest-value long-form field, measure editor complaints/time-on-task, and expand only if it earns it.

How to Pitch It (Stakeholders)

For executives: This is a small, cheap upgrade to the writing experience inside our admin tooling. The latest release (v1.4.0) adds a fullscreen writing mode and a toolbar that stays visible while scrolling — the two things people ask for when they write anything longer than a paragraph. It's an extension to the editor we already use, not a new system, so the cost is configuration rather than engineering, and it can be turned on field by field and turned off just as easily. The decision it buys us is time: it defers a much larger editor or CMS investment while removing a recurring source of friction for the people who produce our content.

For engineering: We're extending Filament's native RichEditor with a maintained community package. v1.4.0 adds Fullscreen and Sticky Toolbar extensions — additive, opt-in, per-editor configuration. No schema changes, no data migration, no change to how content is stored or rendered. Risk is a small single-maintainer dependency: pin the version, review minor upgrades on our normal cadence, and keep adoption to fields where long-form authoring actually happens so backing it out stays trivial.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox