- What is awcodes/richie and what does it actually do?
- Richie is a lightweight Laravel package for working with rich text content. It ships a Tiptap/ProseMirror editor field that mounts inside a Filament v3 panel form, plus a Blade directive and helper for outputting stored content as markup in one line. The wider pitch is a fluent, chainable API for cleaning and transforming HTML with configurable allow-lists instead of scattering strip_tags() and regex through your views. Note that the authoring side (the Filament field) and the render side (JSON to HTML) are the two halves you must verify separately.
- Does Richie require Filament, or can I use it in a plain Laravel app?
- The editor field only has a surface to attach to if you are already running Filament v3, because it is a form field that composes into Filament resource forms. If you are not on Filament, you should evaluate Filament adoption as a separate, much larger decision before letting an editor requirement pull a whole admin framework into your architecture. The Blade rendering and HTML transformation helpers are more standalone in spirit, but confirm against src/ whether they load without Filament present.
- Which Laravel and PHP versions does Richie support?
- Richie targets Filament v3, which in practice means Laravel 10 or 11, so treat that as the supported matrix until the composer.json says otherwise. Version 0.1.3 is an early-line release, so read the constraints in composer.json on a clean checkout rather than assuming your existing lockfile is representative. If you are on Laravel 12 or Filament v4, assume incompatibility until proven otherwise.
- How do I install awcodes/richie with Composer?
- Install with composer require awcodes/richie:0.1.3, pinning the exact patch rather than using a caret range on a 0.1 line with a single maintainer. Publish the config file with the vendor:publish tag documented in the README, and review what it exposes before accepting defaults. Confirm the asset story on a clean checkout, since you need to know whether assets are precompiled or whether an admin form control now sits downstream of your own Vite build.
- How do I render rich text content in a Blade view with Richie?
- Richie provides a Blade directive and a helper so you can output safe markup in a single line instead of hand-rolling tag stripping in templates. The intended architecture is to persist Tiptap JSON as the source of truth and derive HTML at render time, optionally storing the rendered HTML alongside for search and indexing. Before committing, verify in the source that the JSON to HTML render path actually ships at 0.1.3 and is not just roadmap, and confirm the real namespace and make() signature during your spike.
- How do I configure which HTML tags and attributes are allowed?
- Richie uses configurable allow-lists for tags and attributes, exposed through a publishable config file, which keeps sanitization policy in one place rather than spread across views. Publish the config and read it line by line before accepting the defaults, because sensible defaults for a short bio are not the same policy you want for long-form articles or syndicated content. The fluent, chainable API lets you apply cleaning and transformation steps per render where a single global allow-list is too blunt.
- Does Richie sanitize user-generated content well enough for public output?
- Sanitization posture is unverified in this repository, so do not assume it replaces a sanitizer you own and control. Editing inside a Filament admin is semi-trusted, but any surface where output reaches a browser without your own sanitizer, such as public UGC, syndicated content, email export, or anything compliance-sensitive, should be considered out of scope until that gap is closed. This is a product decision with a safety dimension, not a technical preference, so settle it before launch rather than after.
- Is Richie 0.1.x stable enough to use in production?
- Treat it as early-line software: three patches into a 0.1 series, one maintainer, and effectively no dependents means nobody has hardened it against your use case and you will be first through most edge cases. Pin awcodes/richie:0.1.3 exactly, never a caret range, and name an internal owner plus a fork-and-vendor trigger before you ship. The 0.1.3 changelog is a single line about actions registering on the editor instance rather than globally, which is a correctness fix but also evidence the toolbar API is still settling.
- What is the biggest production risk with a Filament rich text field like Richie?
- The realistic incident is not an outage, it is silent content loss: an asset-pipeline or Filament bump breaks editor hydration, the field renders blank, the form saves blank content over a good document, and nobody notices until an author complains. A save-time guard that rejects empty-over-nonempty is cheap insurance and should be a launch requirement, not a nicety. Two other unknowns to close in your spike are whether assets are precompiled and where image uploads land, since Richie may delegate to Filament's uploader or medialibrary rather than owning storage itself.
- Can I extend Richie with custom elements, handlers, and toolbar actions?
- Yes, the package advertises extensible handlers for custom elements, and toolbar actions can be configured per field or through named profiles so a short bio and a long-form article get different editors. That composition model matches how content teams actually want editors to differ, and it means no bespoke JavaScript in your resource forms. Because the action API was still changing as of 0.1.3, keep customizations thin and re-test them on every patch upgrade, and read src/ yourself so you can patch it during an incident.