Weave Code
Laravel Nova Tiptap Field Laravel Package
wamesk/laravel-nova-tiptap-field
A Laravel Nova field that brings the Tiptap rich text editor to your admin panels, giving you a clean, extensible WYSIWYG experience for editing formatted content inside Nova resources.
At a glance
Frequently asked questions about Laravel Nova Tiptap Field
- How do I install wamesk/laravel-nova-tiptap-field in a Laravel Nova app?
- Install it with Composer alongside your existing Laravel Nova installation, then make sure the field assets are published and compiled through your host app's Node build pipeline, since Nova 4 and 5 expect a Vite or npm step. The package registers itself through a FieldServiceProvider, so no application domain code needs to change. After that you simply declare the field on a Nova resource and it renders in forms and detail views.
- Which Laravel Nova and Tiptap versions does this field support?
- The package is a Nova custom field built for the Nova 4 and 5 Vue 3 toolchain, wrapping a ProseMirror-based Tiptap editor in a Vue component. Version alignment is the main feasibility concern: the Nova major and the Tiptap major must be pinned together, because Tiptap major bumps are breaking for extensions. Pin the package, Nova, and Tiptap versions explicitly in composer.json and package.json and lock them before rolling out.
- Does the field store HTML or Tiptap JSON in the database?
- The field persists rich text through a standard Nova field, but the storage format, HTML string versus Tiptap JSON document, is a decision you must make and document explicitly rather than assume. Content consumers such as your front end, API, and search indexing all need to agree on that format up front, because it constrains everything downstream. Decide the sanitisation policy at the same time, since the field should not be treated as the sanitiser on render.
- Is the rich text output sanitised to prevent XSS?
- Rich text means HTML output, so XSS is a real surface and the package should not be relied on to sanitise on render. Treat sanitisation as the host application's responsibility and decide the policy explicitly before shipping. If you store HTML, sanitise on output and consider sanitising on input with a library such as HTML Purifier or a similar allowlist-based approach.
- Does the editor render correctly in index, detail, and form views?
- The 2.0.1 release fixed a rendering regression described as Showing editor, which suggests 2.0.0 shipped with at least one display-context defect. Before adopting it, run a short spike against your current Nova version and confirm the editor mounts correctly in create, update, and detail views. Add a smoke test for exactly those three contexts, since that is the surface the patch touched.
- Can I add custom Tiptap extensions or configure the toolbar?
- Tiptap's extension model is extensible, and teams with ProseMirror experience will find custom toolbar and extension work straightforward. Teams without that background should expect customisation to be non-trivial, especially around node and mark extensions. Plan any custom extension work as part of the initial spike rather than after rollout.
- Does the field support validation and maximum length rules?
- Because it is a standard Nova field, you should be able to attach Nova validation rules to it, but you need to confirm what the underlying value is at validation time, an HTML string or a JSON document, since max-length rules behave differently on each. Verify length limits against the stored format and not just the editor's visible content. Test required and max rules in your own spike before relying on them in authoring workflows.
- Does the Tiptap field support readonly or disabled states?
- Nova fields commonly expose readonly and disabled states, and this field renders in detail as well as form contexts, so you should verify both behaviours in your own Nova version. Confirm the editor properly disables input rather than just visually dimming the toolbar. This matters for workflows where content is locked after publishing or reviewed by a second role.
- How do I migrate existing Trix, Markdown, or HTML content to this field?
- Treat the field as greenfield for new content types first, then plan a one-way transform for existing rich-text columns and keep the legacy field available until the transform is validated. Because this is a young 2.x line with an undocumented 1.x to 2.x history, do not adopt it on a resource where content loss is unrecoverable; always take a backup and run a dry run. Validate the full round trip of create, save, reload, and render before removing the old field.
- Is this package actively maintained, and what are the risks?
- It is a single-maintainer package on a fresh 2.x major, with a short release history and a 2.0.1 patch that fixed a rendering regression, so expect further patch churn and no visible multi-maintainer governance or security policy. The bus factor and lockstep Nova upgrade risk are real, and a Nova 4 to 5 move will likely force a package upgrade with no migration tooling. It is a good fit if your team already standardises on Nova for admin authoring, and a poor fit if content authoring lives outside Nova or is exposed to non-admin users; otherwise evaluate a maintained alternative or a self-built Tiptap field.
Weaver
How can I help you explore Laravel packages today?