@odensc

Open to any feedback on the approach in MR #5 or what needs to be done to get this committed! We have been using this patch in production now for a month and it has provided a considerable speedup to webform submission operations.

We've now been using the fix in MR #469 in production for a month without any errors, and have been able to remove our workarounds. It'd be great if someone else could test and change this issue to RTBC!

MR created with proposed resolution.

@jrockowitz Thanks for the repro config.

I've submitted an MR with tests that fixes this issue. Interestingly, there was already code to handle a similar bug in OptionsBase::getElementSelectorInputValue, from issue #3000202 → . I pulled that code out to an overriden getValue function which should fix the bug for all code paths including OptionsBase::formatTextItem/formatHtmlItem mentioned above, which is the source of the error in this issue.

odensc → created an issue.

odensc → made their first commit to this issue’s fork.

Also verified this patch works with Drupal 10.2.2 and entity_embed 1.5.

Here's the most straight-forward solution I could come up with (patch attached).

This patch: Passes a boolean to the CKEditor 5 plugin of whether the Drupal core alignment filter is enabled. If it's disabled (i.e. we can safely assume that the `data-align` attribute is unused unless the site has a custom filter enabled), then we don't add data-align to the attribute ignore list so that any custom filters can handle it.

Another option would be to simply rename the attribute to `data-removed-align` or something rather than removing it completely, but that would require the filter to check both attributes and seems more convoluted overall.

Any input appreciated, thanks.

@bnjmnm Thanks for the MR! I've confirmed it fixes the issue described, but I did find some bugs:

1. If a wildcard is defined in the Source editing plugin's allowed tags, e.g. <drupal entity data-*>, then a TypeError: attr.key.replace is not a function is thrown.

2. If one of the default data attributes is defined in the allowed tags, e.g. <drupal-entity data-entity-type data-entity-uuid>, then the media doesn't render after embedding. I believe this is because the default key in the attrs object, e.g. "drupalEntityEntityType", gets superseded by the now-automatically-added "dataEntityType", causing some other part of the code to break.

I've attached a patch to your MR that works around these two issues.

For #2, the fix is easy enough: add a check that the attribute is not already defined in the attrs array.

For #1, it's a bit trickier. It appears CKEditor's SchemaItemDefinition.register method does not accept RegExp objects in the allowAttributes property. That means there's no way to simply pass the wildcard along, AFAICT.

Therefore, I simply added a typecheck to simply skip if attr.key is not a string, but this is quite opaque - I'm not sure if it'd be better to actually throw an error instead, so the user isn't confused if their wildcard is not respected. That is, of course, unless you have a better idea of how to handle wildcards.

Comment #35 is exactly correct. There are two issues at play, there was a data loss issue that was fixed in https://www.drupal.org/project/drupal/issues/3410303 🐛 FilterHtml data loss when iframe and/or textarea is allowed Active , but there still exists a separate issue (fixed/reverted by the patch in comment #38), which is that saving a valid CKEditor "Source editing" configuration in the admin interface will cause a validation error. You can still technically edit it through drush, but it's not ideal.

Thanks @timodwhit! Confirmed this patch fixes the issue on Drupal 10.1.5, PHP 8.1.18, and diff 8.x-1.1.

This is due to a breaking change in Symfony 6 (used by Drupal 10) that no longer allows arrays as the return type of `InputBag::get`. See a similar fix that was made in another area of the Webform module: https://www.drupal.org/project/webform/issues/3335962 🐛 File input value contains a non-scalar value Fixed

This is a pretty high priority regression IMO, it will give an error and fail to render the webform on any link that is using prepopulated arrays in the query string.

@jrockowitz Attached is a repro webform. The difference here is that yours has the global `form_prepopulate` setting enabled, which does not trigger this error, as it follows a different codepath at `WebformSubmissionForm.php:L2651`. Disabling the global setting and enabling prepopulate on the individual form element allows the error to happen.

I ran into this issue too. Doing some debugging with XDebug, it seems the error is coming from Drupal\webform\Plugin\WebformElement\OptionsBase::formatTextItem/formatHtmlItem. The call to getValue is returning an array of ["select" => [...], "other" => "..."] for some reason, but only when called from inside a computed token/computed twig field and when the select element is conditionally visible.

When the select element isn't conditional/when the token is in the confirmation page, it seems to be returning a string (either the option selected, or the value of the Other field), as expected.

I was able to do an ugly workaround by using a computed twig field, by detecting if it's an array and returning an empty string, otherwise computing the token:

{{ data.select_element is iterable ? '' : webform_token('[webform_submission:values:select_element]', webform_submission) }}