Statamic Tinymce Cloud Laravel Package

Technical Evaluation

Architecture fit mitydigital/statamic-tinymce-cloud is a Statamic addon rather than a general-purpose Laravel package — it registers a custom fieldtype and control-panel asset bundle inside a Statamic installation, and is not usable in a plain Laravel app without Statamic present. Architecturally it is thin by design: a service provider, a config file holding the TinyMCE Cloud API key, and a Vue-based CP component that mounts the TinyMCE editor and persists HTML into the field's value. The 4.0.2 change ("Adjust Vue setup", PR #21) sits squarely in that CP component layer — it is a build/tooling adjustment to how the fieldtype's Vue component is compiled and loaded by Statamic's control panel, not a change to the data model, config surface, or public API. Fit is good for teams already standardised on Statamic 4/5 who want a premium WYSIWYG without self-hosting TinyMCE.

Integration feasibility Low effort: composer require, publish config, set the API key in .env, add the fieldtype to one or more blueprints. Content is stored as HTML on the entry, so no custom storage or migration layer is introduced. The main external dependency is the TinyMCE Cloud CDN plus a domain-restricted API key — that is a procurement/onboarding step (key issuance, domain allow-listing per environment) rather than an engineering one.

Technical risk

• 4.0.2 is a patch with a single PR and no changelog detail; the phrase "Adjust Vue setup" signals control-panel asset-build churn, which historically correlates with blank/erroring fields in the CP until compiled assets and caches are refreshed.
• Single-maintainer vendor (Mity Digital) — bus factor and release cadence risk.
• Runtime dependency on a third-party CDN inside the authoring experience: a CDN or key failure degrades content editing, not the public site.
• Some TinyMCE Cloud premium plugins route data externally (spellcheck, AI-assisted features); confirm which plugins are enabled before assuming content never leaves your boundary.

Key questions

• Which Statamic/Laravel/PHP version matrix does 4.0.x officially support, and does the Vue adjustment target Statamic 5's Vue 3 control panel specifically?
• Does upgrading to 4.0.2 require re-publishing CP assets or clearing the Statamic/Vite cache in existing installs?
• Is there a documented fallback (self-hosted TinyMCE or plain textarea) if the Cloud key is unavailable?
• What is the Cloud plan's monthly editor-load quota, and who owns key rotation per environment?

Integration Approach

Stack fit Laravel 10/11 + PHP 8.1/8.2 + Statamic 4/5 is the expected baseline; verify against the package's composer.json constraints before scheduling. Configuration is conventional Laravel (config/statamic/tinymce-cloud.php + env var), so it slots into existing config-cache and secret-management practices without new patterns.

Migration path 4.0.1 → 4.0.2 is a non-breaking patch and should be treated as a routine composer update plus a CP smoke test. The meaningful migration is v3 → v4, which is breaking and should be handled as a separate change window. If replacing another editor (Bard, Redactor, Markdown), note that stored value shape differs — HTML vs. ProseMirror JSON vs. Markdown — so existing entries need a conversion or a dual-field transition period.

Compatibility The Vue setup adjustment implies alignment with the control panel's front-end toolchain; confirm the CP renders the field after upgrade in both a fresh install and an install that previously published assets. Check that any custom CP styling or field-width configuration still applies.

Sequencing

1. Validate on staging: install 4.0.2, confirm field renders in the CP, save/reload an entry, verify HTML round-trips.
2. Confirm key/domain restrictions for staging and production hosts.
3. Roll to production pinned at 4.0.2; avoid floating ^4.0 until the Vue change has been observed in your environment for a release cycle.
4. Only then begin any editor-consolidation or content-migration work.

Operational Impact

Maintenance Small code surface and infrequent releases — low ongoing engineering cost. The offsetting factor is single-maintainer dependency: budget for the possibility of forking or replacing the addon if it lags Statamic major versions. Pin the version in composer.json and review changelogs deliberately rather than auto-merging patches, given how terse the release notes are.

Support Community/GitHub-issue support only; no vendor SLA on the addon. TinyMCE Cloud itself carries a separate commercial support relationship, which is where real escalation should route for editor-level defects.

Scaling Effectively free on the server side — the editor is CDN-delivered and adds no meaningful request-path load. The scaling constraint is contractual, not technical: monthly editor-load limits on the TinyMCE Cloud plan, and per-domain key restrictions that complicate ephemeral/preview environments.

Failure modes

• Invalid, expired, or domain-mismatched API key → editor fails to initialise, blocking all content authoring on affected blueprints.
• CDN outage or CSP blocking the TinyMCE origin → same authoring outage.
• Stale published CP assets after a Vue-setup change → blank field in the control panel post-deploy.
• Third-party plugin behaviour changes silently with Cloud-side updates, since the editor version is not fully pinned by your lockfile.

Mitigations: add the TinyMCE CDN origins to CSP explicitly, alert on authoring errors, keep one blueprint using a fallback field so publishing is never fully blocked, and re-verify the CP field as a standard post-deploy check.

Ramp-up Developer onboarding is roughly half a day (config, blueprint registration, asset-publish conventions). Editorial onboarding to the TinyMCE toolbar and paste behaviour is the larger cost — plan a short guide and a restricted toolbar preset so authors see a consistent, limited feature set from day one.