excluded_patterns in asset mapper

[ThibaultPelloquin]

AssetMapper default exclusions break custom TinyMCE CSS in bundles

3615 MYLIFE

Today, I spent half a day trying to integrate a custom TinyMCE skin into my project, feeling like I was going crazy. I logically (?) named this skin tinymce-custom.css.

<script>
window.tinymceConfig = {
  content_css: "{{ asset('@acme/assets-bundle/styles/tinymce-custom.css') }}",
}
</script>

I couldn’t get it to work—everything kept failing.

The string '@acme/assets-bundle/styles/tinymce-custom.css' was never converted to real asset path...

Then... I tried in my asset mapper js file, just to test (in desperation):

import './styles/tinymce-custom.css';

And I got the error

Unable to find asset "./styles/tinymce-custom.css" imported from "/app/work/packages/assets-bundle/assets/base.js" .The file "/app/work/packages/assets-bundle/assets/styles/tinymce-custom.css" exists, but it is not in a mapped asset path. Add it to the "paths" config.

So... I ran:

php bin/console debug:config framework asset_mapper

And then… what did I see!?

Current configuration for "framework.asset_mapper"
==================================================

excluded_patterns:
    - '**/**tinymce**' << WHAT!?
    - '**/skins/*/appstack**'
    - '*.d.ts'
    - '**/controllers.json'

I looked for the guilty code in our application… nothing. Then I finally discovered it was in the bundle configuration we were using.

What is the purpose of these exclusions!?

Description

In the current version of the package, the DependencyInjection automatically prepends the following AssetMapper configuration:

if (class_exists(\Symfony\Component\AssetMapper\AssetMapper::class)) {
    $container->prependExtensionConfig('framework', [
        'asset_mapper' => [
            'excluded_patterns' => [
                '**/**tinymce**',
                '**/skins/*/appstack**',
            ],
        ],
    ]);
}

This causes any CSS files containing tinymce in their path, including custom TinyMCE builds in the main project, or private bundles (e.g. tinymce-custom.css), to be ignored by AssetMapper. This breaks the ability to import and fingerprint custom TinyMCE CSS files.

---

Steps to reproduce

As simple asset

1. Create a custom TinyMCE CSS file in a private bundle:

assets/styles/tinymce-custom.css

2. Import it in a JS file or link it in a Twig template using AssetMapper:

{{ asset('@acme/assets-bundle/styles/tinymce-custom.css') }}

3. The asset stays in 404.

---

Expected behavior

• Only the original TinyMCE vendor skins (skins/*/appstack) should be excluded.
• Custom CSS in the bundle should be included normally and fingerprinted.

---

Proposed solution

• Do not prepend excluded_patterns automatically in the bundle’s DependencyInjection.
• If exclusion is needed, it should be optional or configurable by the user.
• At minimum, avoid a blanket **/**tinymce** exclusion that blocks all custom TinyMCE CSS.
• Or add the bundle name in the ignored path!

---

Environment

• Symfony 6.4+
• AssetMapper enabled
• Private bundle with custom TinyMCE CSS

[EmilePerron]

Hey there!

TinyMCE's expectations in regards to file names and paths are not really compatible with the way AssetMapper works. TinyMCE assumes its scripts and stylesheets are present in the same directory as the core import, and that these scripts and stylesheets have very specific names. However, Asset Mapper adds hashes to each file name, which completely breaks TinyMCE.

That is why the excluded_patterns is prepended automatically with the configs you mentioned when AssetMapper is enabled: because without that, TinyMCE wouldn't work at all. That is why it's there by default: making this optional/configurable is not really a viable option here.

In any case, updating to a more precise selector would obviously be ideal. I feel like I had tried a few more precise options without any luck before finally landing on this wider one, but it's been a year since I worked on this so I don't quite remember - and perhaps updates have been made since to fix issues that more precise selectors might've caused.

If you want to give it a shot and open a PR for this, I'd be happy to merge it in and release it as long as the tests pass. The automated tests in the CI do include tests with and without AssetMapper installed/enabled, so it should be fairly straightforward to find out if a solution is solid or not.

If neither you nor anyone else can make a PR for this, I'll end up taking a look at it eventually, but I am busier than usual at the moment so it might take a while for me to get to it.

Cheers,

• Émile