- Can I use helios-ag/fm-tinymce-bundle in a Laravel application?
- No. The package is a Symfony bundle: it subclasses Symfony's Bundle class, ships a dependency-injection extension, and renders editor assets and configuration through Twig. Laravel has no bundle registration mechanism and no Kernel::registerBundles() equivalent, so Composer package discovery will not wire anything up. Making it work would mean bootstrapping a parallel Symfony kernel inside your Laravel app, which is high cost and high blast radius for zero product benefit. For Laravel, treat this package as reference documentation only.
- How do I install and register the bundle?
- Installation is Composer-based, followed by registering the bundle in your Symfony application's config/bundles.php and importing its configuration under config/packages. You then use the bundle's Twig helpers or form type to render a TinyMCE field, and the bundle loads the editor assets for you. Every one of those steps assumes a Symfony skeleton with a kernel and bundle registry. None of them map onto a Laravel service provider or Blade view.
- Which Laravel and PHP versions does this package support?
- None. There is no Laravel support at any version, and the 3.0 changelog contains no service provider, no package discovery entry, and no Blade integration. The 3.0 release most plausibly raises minimum Symfony and PHP versions for Symfony consumers, which is a breaking change for them but irrelevant to a Laravel estate. If any part of your stack genuinely runs Symfony 6 or 7, confirm the exact minimums before upgrading.
- What changed in version 3.0 and are there breaking changes?
- The 3.0 changelog covers dependency bumps, a TinyMCE version update, assorted fixes, CI badges, and completed installation documentation. A major version bump implies breaking changes for Symfony consumers, most plausibly raised Symfony and PHP minimums and the removal of the matthiasnoback test tooling at its previous major constraints. Configuration key renames and Twig template changes should be verified against the upgrade notes. Note that three of the seven merged pull requests were Dependabot bumps to test-only dev dependencies, which is CI churn rather than production-surface hardening.
- What is the best way to add TinyMCE to a Laravel application instead?
- Reimplement it natively. TinyMCE is a client-side JavaScript library, so install tinymce via npm, bundle it with Vite, wrap it in a small Blade component with an x-data or vanilla init hook, and pass your toolbar and plugin configuration from a config array. That is roughly one to two days of work and gives you full control over the editor version, licensing, and asset pipeline. The bundle's documented toolbar profiles and option presets are still useful as a design reference while you build it.
- Does this package sanitize user-submitted HTML on the server?
- No. The bundle only handles editor assets and configuration, so it provides no server-side sanitization of rich-text input. Rich-text fields are a persistent XSS vector, so you must run submitted HTML through a sanitizer such as HTML Purifier, Symfony HtmlSanitizer, or an equivalent allowlist-based filter before storing or rendering it. That work is in scope on every path, including a native Laravel reimplementation. Never rely on the client-side editor to enforce markup rules.
- Which TinyMCE version does the bundle pin, and is it still patched?
- The release notes do not state the target version, so you have to confirm it in the lockfile or composer.json. Release 3.0 includes a PR that moves the bundled editor forward, which addresses earlier concerns about pinning an end-of-life editor with unpatched XSS vectors, but an upgrade is not the same as landing on a currently supported release line. Verify the pinned version against TinyMCE's current security-patch line before putting it anywhere near a rich-text input path. Until that is confirmed, this remains the highest-severity open risk in the feature area.
- Is TinyMCE free to use, or does this bundle require a paid license?
- The bundle itself does not settle that question. You still have to decide between self-hosted community TinyMCE, the cloud/API-key model, and commercial premium plugins, and confirm which model the bumped editor version in 3.0 now assumes. Whoever owns the API key also owns billing and quota, so make that ownership explicit before rollout. Verify the current TinyMCE licensing terms yourself rather than inferring them from the bundle version.
- Is helios-ag/fm-tinymce-bundle actively maintained and production-ready?
- The maintainer is active: seven pull requests were merged in the 3.0 cycle, with CI badges added and installation documentation completed, which is a better signal than earlier reads. However, adoption is effectively zero and there is no downstream validation you can point to, and three of those PRs were automated dependency bumps to test-only tooling. Activity is not the same as a support commitment, and future-dated release metadata in the repository means you should treat release dates as unreliable and the linked PR record as the verifiable evidence.
- How do you configure toolbars, plugins, and asset loading with this bundle?
- You declare editor options, toolbar layouts, and plugin lists in the bundle's configuration, and it renders the corresponding TinyMCE init script plus the editor assets through Twig helpers or a Symfony form type. Optional integrations with related file-manager tools let users insert media from a browser. Since the bundle manages asset loading for you, you control the editor version and plugin set only indirectly through the bundle release you install. In a Laravel app, use these configuration patterns as a template for your own Blade component and config file instead of installing the bundle.