- How do I install tonysm/rich-text-laravel in a Laravel application?
- Install it with Composer using composer require tonysm/rich-text-laravel, then publish the package config and migrations. Run php artisan migrate to create the rich_texts table and any attachment tables. After that, add the HasRichText trait to the models that should have rich bodies and use the Blade x-trix-input component inside your forms. There is no queue worker, external service, or SaaS account required, so the install stays inside your normal Laravel deployment flow.
- Which Laravel and PHP versions does rich-text-laravel support?
- The package targets modern Laravel releases on PHP 8.1 and above, but you should always verify the exact constraints in its composer.json and release notes before committing. Laravel ships major versions faster than most package maintainers can track, so check that the tagged release you plan to use explicitly lists your Laravel and PHP versions. If you are on an older or brand-new Laravel release, run a quick install on a branch to confirm compatibility before rolling it out.
- How do I add a rich text field to an Eloquent model?
- Add the HasRichText trait to your model and declare which attributes should be treated as rich text, for example a body or content field. The trait wires that attribute to the polymorphic rich_texts relation, so reading the attribute returns the stored HTML body. You then fill it from the Trix input component in your form and persist the model as usual. Because the content lives in a separate table, there is no schema change to your existing model table.
- How do I render rich text without introducing stored XSS?
- Always render rich text through the package's renderer or sanitizer pipeline rather than dumping the raw column with {!! !!}. Treat sanitizer configuration as a security-reviewed part of your app, with an explicit allow list of tags and attributes, and make sure every output site, including emails, APIs, and Blade partials, uses the same path. A single unescaped echo of stored HTML is a stored-XSS vector, so this deserves a code review and ideally a test that asserts dangerous markup is stripped. Also decide how links, iframes, and inline styles are handled before you go live.
- How does rich-text-laravel store and serve image attachments?
- Attachments are stored through Laravel's filesystem disks, so local storage, S3, and other drivers work as long as the disk is configured correctly. Trix uploads are handled by the package's upload endpoint, which records the attachment and returns the URL the editor embeds in the HTML. You still own the hard parts: per-tenant authorization, signed or temporary URLs, file size limits, and virus scanning. Plan attachment retention and cleanup too, because deleting a record does not automatically delete every orphaned file.
- Can I use rich-text-laravel with Livewire or Inertia?
- Yes for Livewire: the package is Blade-first, so the x-trix-input component drops into a Livewire view, but you must make sure Trix content is synced into the Livewire property, often with a small Alpine or JavaScript bridge. Inertia apps can use it too when the form itself is rendered by a Blade page rather than a fully decoupled frontend. If your entire UI is a client-side SPA, the Blade and Trix assumptions start working against you. The package is strongest when the rendering layer stays in Laravel.
- Is rich-text-laravel a good fit for an API-only or headless frontend?
- Generally no. The package assumes server-rendered Blade, the Trix editor, and a relational rich_texts table, which adds friction when your frontend is a separate React, Vue, or mobile client. In a headless architecture, a JSON document editor such as TipTap, Lexical, or ProseMirror paired with a structured content store is usually a better shape. You can still use the package's storage model behind an API, but at that point you are keeping the database layer and discarding the parts that made it convenient.
- How do I migrate existing plain text or Markdown columns to rich text?
- Write a backfill that converts existing content into HTML and creates a rich_texts row for each record, while keeping the original column in place during a dual-read, dual-write transition. Conversion is lossy in both directions, so review a sample of migrated records and decide what to do with Markdown syntax, line breaks, and embedded images. Once the new field is verified, you can point reads at the rich text body and retire the old column in a later deploy. Large tables should be backfilled in chunks with a queued job rather than a single long-running migration.
- How do I customize which HTML tags and attributes are allowed?
- Publish the package config and adjust the sanitizer settings, then review the renderer to confirm it applies that configuration at every output path. Keep the allow list as narrow as your content actually needs, since every permitted tag and attribute expands your attack surface. Add tests that feed in script tags, event handler attributes, and javascript: URLs and assert they are removed. Because content policy is the real risk with this package, document who owns that config and require review for changes.
- What are the alternatives to Trix, and is this package actively maintained?
- Common alternatives include TipTap, Lexical, ProseMirror, and the rich editor bundled with Filament, all of which generally ship features and fixes faster than Trix. Trix is maintained by Basecamp with a slower cadence, so features like tables, markdown shortcuts, and collaborative editing may simply be out of scope. tonysm/rich-text-laravel is a capable but niche package with a small contributor base, so pin versions and keep a fork-readiness plan. If your app depends on long-term editor evolution, evaluate that maintenance risk before adopting it.