Localtinymce Laravel Package

Product Decisions This Supports

• Editor selection inside Nova admin panels. This package provides a self-hosted TinyMCE field with image uploads, so it directly informs the "which rich-text editor do we standardize on for our Nova-backed internal tools?" decision. It is a narrow, single-purpose component, not a content platform.
• Build vs. buy vs. fork. At roughly a few hundred lines of glue code, the realistic decision is rarely "adopt as a dependency" — it is "vendor/fork this as a starting point" or "build the same thin wrapper ourselves in a day." Use it to price the build option.
• Self-hosting and data-residency posture. Because it removes the TinyMCE Cloud API key and any third-party editor SaaS from the request path, it supports decisions about on-prem/air-gapped deployments and keeping authored content and uploaded media inside your own storage.
• Storage and media pipeline roadmap. Image uploads mean files land on a Laravel filesystem disk. That forces explicit decisions on local vs. S3, public vs. private disks, CDN, image resizing/optimization, and retention — decisions that outlive whichever editor you pick.
• Licensing and compliance posture. TinyMCE's community edition carries copyleft-style terms in recent major versions and premium plugins are commercially licensed; this is a real input to a "self-host vs. paid editor" trade-off and should be reviewed before redistribution (e.g., in agency/client work).
• Content portability and XSS policy. Content is stored as HTML in a database column. That drives decisions on server-side sanitization, allowed-tag policy, and a migration path if you later switch editors or move to structured/block content.
• Concrete use cases it fits: internal ops dashboards, back-office CMS for small editorial teams, agency-delivered client apps already on Nova, and environments where external CDN/API calls are prohibited.

When to Consider This Package

Adopt (as a spike or a vendored fork) when:

• You already run Laravel Nova and need a rich-text field with inline uploads — the integration cost is genuinely low.
• You have a hard requirement for self-hosting, air-gapped operation, or no outbound calls to an editor vendor.
• The blast radius is small: admin-only, internal users, low traffic, no public content surface.
• You are prepared to own it. With zero stars, zero dependents, and a single maintainer, there is no community, no security-response process, and no upgrade guarantee. Assume you are the maintainer from day one.
• You will pin Nova and TinyMCE versions and budget time for major Nova upgrades (Nova's front-end moved to Vue 3, which historically broke field packages).

Look elsewhere when:

• Content is public-facing, regulated, or security-sensitive. Rich-text input is a top XSS vector; you need sanitization, audit trails, and a maintained patching story — not a zero-adoption package.
• You need support SLAs, security advisories, or a commercial counterparty.
• You need collaboration, comments, real-time co-editing, or AI assist — that is a different product category.
• You need structured content, blocks, localization workflows, or reusable media. Prefer a headless CMS, or compose Nova's native fields with a maintained media library (e.g., Spatie Media Library) rather than a bespoke editor field.
• You are mid-migration on Nova versions and cannot afford a broken field.

Default recommendation: treat this as a one-day spike, not a strategic dependency. Fork it, add sanitization and tests, and record it as internal code with a named owner.

How to Pitch It (Stakeholders)

To executives: This is a small, self-hosted rich-text editor for our admin tooling that removes the TinyMCE Cloud subscription and API key from our stack, and keeps all content and uploaded images on our own infrastructure. Cost is effectively zero in licensing and infrastructure terms. The trade-off is equally clear: it has no vendor, no support contract, and effectively no user base, so it is not a product we "buy" — it is a component we take ownership of. Recommendation: use it as a starting point for a scoped internal-admin use case, with a named engineering owner and a small maintenance budget, and revisit if our editing needs grow beyond a single rich-text box.

To engineering: Thin wrapper around a self-hosted TinyMCE build plus upload handling through Laravel's filesystem abstraction — small enough to audit and fork in a day. Because upstream is unmaintained in practice, plan to vendor it: pin Nova and TinyMCE versions, add server-side HTML sanitization, add tests around upload validation and disk configuration, and keep an escape hatch to a plain textarea or a maintained editor. Verify TinyMCE's current community-edition licensing before shipping it in anything we redistribute to clients.