Tinymce Bundle Laravel Package

Getting Started

Read this first: short-edition/tinymce-bundle is a Symfony2 bundle, not a Laravel package. There is no service provider, no facade, no config/tinymce.php publish tag. composer require short-edition/tinymce-bundle in a Laravel app pulls in a class tree that references Symfony\Component\HttpKernel\Bundle\Bundle, the Symfony DI container, and Twig 1.x — none of which Laravel wires up. For a Laravel codebase, the realistic "getting started" is to read the repo as a reference implementation and re-implement its ~150 lines of useful logic yourself.

Where to look in the source, in order:

1. The Twig extension — this is the package. It exposes a tinymce_init() function that emits a <script> block calling tinymce.init({...}).
2. The DI extension — the class that loads and merges the bundle's YAML config into the container. This is the pattern worth copying.
3. The default config file — the theme: map that ships with sensible defaults for default, simple, full variants.

First use case (Symfony context, for reference): register new ShortEdition\Bundle\TinymceBundle\ShortEditionTinymceBundle() in AppKernel.php, add a short_edition_tinymce: block to config.yml with tinymce_js_url and theme:, drop {{ tinymce_init() }} in your base layout, and put class="tinymce" on any <textarea>. The extension's init script targets .tinymce and auto-bootstraps.

For Laravel: skip the bundle. npm install tinymce plus a small Blade component gives you the same result with a maintained, versioned editor. Treat the repo as a spec for how to wire TinyMCE into a server-rendered form layer.

Implementation Patterns

Named themes, one global default. The bundle's core idea is a theme: map in config — a default entry plus named variants (simple, full, minimal). A textarea opts in with data-theme="simple", and the Twig helper emits one tinymce.init({...}) per theme actually present on the page. Copy this pattern: keep toolbar/plugin config out of templates and in a versioned config array.

Layout-level include, view-level opt-in. Call tinymce_init() once in the base layout (cheap when no .tinymce textareas exist) and let individual forms opt in via class/data attributes. Do not call it from partials — duplicate tinymce.init calls on the same selector are a classic source of double-initialized editors and ghost toolbars.

Laravel analogue. A Blade component that mirrors the bundle's form-helper ergonomics:

<x-tinymce name="body" :value="old('body', $post->body)" theme="simple" />

The component renders the textarea and pushes a per-page @push('scripts') block containing tinymce.init. Keep the init payload in a PHP config array (config/tinymce.php) and json_encode it — that mirrors the bundle's config-merge behaviour exactly.

Asset strategy. The bundle exposes tinymce_js_url (and a base URL) so you point at a CDN, a protocol-relative URL, or a locally served copy. In Laravel, prefer Vite/npm and @vite('resources/js/tinymce.js') so the editor version is pinned in package.json rather than in a URL string in YAML.

Server-side config rendering. The interesting part of the bundle is that the editor config is server-rendered — theme variants are resolved from YAML at render time and injected into the init call. That means your toolbar/plugin set is versioned with your app and can be gated by user role or feature flag. Preserve this: do not hardcode tinymce.init in a static JS file.

Multiple editors per page. One tinymce.init with a selector array (selector: '.tinymce-simple, .tinymce-full' — or per-theme init calls) is correct. Do not loop over textareas and call tinymce.init per element; TinyMCE re-scans the DOM each call and you get duplicates.

Gotchas and Tips

• Framework mismatch is the gotcha. The bundle assumes Symfony2 DI, AppKernel, and Twig 1.x. Installing it in a Laravel app or a Symfony 5/6/7 app yields Composer conflicts and runtime class-not-found errors. The composer.json almost certainly pins PHP 5.x / Symfony ~2.x — modern Laravel requires PHP 8.1+ and Symfony 6/7 components.
• Symfony2 is EOL (Nov 2018). The package has zero stars, zero dependents, and no maintenance signal. Treat any adoption as "we forked it; we own it."
• Licensing. TinyMCE v6+ is GPLv2+ or commercial. Closed-source commercial use requires a license — a procurement decision independent of the bundle. The bundle will pin or assume an older TinyMCE version, which changes the terms.
• XSS is your problem, not the bundle's. The bundle does not sanitize editor output. Sanitize on the server (e.g. HTMLPurifier or an allowlist-based sanitizer) before persistence, and again on render if you echo raw HTML.
• Debugging a silent no-init. The most common failure is that the <script> from tinymce_init() runs before TinyMCE's JS bundle has loaded, or after a Turbo/Livewire navigation replaces the DOM. Check the network tab for tinymce.min.js, then check init ordering. With Livewire/Turbo, re-initialize on navigation by listening to the navigation event.
• Asset URL quirks. tinymce_js_url may be emitted protocol-relative or as a raw path. With HTTPS-only apps serving mixed-content, or with a CDN that requires a versioned path, override it explicitly rather than relying on the default.
• Double-init. Calling tinymce_init() in both layout and a view partial, or including it twice in a composable template, initializes each textarea twice. Add a one-shot guard in the extension or a data-tinymce-inited attribute on the base element.
• Extension points worth copying. The theme-map pattern (config → init) and the "helper emits one script per theme present" approach are both genuinely useful ideas. The DI/config-merge plumbing is framework-specific and should not be copied into Laravel.
• Escape hatch. If you inherit a Symfony2 app already using this, the swap-out is small: replace the bundle's asset inclusion with npm/CDN, replace the form type with a plain textarea plus a template init script, and drop the bundle registration. That's a two-hour task, not a migration.