Filament Tinyeditor Laravel Package

Technical Evaluation

Architecture fit

• The package is a Filament form Field subclass (AmidEsfahani\FilamentTinyEditor\TinyEditor) that wraps TinyMCE, not a standalone Laravel package. That is the right shape for our stack: it slots into existing Form/Resource schemas alongside TextInput, RichEditor, and MarkdownEditor without new abstractions, controllers, or persistence layers.
• It inherits the Filament Field API, so required(), columnSpan(), reactive(), hidden(), validation, and Livewire binding come for free. From a TPM standpoint this materially reduces the integration surface: the team is learning one widget, not a subsystem.
• Runtime dependencies are conventional for Filament: a service provider, publishable config/views/assets, and Blade/Alpine wiring. Media handling reuses Filament's attachment disk/visibility/directory conventions (fileAttachmentsDisk, fileAttachmentsVisibility, fileAttachmentsDirectory), so storage policy stays in our existing filesystem config rather than a second upload path.
• The package assumes the front end is exclusively a Filament panel. If any requirement involves a public-facing editor, an API-driven content workflow, or a non-Filament admin surface, this package does not apply and we would need a separate headless integration of TinyMCE.

Integration feasibility

• Low-to-moderate effort. Realistic sizing for a first production resource: 1–2 developer-days for install, asset publishing, config, disk wiring, and one form; add 2–3 days for sanitization, upload hardening, and acceptance tests.
• The version matrix is explicit and clean, which is the single biggest de-risking factor:

• Our gating decision is simply: pin the package major to the Filament major we run. There is no ambiguous middle ground, which is unusual and welcome for a Filament plugin.
• Four built-in profiles (default, simple, full, minimal) plus none and custom map well to role-based authoring: a minimal profile for short marketing blurbs, full for long-form pages. Custom profiles and pipe-separated tool groups let us cap editor surface area per content type rather than shipping one maximal toolbar to every user.
• RTL support via ->rtl() / ->direction('auto|rtl|ltr') plus the config direction key is a real differentiator if we have any MENA or Hebrew content roadmap. It is cheap to validate and hard to retrofit later, so confirm it in the spike.

Technical risk

• Adoption / bus factor (highest). 109 stars, zero dependents, effectively a single maintainer. That is not disqualifying for an admin-only widget, but it means we must assume we may need to fork. Budget a named owner and a "fork-in-a-day" rehearsal if this becomes load-bearing.
• Version lag against Filament majors. Each Filament major requires a package major. Filament ships majors on a fast cadence; the package's 5.x line exists but track record across prior transitions (3→4→5) is compressed into a short window. Risk: we upgrade Filament and are blocked on this widget.
• TinyMCE licensing, not package licensing. The package is MIT, but TinyMCE 7 itself is GPL-2.0-or-later or commercial, and the tiny.cloud hosted variant requires an API key (a license-key option was added in v2.0.1). Someone must own this determination before production, because it is a legal/commercial question, not a code question.
• XSS surface area. A WYSIWYG stores raw HTML. The package gives us an editor, not a sanitizer. Server-side sanitization (HTML Purifier or equivalent) on every write path, plus safe rendering on every read path, is our responsibility. This is the most likely source of a security finding.
• External plugins via arbitrary URLs. external_plugins accepts remote JS URLs (the README example pulls from unpkg.com at @latest). That is a supply-chain and availability hazard: @latest is unpinned remote code executing in an authenticated admin session. Treat as banned-by-default in our standard.
• Client-side upload flow. Temp image upload required a URL-encoded filename fix as recently as v5.0.1 / v4.0.8, indicating a non-trivial upload path. Expect edge cases in filenames, MIME validation, and orphaned temp files; test with non-ASCII and spaced filenames.
• Historical fragility is documented in the changelog itself. Content loss on reorder, modal overlap conflicts, and Alpine x-load renaming all appear as past fixes. Each was resolved, but it tells us the Livewire/Alpine integration is the fragile seam and must be regression-tested on every upgrade.
• Maturity signal. "readme, releases" only — no evidence of CI, test suite, static analysis, or a security policy. We cannot lean on upstream testing; our own acceptance suite is the safety net.

Key questions for the maintainer / spike

1. Is TinyMCE consumed self-hosted from published assets, from tiny.cloud, or both? Which is the default, and what does the license key actually gate?
2. What is the tested upgrade window when a new Filament major lands — days, weeks, or "when someone contributes a PR"?
3. Is there a supported sanitization story, or is it explicitly the host application's problem? (Assume the latter, but confirm.)
4. What are the upload validation guarantees — MIME allowlist, max size, image re-encoding, temp-file cleanup — versus what Filament's own FileUpload enforces?
5. Does the editor behave correctly inside Filament modals, repeaters, and nested relation managers? These are the historically reported breakages.
6. Are published assets version-hashed or stable-path? This determines our CDN cache-invalidation strategy.
7. Any known accessibility conformance (WCAG) for the configured toolbars, and is there a keyboard-only path?

Integration Approach

Stack fit

• Assumes Filament Admin/Forms (3.x, 4.x, or 5.x) on matching Laravel/PHP. If we are on Filament 3 today, we take package 3.x; when we move to Filament 4/5 we move the package in lockstep. There is no scenario where we mix majors.
• Fits naturally where we already use Filament resources for CMS-ish content: pages, posts, product descriptions, email templates, help articles. It is a poor fit for structured data or short single-line fields, where a TextInput or Textarea is cheaper and safer.
• Storage integrates through Filament disks. We should standardize on a single named disk (e.g., public for local, s3 in production) and a per-content-type upload directory, and keep visibility explicit rather than relying on defaults.

Migration path

• Greenfield: trivial. composer require the matching major, publish config, optionally publish views/assets, drop TinyEditor::make('content') into a schema.
• Brownfield from Filament's built-in RichEditor (Tiptap-based): not a drop-in. Stored HTML is broadly compatible, but toolbar semantics, image embedding, and paste behavior differ. Expect a content-QA pass on existing records and a short editor-training note for authors. Recommend not migrating in-flight content; migrate per resource with a before/after sample review.
• Brownfield from a legacy TinyMCE or CKEditor integration: this is net-simplifying — it replaces bespoke asset registration and init scripts with a maintained Field. Salvage the config intent (toolbars, plugins, content styles) into the package's profiles array.
• From package 3.x → 4.x → 5.x: treat as breaking. Re-publish config and views, diff them against our customized copies, and re-run the editor regression suite. The 3.x line specifically renamed Alpine directives (ax-load → x-load), which is the class of change that silently breaks init.

Compatibility

• Pin the package exactly ("^5.0" with a committed composer.lock), and add a CI gate that fails on Filament major/minor drift outside the tested matrix.
• Verify PHP and Laravel floors in the same composer bump as Filament: package 4.x and 5.x both require PHP 8.2+, which may itself be the forcing function for a platform upgrade. Sequence accordingly.
• Check our CSP: TinyMCE needs inline styles/scripts in some configurations. If we run a strict CSP with nonces, validate in the spike rather than discovering it in staging.
• Confirm Alpine/Livewire versions used by the panel; the package's history is sensitive to Alpine directive naming and Livewire state sync.

Sequencing

1. Spike (2–3 days). Sandbox branch. Install the major matching current Filament. Publish config and assets. Build one resource with default and minimal profiles, RTL enabled, and a local disk upload.
2. Hardening pass. Add server-side sanitization to the model/mutator or a form-level pipeline. Restrict upload MIME types and sizes. Explicitly disable external_plugins (or pin an exact versioned URL if a plugin is truly required). Define the toolbar allowlist per content type.
3. Acceptance suite. E2E coverage for: initial render, save/reload round-trip, file upload with non-ASCII filename, paste from Word, RTL alignment, editor inside a modal and inside a repeater, and content preservation on repeater reorder (a documented past regression).
4. Pilot. One low-risk resource behind a feature flag, 1–2 real authors, one week of observation. Instrument for JS init failures and upload errors.
5. Rollout. Expand resource by resource. At each step confirm the profile-to-content-type mapping is intentional, not copy-pasted.
6. Upgrade runbook. Documented procedure for Filament major bumps: bump both, re-publish and diff config/views, run acceptance suite, compare sanitization output on a fixture corpus.

Operational Impact

Maintenance

• Recurring cost is dominated by upgrade coupling, not day-to-day breakage. Every Filament major implies a package major, a config/views diff, and a regression run. Budget roughly 1–2 engineer-days per Filament major, plus the risk of waiting on upstream.
• Because config and views are publishable, we will accumulate local divergence. Mitigation: keep published config minimal and documented as an intentional override list; avoid publishing views unless a concrete need exists, since view overrides are the stickiest form of drift.
• Asset publishing means versioned JS/CSS land in our repo or build. Decide once: commit published assets (auditable, but noisy diffs) or publish in deploy (leaner, but requires a post-deploy artisan step). Do not do both.

Support

• Community-only support with a single primary maintainer and no dependents. There is no vendor SLA. Our realistic support model is: internal owner + ability to patch locally + willingness to fork under the MIT license if upstream stalls.
• Name an internal owner for the widget and an alternate. Record the fork procedure (mirror to internal VCS, patch, pin via composer repositories vcs entry) so it is a known path rather than an improvised one.
• Track upstream releases; the project does ship patches promptly (multiple fixes credited to outside contributors within days), which is a positive but not a guarantee.

Scaling

• Editor bundle size is the user-facing cost: TinyMCE plus the full profile's plugin set is a meaningful JS payload per admin page. Use minimal/simple profiles by default and reserve full for the few long-form resources. Serve assets via CDN with long-lived caching.
• Uploads, not the editor, drive infrastructure load. Image uploads through the panel consume app-server CPU for validation and any resizing, then storage bandwidth. If image volume is high, route to object storage and do derivative generation out-of-band.
• Content payloads are large HTML blobs. Watch column type (longText), row size, and any full-text indexing strategy; avoid SELECT * patterns that hydrate editor HTML into list views.
• Orphaned uploads from abandoned edits are a slow-burn storage cost. Plan a periodic reconciliation job keyed on referenced media paths.

Failure modes

Ramp-up

• Developer ramp-up is short: the Field API matches Filament conventions, so an engineer productive with Filament resources needs roughly half a day to be effective, and the README's usage and config examples are adequate for that.
• Author ramp-up is the under-budgeted piece. TinyMCE's toolbar is denser than Filament's native editor and paste-from-Word behavior will produce messy markup unless paste_webkit_styles-style configs are tuned. Budget a short author guide and one feedback cycle after pilot, and expect a follow-up config iteration.
• Hidden ramp-up cost: sanitization and upload policy are owned by us, so the security reviewer and the platform owner both need onboarding to this widget — not just the feature developer.