Tinymce Laravel Package

Getting Started

Reality check first: contao-components/tinymce is not a Laravel package. It is a Contao CMS "component" package: a Composer-installable, version-pinned mirror of the TinyMCE static distribution, tagged "type": "contao-component". There is no ServiceProvider, no config/tinymce.php, no facade, no Blade directive, and Laravel's package discovery will ignore it. If the goal is "TinyMCE in a Laravel app," the correct first move is npm install tinymce and close this tab. The rest of this assessment assumes a legitimate reason to be here — maintaining a Contao site alongside Laravel services, or deliberately vendoring a known-good TinyMCE build when npm/Vite is not an option.

Minimal steps (Contao, the intended context):

1. composer require contao-components/tinymce
2. Ensure the installer plugin is allowed: contao-components/installer (or contao/manager-bundle) must be installed and listed under config.allow-plugins in composer.json for Composer 2.2+.
3. Run composer install; the plugin copies the package contents to assets/tinymce/ (older Contao) or public/assets/tinymce/ (newer) — not vendor/.
4. Reference assets/tinymce/tinymce.min.js from a Contao template (be_tinyMCE.html5, fe_page, or a custom module template), or configure the back-end RTE through Contao's contao.rte configuration.

Minimal steps (Laravel, if you insist):

1. composer require contao-components/tinymce — it lands in vendor/contao-components/tinymce/ and does nothing.
2. Copy vendor/contao-components/tinymce/tinymce/ to public/vendor/tinymce/ via a post-autoload-dump script or a small Artisan command.
3. Add <script src="{{ asset('vendor/tinymce/tinymce.min.js') }}"></script> and initialize.

Where to look first: vendor/contao-components/tinymce/composer.json (version, type, extra), the tinymce/ directory (tinymce.min.js, themes/, models/, plugins/, skins/), and the Contao root composer.json for the components installer config. Treat the repo as vendored JS, not as an API.

First use case: Replacing a plain <textarea> with a rich text editor in a Contao back-end module, or vendoring a pinned TinyMCE build into a Laravel Blade form when the build pipeline cannot consume npm packages.

Implementation Patterns

Pattern 1 — Contao back-end RTE (the intended use). Contao's core consumes this package to serve the editor in the back end. Customization happens through Contao configuration (typically contao.rte in config/config.yaml, or the legacy $GLOBALS['TL_RTE'] and be_tinyMCE.html5 template, depending on Contao version) — not through PHP shipped by this package. Keep toolbar, plugins, menubar, and content_css in Contao config so component upgrades don't clobber them.

Pattern 2 — Laravel asset vendoring. Make the copy step explicit and reproducible:

• Add a Composer script ("post-autoload-dump": ["@php artisan vendor:publish --tag=tinymce --force"]) or a cp -R shell step.
• Register a Blade component <x-tinymce name="body" :value="old('body', $post->body)" /> that renders the textarea plus an init script pushed into @stack('scripts').
• Set base_url to /vendor/tinymce and suffix: '.min' so theme, model, and plugin URLs resolve.

Pattern 3 — The sane Laravel path (recommended). npm install tinymce, import tinymce/tinymce plus the specific plugins and theme you need in resources/js/app.js, and initialize from a small module. Vite hashes and bundles it; package.json is your version control; no Composer plugin and no copy scripts.

Integration tips:

• Load from the TinyMCE CDN if you want zero build steps — the cloud build requires an API key.
• In Contao, use the components installer rather than manually copying into assets/, or files will disappear on the next deploy.
• In hybrid Contao/Laravel monorepos, keep separate asset roots. Don't try to serve Contao's assets/ from Laravel's public/.
• Pin the TinyMCE major version. Config keys differ sharply across v4/v5/v6/v7 (toolbar vs toolbar1, string vs array plugins, license_key in v7).

Gotchas and Tips

• It is not a Laravel package. composer require in a Laravel app installs static files into vendor/ and nothing else. No discovery, no provider, no config publish, no artisan tinymce:install.
• Composer 2.2 plugin blocking. contao-components/installer is a Composer plugin. Without "config": {"allow-plugins": {"contao-components/installer": true}}, Composer skips it and assets never leave vendor/.
• Wrong asset root. Older Contao uses assets/; newer uses public/assets/; very old used web/assets/. A 404 on tinymce.min.js is almost always a path or base_url mismatch, not a missing file.
• Cascading 404s. If tinymce.min.js loads but the editor is blank, check the Network tab for themes/silver/theme.min.js, models/dom/model.min.js, and plugins/*/plugin.min.js. TinyMCE resolves these relative to base_url; get it wrong and you get a silent blank box.
• Version and license drift. TinyMCE 7+ community builds expect license_key: 'gpl'; older builds don't. The component version tracks upstream — read the tinymce.min.js banner and composer.json before copying config from a tutorial.
• Don't edit inside vendor/. Contao's installer overwrites changes on the next composer install. Put custom plugins and skins in your own public/ path and register them via external_plugins / content_css.
• Contao cache. After changing RTE config or component versions, run vendor/bin/contao-console cache:clear; back-end asset URLs are cached and stale entries mimic install failures.
• Extension points: Contao — contao.rte config, be_tinyMCE.html5, custom plugins under your own asset path, and the components installer config in root composer.json. Laravel — a Blade component wrapping tinymce.init, a Vite entry, or a vendor:publish-style command that copies the build.
• Signal from the metadata. Zero dependents and a score of 0 reflect that this is a thin, Contao-specific asset mirror, not a general-purpose integration. Evaluate it as vendored JavaScript; if you are not on Contao, it is almost always the wrong dependency.