Filament Forms Tinyeditor Laravel Package

Technical Evaluation

Architecture fit. Unchanged at the architectural level. This is still a Filament form-field package: a custom Field subclass plus a Blade view and JS bootstrap that mounts TinyMCE onto a Livewire-bound input. Low coupling, small blast radius, slots into any Filament panel that renders form schemas, and storage semantics still match Filament's native RichEditor (HTML string in a text/longText column), so the data model does not change. The friction point remains the seam between TinyMCE and Livewire — TinyMCE owns the DOM node and mutates it outside Alpine/Livewire's reactivity, so correctness depends on explicit event wiring (change/blur → $wire.set, wire:ignore on the wrapper, re-hydration on Livewire re-render). v4.0.4 lands directly on that seam: "focus management and shield functionality" is a change to editor focus/blur behavior, which is the exact mechanism the sync path depends on. That does not make the release bad, but it moves it from "cosmetic" to "requires regression testing of the write path."

Integration feasibility. Mechanically unchanged: composer require, provider auto-discovery or manual registration, optional config/view publish, then TinyEditor::make('content') in a schema. Still under a day for a first working field, plus 1–2 days for sanitization, upload handling, and theming. One new operational wrinkle: a JS/Blade-touching release generally requires re-publishing Filament assets (php artisan filament:assets) so the new script reaches deployed environments. If our CI pipeline publishes assets at build time, this is a no-op; if any environment relies on previously published assets, the Blade view and the JS bundle can desynchronize silently. Confirm the release changes published assets before rollout.

Technical risk.

• Supply chain / governance (high — unchanged). 0 stars, 0 dependents, single maintainer, and the namespace mismatch (Packagist vendor noin/ vs. repository owner Tinnnooo) remains a standard typosquat/handoff pattern. A feature release does not resolve this. Verify Packagist ownership, commit history continuity, and whether the vendor name was transferred. Treat as unvetted third-party code.
• Licensing (medium). Package is MIT, TinyMCE 6+ core is MIT, but Cloud delivery, premium plugins, and "free trial" bundles are commercially licensed and gate on an API key. Determine whether the package loads TinyMCE from a CDN or vendors it. New consideration: "shield" may map to a TinyMCE-side protection/focus-lock capability rather than a package-coined term. If so, it may imply a minimum TinyMCE version, which in turn may change the delivery mode (self-hosted bundle version, Cloud tier) and therefore the licensing posture. Resolve this before assuming the release is license-neutral.
• Security (high). Rich text is a stored-XSS surface; client-side filtering is not a control. Server-side sanitization with an allowlist (HTML Purifier or equivalent) must be added by us regardless of package behavior. Any image/file upload endpoint the package or its config exposes needs authorization, MIME sniffing, and size limits. Note that a "shield"/read-only mode is a UX affordance, not an access control — do not let its presence weaken the sanitizer requirement.
• Compatibility (medium — slightly improved signal). The v4.x version line is at least consistent with a Filament v4 target, which narrows the earlier "v3 or v4 — confirm" ambiguity, but confirm it against the composer constraint rather than inferring from the tag. Unpinned or loosely pinned Filament/Livewire constraints can still block composer update across the monorepo. Editors inside repeaters, modals, and nested relation forms remain the classic breakage cases — and focus management changes are precisely what regress modal focus trapping.
• Maturity (medium — modestly improved). v4.0.4 following v4.0.3 gives a second data point within the same minor line and corroborates that the repo is alive; the earlier "anomalous last release date" caveat can be retired. Cadence beyond a patch-per-release is still unknown, and a patch bump containing a feature is a mild signal that semver discipline is loose — budget for reading changelogs on every bump rather than assuming patch = safe.

Key questions.

1. Which Filament major versions does the composer constraint actually permit, and does the v4.x tag actually correspond to Filament v4?
2. Does it bundle TinyMCE or fetch it from a CDN — and if CDN, is a paid API key or Cloud account required?
3. What does "shield" concretely mean here — a TinyMCE feature (and which minimum TinyMCE version does it require), or package-local UX?
4. Does v4.0.4 change published JS/CSS assets, and does it require a filament:assets re-publish in each environment?
5. Who is the maintainer of record, and is there any relationship between noin and the repo owner?
6. Does it handle Livewire re-render (wire:ignore), repeaters, and modal-mounted forms — and does the new focus management preserve or break modal focus trapping?
7. Is there a documented sanitization or upload story, or is that entirely on the consumer?
8. What is the fallback if the package is abandoned — is the field class small enough to vendor and own?

Integration Approach

Stack fit. Unchanged: Laravel + Filament (v3 or v4 — the 4.x tag suggests v4, confirm), Livewire 3, PHP 8.1+, a standard panel with published Filament assets and a working Vite build. Fits cleanly alongside Filament's first-party RichEditor; the two can coexist per-resource, which supports staged rollout. Still does not fit under a strict CSP without nonces, or where deep TinyMCE customization (custom plugins, PowerPaste) is expected — that pushes into a paid tier. Add one check given this release: verify whether "shield" is a premium-tier capability. If it is, the feature is unusable for us and should be excluded from any evaluation of the release's value.

Migration path. Content is plain HTML in an existing column, so no schema migration for a straight RichEditor → TinyEditor swap. The real work is unchanged: (1) run existing stored HTML through the new sanitizer and diff for dropped markup before enabling writes; (2) replace Filament's native file-attachment integration with an explicit images_upload_handler pointing at an authenticated endpoint, or disable uploads initially; (3) map feature parity — mentions, @ autocomplete, and Filament's FileAttachments API have no direct equivalent. Add a fourth: pin the exact version we validate, because the focus-change in v4.0.4 means "latest 4.x" is not interchangeable with "the build we tested."

Compatibility. Validate dark mode, RTL locales, Filament theme CSS leaking into TinyMCE's iframe/skin, and mobile toolbar behavior. Validate CSP: TinyMCE injects styles and base64 assets, which commonly trips style-src and img-src. Confirm the package respects Filament's asset publishing so it works under php artisan filament:assets in CI and in deployed environments without a node build step on the server — this release makes that check mandatory rather than precautionary.

Sequencing.

1. Spike (1–2 days). Vendor the package into a scratch Filament panel, read the source, and confirm TinyMCE delivery mode, license posture, composer constraints, and what "shield" maps to.
2. Release triage (half day). Diff v4.0.3 → v4.0.4. Identify whether the focus/shield changes touch the change/blur wiring, whether published assets changed, and whether any TinyMCE minimum version moved. Keep a note of the v4.0.3 behaviour so you can pin back if focus regressions appear.
3. Pilot (1 sprint). Wire it into one low-risk internal resource. Add server-side sanitization and an authz-gated upload endpoint. Cover repeater, modal, dark-mode, and modal-focus-trap cases in tests.
4. Gate review. Compare against the incumbent RichEditor on authoring UX, content fidelity, page-weight, and maintenance cost. Kill it here if the delta is marginal — a zero-adoption dependency must earn its place.
5. Adopt or vendor. If adopted, pin the exact version, add a lockfile diff review plus an asset-republish check to CI, and record the maintainer as a monitored dependency. If the gate is close but the UX wins, vendor the field class in-house and own ~300 lines rather than the dependency.
6. Broaden. Roll out resource-by-resource behind a feature flag, keeping the old editor as fallback for one release cycle.

Operational Impact

Maintenance. The package is small, so ongoing cost is less "patch the library" and more "absorb Filament upgrades yourself," plus now "read every changelog line." A feature shipped in a patch version means we cannot rely on semver to tell us when behaviour changed; pin the exact version and treat any release — patch included — as a review event that requires a changelog read and an asset re-publish check. Budget a recurring review each time Filament ships a major, plus a quarterly check that the repo is alive (this release is a positive data point there). The realistic worst case remains a fork, and the exit cost is still low — the strongest argument in the package's favor.

Support. Effectively zero. No stars, no dependents, no community issue traffic means no signal on whether a bug is ours or the package's. Our team becomes tier-1 support. Acceptable for an admin-panel nicety, not acceptable for anything customer-facing or compliance-relevant. Document the internal owner; add "focus management regressions introduced in v4.0.4" as a known-watch item in that owner's runbook.

Scaling. Unchanged: TinyMCE is a heavy client bundle (hundreds of KB minified, more with plugins and skins). Multiply by editors per page — repeaters and nested relation forms are the failure case — and admin page load and memory degrade quickly on low-end machines. Mitigate by lazy-initializing on focus, capping instances per form, and self-hosting with long-lived cache headers rather than relying on a CDN round trip per session. Server-side cost is negligible; sanitization is the only meaningful CPU add. One nuance: focus-on-init behavior changes can interact with multi-editor pages — if "focus management" auto-focuses a newly mounted editor, forms with several editors may scroll-jump or steal focus from the user's actual target. Verify with a repeater containing three or more editors.

Failure modes. Rank by likelihood × impact: (1) silent content loss when Livewire re-renders or the form submits before TinyMCE flushes to the model — still the highest-severity, hardest-to-detect failure, and now the most likely thing to be perturbed by a focus-management change; (2) stored XSS from unsanitized HTML; (3) editor fails to initialize inside modals/repeaters, leaving a blank box with no obvious recovery — again adjacent to this release; (4) stale published assets after upgrade, producing a Blade/JS mismatch that manifests as intermittent focus or sync misbehaviour that is very hard to attribute; (5) CDN outage or expired API key blanking every editor at once; (6) composer resolution break during a Filament or Livewire upgrade; (7) package abandonment, which degrades gracefully into (6). Instrument (1) explicitly with a test that asserts model state after a debounce and after a simulated re-render, and add a test asserting focus lands where expected when a modal form opens.

Ramp-up. Unchanged for developers already fluent in Filament custom fields — half a day to productive. The real learning curve is TinyMCE's own configuration surface (toolbar, plugins, valid_elements, upload handlers), which is large and sparsely documented for Filament-specific wiring; "shield" is a new term to get a definitive answer on before anyone builds assumptions on it. Budget one owner to become the internal expert, write a short usage doc covering sanitization, upload policy, and the version-pinning/asset-republish procedure, and codify the field in a shared internal package so other teams are not each re-deriving the Livewire sync.

Recommendation. Conditional pilot only — unchanged. v4.0.4 is a feature-only patch with no breaking change or deprecation, so it does not alter the verdict, but it does three useful things: it corroborates that the repo is maintained, it confirms the release line is active enough that we must pin exactly, and it touches the focus/sync seam, which raises the bar on regression testing rather than lowering it. The opportunity is still real — Filament's native editor is opinionated, and teams with an existing TinyMCE investment or content pipeline have a genuine gap — but 0/0 adoption and the vendor-namespace mismatch mean this cannot be adopted on trust. Run the spike and pilot with server-side sanitization written by us, resolve what "shield" means and whether it carries a license or minimum-version implication, keep the in-house-vendor exit open, and make the adoption decision on measured authoring gains rather than on install convenience.