- What does murdercode/nova4-tinymce-editor actually do?
- It is a Laravel Nova 4 field package that replaces the default textarea with a full TinyMCE WYSIWYG editor inside your Nova resources. Content is still saved as a plain HTML string in an ordinary text or longText column, so there is no new data model or persistence layer to manage. You register it like any other Nova field, for example TinymceEditor::make('Body').
- How do I install the TinyMCE field in Laravel Nova 4?
- Install it with Composer using composer require murdercode/nova4-tinymce-editor, then run php artisan storage:link if you plan to use the image upload handling. Add TinymceEditor::make('Body') to the fields method of your Nova resource. The package's service provider registers its front-end assets, so there is no separate npm build step on your side.
- Which Laravel, Nova, and PHP versions are supported?
- The package targets Laravel Nova 4, and it is intended for applications running a Nova 4 compatible Laravel and PHP version. Because the package is community maintained with infrequent releases, you should confirm the exact constraint set in its composer.json before adopting it. Pin the version you validate and verify it against your Laravel and PHP matrix in a staging environment first.
- How do I customize the toolbar, height, or editor options per field?
- Each field accepts a per-field options array, so you can pass TinyMCE init settings such as the toolbar layout, height, or plugins via ->options([...]) without touching shared configuration. This keeps changes scoped to a single resource field and limits the blast radius if you tune one editor differently from another. You can also define defaults in the package config so most fields inherit sensible settings.
- Does the package include an image upload endpoint, and is it secure?
- Version 2.0.3 added an enabled upload API route, which moves the package from a pure editor widget to an editor plus an application file-upload endpoint. Before going live you must confirm the route sits behind Nova's authentication and authorization middleware, and verify validation of MIME type, file size, filename, and storage path server-side rather than only in the TinyMCE init config. Treat that security review as its own workstream with a named owner, since it is the real long pole in the integration.
- Which filesystem disk do uploaded images go to, and can I change it?
- Uploads are written through Laravel's filesystem abstraction, so the target disk is configuration-driven rather than hardcoded to a single path. Check the package config and the upload route in the source to confirm the default disk name and whether it can be overridden per environment. If you serve customer-facing content, keep the disk policy explicit and consider private storage plus signed URLs instead of a public disk.
- Is content from this editor safe from XSS, or do I need to sanitize it?
- TinyMCE outputs raw HTML, and the package stores that string as-is, so output sanitization remains your application's responsibility. Render the field through your existing HTML pipeline and run it through a sanitizer such as HTML Purifier on output, or sanitize on save if you prefer. Do not assume the editor alone protects you, especially if authors are not fully trusted.
- What are the maintenance and supply-chain risks of using this package?
- It is an MIT-licensed community package with a single primary maintainer, a small star count, and no dependents, so support is community-only and release cadence is not guaranteed. That is acceptable for internal admin authoring behind a gated pilot, but it is a poor fit as an unexamined dependency for regulated or customer-facing content pipelines. Document a fallback, such as a custom Nova field or a different editor, in case maintenance stalls.
- What are good alternatives if I want a WYSIWYG in Laravel Nova?
- Common alternatives include the built-in Nova textarea with markdown, other community Nova editor fields, or a custom Nova field wrapping the editor of your choice. The trade-off is usually maintenance burden versus control: a custom field costs more up-front but lets you own the upload route and sanitization policy completely. If you only need basic formatting, a markdown field may avoid the upload surface area entirely.
- How should I test and roll this out to production safely?
- Start with a non-production spike that installs the package, registers one field, and exercises the upload route end to end. Then verify that the route is authenticated and tenant-isolated if relevant, that MIME and size limits are enforced server-side, and that returned URLs resolve in your environment. Roll out behind a gated pilot for internal admin authoring, keep the previous field available as a rollback, and re-check behavior after any version bump since upgrades can change the upload handler.