The "ckeditor5_globalAttributeDir" CKEditor 5 plugin definition has a "drupal.conditions" value that contains some unsupported condition types: "filter"

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Have not reviewed but changes should be in MRs and bugs should most likely have test coverage

I experienced the same issue on 11.1.3. The issue persisted after updating to 11.1.6.

I can't give steps to reproduce either. Duplicating the same site on the same server with the same database showed no issues on the duplicate whilst the issue remained on the original.

I can confirm the patch provided resolved it though - or the issue hasn't returned since patching it at least.

We are experiencing the same issue, however, noticed that the issue can only be cleared by clearing the APCu cache.

Looking at the patch in #2, it seems to bypass the strict check and my colleagues and I are not confident it is a true solution.

Why are the array keys 'filter' failing when checked array_diff_key (strict check) but not in_array (loose check)?
The error logs seem to show the same strings, it found an unsupported type 'filter' and then lists 'filter' as a supported type.

Additionally, since it only occurs intermittently and not easily reproduced with specific steps, it suggests that the code itself may not be the issue.

Could this be an issue with how APCu cache is being handled?

To resolve the issue, we have discovered that clearing Drupal cache via Flush all caches would not work until we installed a module to also ensure APCu was cleared.
Likewise, clearing the APCu cache on the server or restarting the server (which clears the cache) would also work to remove the issue.

We have noticed this more often on PHP 8.3 and Drupal 10.3+, currently we don't run any Drupal 11 sites.
We are debugging this on a system running APCu 5.1.24 and PHP 8.3.15.
Older PHP versions do not appear to be impacted by this issue as much from our experience.

krzysztof domański and sagraham, do you currently have APCu enabled?
Which PHP and APCu versions are running?

We will update if we find other helpful information.

We have an update.

After some debugging we found a way to reproduce this for our local and testing environments.
We copied as many UAT server config settings for APCu and OPCache as we could, so we could remove as many variables as possible.

Our live environment:
Cache Utility module - set to clear APCu cache on Drupal Cache Clear
https://www.drupal.org/project/cache_utility →

Changes for Local and UAT:
Disable the option in Cache Utility to clear APCu cache on Drupal Cache Clear

Server Config and settings of note:
Apache
PHP 8.3
APCu enabled, most settings set to APCu defaults, except:
apc.serializer = "default"

Current advice is to use:
apc.serializer = "php"
As advised at: https://www.php.net/manual/en/apcu.configuration.php

Steps used to reproduce:

1. Clear all server and drupal caches
2. Open a content edit screen that uses CKEditor
3. If it loaded correctly, as is expected in this state, clear Drupal Cache but not APCu cache
4. Use Flush all caches option from Drupal Admin menu
5. Page fails to load
6. Clear APCu cache, if Cache Utility is installed it gives the ability to clear just APCu cache
7. Load content edit screen again, confirming that a cleared APCu cache has restored functionality

We tested further and confirmed that changing the following line in php.ini changed the outcome of the above steps:
apc.serializer = "default"
To:
apc.serializer = "php"

When trying to reproduce with the above changes, after an Apache/server restart, the reproduction steps failed to reproduce the issue.
This needs longer testing to confirm the issue, but could shed light on the cause of this issue.