- How do I install caouecs/sirtrevorjs in a Laravel app?
- Run composer require caouecs/sirtrevorjs, then publish the package config and views with the vendor:publish command so the Sir Trevor settings and Blade partials land in your application. Laravel 5.5 and later auto-discovers the service provider and facade, so no manual registration is needed on supported versions. After publishing, check the config file for the block type map and editor options before you touch any Blade template. Do the install on the exact Laravel version you plan to ship, because Composer constraint resolution is the most common failure point.
- Which Laravel versions does caouecs/sirtrevorjs support?
- The package advertises support through Laravel 9 and relies on package auto-discovery introduced in 5.5. Composer resolution on Laravel 10, 11, or 12 is not guaranteed and typically requires a fork with updated illuminate/support constraints. Verify it against your target framework version in an isolated branch before committing to adoption. If your roadmap is Laravel 10 or newer, isolate the renderer behind your own service so a later swap is cheap.
- How do I render the Sir Trevor editor inside a Blade form?
- Add the @sirtrevor directive inside your form where the editor should appear, and it outputs the editor markup plus the required bootstrap. Post the resulting block JSON to your controller like any other form field, since the package works with standard submissions and needs no API changes. Drive behaviour such as block types and editor options from the published config rather than hardcoding values in the template. Keep the field name consistent with the column and validation rules your controller expects.
- How do I render saved Sir Trevor block JSON as HTML?
- Call SirTrevorJs::render($json) with the stored block JSON and the package converts each block into HTML through its configurable converters and Blade partials. The converter config is the intended customization seam, so change block mappings there instead of editing vendor files. Because the result is raw HTML, sanitize it before echoing it into a page. Store the original JSON alongside the rendered output so you can re-render later without re-opening the editor.
- Does the package include the Sir Trevor JavaScript and CSS assets?
- The publish step is meant to place the editor config and view assets into your application, but the Sir Trevor JavaScript build is effectively app-owned. Sir Trevor requires jQuery plus its own stylesheet, so plan for asset pipeline work on your side, especially when moving from Laravel Mix to Vite on newer Laravel versions. Confirm exactly what lands in public/vendor after publishing and whether the inline editor scripts conflict with a strict Content Security Policy. Self-hosting the JavaScript is the safer default for production.
- Can I add custom block types or override the rendered block views?
- Yes. Block types and editor options come from the published config, and each block is rendered through Blade partials you can override in your resources/views/vendor directory. Truly new block types need a matching JavaScript definition on the editor side plus a PHP partial or converter on the render side, so treat them as paired work. Keep your overrides in version control because package updates can change the published views, and check for collisions with your own view namespace.
- Does it handle image uploads, validation, or HTML sanitization?
- No. The package is a rendering adapter, so persistence, validation, image and video upload endpoints, sanitization, and storage conventions are all your responsibility. Sir Trevor blocks can carry arbitrary HTML and embed URLs, so run the converted output through a sanitizer such as HTML Purifier and validate the JSON shape on save. Build upload endpoints that write to your own disks and return URLs the editor can reference. Treat every stored block as untrusted input, including ones submitted by trusted editors.
- How should I store Sir Trevor content in the database?
- Cast a JSON or longText column to array on your Eloquent model and persist the raw block JSON exactly as the editor submits it. Also store the rendered HTML and a plain-text rendition so search indexing and any future renderer swap do not require a content migration. Add a schema version key to the payload so you can detect and handle older documents later. Never treat the package's rendered output as your only copy of the content.
- Is caouecs/sirtrevorjs still maintained, and what are the alternatives?
- Adoption signals are thin and the underlying Sir Trevor editor is aging compared with Tiptap, Editor.js, ProseMirror, or the rich text editors shipping in Filament. The MIT license is a genuine upside because it lets you fork the package and take internal ownership, but you should budget for that ownership from day one. On greenfield builds or Laravel 10 and newer, time-box a spike on a maintained editor before adopting this one. Use this package mainly to cut wiring effort while you evaluate a replacement.
- What production risks should I review before shipping with this package?
- Expect XSS risk from unsanitized block HTML, CSP friction from inline editor scripts and oEmbed iframes, and asset pipeline breakage when you migrate from Mix to Vite. Composer constraint conflicts on framework upgrades are common, and the package advertises no support past Laravel 9. Mitigate by sanitizing all rendered output, self-hosting the JavaScript, and wrapping the facade in an internal ContentRenderer service so call sites do not bind to it. Review the jQuery and Sir Trevor versions in use for known vulnerabilities, and check accessibility and RTL behaviour in both the editor and the rendered output before launch.