I did some code diving to get some background information for this.
TL;DR:
"dir" and "lang" are allowed by the filter directly in the same way that "style" and "on*" are prohibited. Other attributes, which are allowed on any tag via configuration or plugin definition, don't have that priviledge.
Relevant code:
The validation message is thrown in:
core/modules/ckeditor5/src/Plugin/Validation/Constraint/FundamentalCompatibilityConstraintValidator.php::checkHtmlRestrictionsMatch()
The validation compares the provided HTML (tags, attributes and values form the configuration and plugin definitions) with the HTML, which is allowed by the "filter_html" filter ("Limit allowed HTML tags and correct faulty HTML").
core/modules/filter/src/Plugin/Filter/FilterHtml.php::getHTMLRestrictions()
That method collects all the allowed (and prohibited) HTML. At the very end, the following is added in any case:
$restrictions['allowed']['*'] = [
'style' => FALSE,
'on*' => FALSE,
'lang' => TRUE,
'dir' => ['ltr' => TRUE, 'rtl' => TRUE],
];
At the moment, the wildcard definitions like "<* class>" don't even arrive at the beginning of the method. If they would, the code above would override any definition for *-tags.
Further foughts:
As a workaround, someone could patch additional lines like the one for "lang" (any class) or dir (some classes) in. I wouldn't recommend this as a solution for this issue though, since it won't be a general solution for any use case.
I think, what needs to be done, is to check, why the *-tags are not arriving at the beginning of the "getHTMLRestrictions()"-method.
After that, it should just be making sure that they survive till the end of the method.
At the end, the definition for "$restrictions['allowed']['*']" should be merged, instead of overridden, to keep whatever came so far while still maintaining the prohibition of "style" and "on*" as well as the permission for "lang" and "dir".
The patch is a re-roll of the one in
#2965989-10: Does not work with core media →
against auto_entitylabel 3.3.0.
It requires the core patch from
#2965989-3: Does not work with core media →
too:
drupal-media-pre-preparesave-hook.patch →
The core patch invokes a hook and the auto_entitylabel patch implements it.
Since there is still an ongoing discussion in #2992426: Add entity methods and hooks for executing pre/post code outside of the save transaction → , the name of the hook might change or an event might be used instead of a hook.
lars.stiebenz → created an issue.
There is one more place, where the field key variable needs to be changed: /src/EntityClone/Content/ContentEntityCloneFormBase.php line 205
Or in human terms: The part of the content clone form, which displays referenced entities for which cloning is enforced.
"body {hyphens: auto}" is in 10.3.x/11.x and git blame is pointing to this issue.
Can someone check if the commits were merged correctly?
The patch is an update to the one in #79 against Drupal 10.2.3.
One test class was moved:
Old path: core/modules/system/tests/src/Functional/Entity/EntityReferenceSelection/EntityReferenceSelectionAccessTest.php
New path: core/modules/system/tests/src/Kernel/Entity/EntityReferenceSelection/EntityReferenceSelectionAccessTest.php
The description for "Allow multiple values" says that you can do OR and AND connections. Since AND is not working with the field-specific filter it is not working as intended, at least.
A minimal correction would be to change the description (see
#6
🐛
Contextual filter AND (,) operator for multiple values does not work
Active
).
However, there is a difference between using a field-specific filter (as in the issue summary) and using "Has taxonomy term ID". The later checks for references anywhere in the entity, not just one specific field. So if your entity has two fields, which are using the same taxonomy, you can't create a filter like "all of the given terms (AND condition) must be given in field_foo". Therefore, enabling the AND-connection for field-specific filters might be helpful for this edge case.
Simple Code for testing (placed in setting.php or settings.local.php):
$config['charts.settings']['advanced']['requirements']['cdn'] = FALSE;
More advanced options are in the documentation → .
Preconditions:
- CDN should be allowed in the advanced configurations.
- Used library should be any but Google (that one lacks the config-check).
- The library itself should not be installed for the test.
Testing:
Place the code and go to /admin/reports/status.
Results:
Without patch: CDN-warning appears.
With patch: CDN-warning does not appear.
Background:
The overrides should work for any of the configurations. The CDN-Option is relatively simple to test since it shows almost directly in the status report.
lars.stiebenz → created an issue.
My approach is basically the same as #3380653-2: Entity queries need an explicit accessCheck()-call in Drupal 10 → : The accessChecks are all set to FALSE since all the queries are used either on admin pages or in background processes.
Additionally I removed some queries entirely. At several places the query was used to get the IDs of all entities (mostly server configurations) and the result was only used as a parameter for loadMultiple(). Since loadMultiple() without a parameter loads all entities too, the query before should be unnecessary.
Or in code:
Old:
$servers = $storage->getQuery()->execute();
foreach ($storage->loadMultiple($servers) as $server) {
// ...
}
New:
foreach ($storage->loadMultiple() as $server) {
// ...
}
"New" should give the same result as "Old" but with 1 query less.
lars.stiebenz → created an issue.
Seems that the issue is already handled in 💬 Unexpected behavior in ldap_user_user_presave on processing multiple users per request Closed: outdated .
The patch is just doing a simple type casting.
lars.stiebenz → created an issue.
lars.stiebenz → created an issue.
Small review: The patch from #3342032-2: Undefined method getImplementations() → works under Drupal 10.0.5 and Libraries 4.0.0.
The Drupal-10-compatibility-issue has a patch, which includes the dependency replacement (grahl/ldap becomes synfony/ldap):
#3297516-7: Automated Drupal 10 compatibility fixes →
.
Seems the approach there was: declare "ext-ldap" dependency and use "--ignore-platform-reqs" to bypass tests here.
Theoretically that should be an issue for automated test here, but testing, and more importantly using, the module in projects should be possible.
An another one: 🐛 [PHP 8.1] [Drupal 10] Upgrade grahl/ldap fork to follow symfony/ldap 5.4.x and require graph/ldap:^5.4 Closed: outdated
The patch in #3297516-7: Automated Drupal 10 compatibility fixes → replaces the grahl/ldap dependency. There is a separate issue for that: ✨ Switch grahl/ldap to symfony/ldap Closed: duplicate .