🇺🇸United States @esod

We reviewed the following issues:
Move 13 words to the drupal dictionary 📌 More more words to the drupal dictionary Active
There is an issue with the dropdown button action overlapping in display view mode. 🐛 There is an issue with the dropdown button action overlapping in display view mode. Active
Olivero default welcome page needs link removed 📌 Olivero default welcome page needs link removed Active

reviewed but couldn't comment on these issues:
Remove references to hook_process_HOOK 📌 Remove references to hook_process Active
Twig Filter "spaceless" is deprecated 📌 Twig Filter "spaceless" is deprecated Active
Add void return to all views execution hook implementations 📌 Add void return to all views execution hook implementations Active

Great job everyone!

Nice work!

We have >90,000 rows in the acquia_contenthub_publisher_export_tracking table at this point. I appreciate that an effort was made to address this issue with release v.3.5.2. Unfortunately, it's still failing:

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 163840 bytes) in /mnt/www/html/ojp01test/docroot/core/lib/Drupal/Core/Database/StatementWrapperIterator.php on line 113 

After running the hook updates 3 times on our test environment.

mysql> SELECT COUNT(*) FROM acquia_contenthub_publisher_export_tracking WHERE label IS NULL;
+----------+
| COUNT(*) |
+----------+
| 71680 |
+----------+

Same count after running the hook updates a 4th time.

This form uses only textfield, radio elements and #states.

Open the Console on your browser.
Select 'I am the nominee.'
Fill out the form.
Click Submit.
See the 'An invalid form control...' error.

Open the Console on your browser.
Select 'I am submitting on behalf of the nominee.'
Fill out the form.
Click Submit.
The form submits.

@nilesh.addweb Yes, it works with plain text format or a textarea, which is also plain text. We'd like this to work using a CKEditor 5 text_format element.

I was hoping this wasn't just a webform problem, but it is a webform problem.

I'm able to to replicate this issue too. Select 'Recuse' in the attached form.

Thanks for this fix. Public facing users were experiencing the message about blockSubmit on a multi-page form where the file element was last element on the page and they were clicking Next Page before the upload had completed. So it was difficult to uncover the issue. And now it's fixed. Yay!

Here's a better version of the patch. The server still times out after ~21k record updates.

A core bug is preventing the update from completing. The bug is an Annotation bug in Editor.php. Here is the bug.

Doctrine\Common\Annotations\AnnotationException [Semantical Error] The class "Editor" is not annotated with @Annotation. Are you sure this class can be used as annotation? If so, then you need to add @Annotation to the _class_ doc comment of "Editor". If it is indeed no annotation, then you need to add @IgnoreAnnotation("Editor") to the _class_ doc comment of class @Drupal\editor\Annotation\Editor.

core/modules/editor/src/Annotation/Editor.php includes @Annotation. But since the editor entity_id is for only 2 records in the acquia_contenthub_publisher_export_tracking table, my patch manually updates them so as to avoid the annotation issue with the Editor service class.

However, even with the patch successfully applied to our DEV environment, MySQL still goes away after ~20k record updates, ~15 - 20 minutes.

My patch is tending a bit towards a custom patch, but I'm going to add it here because I also don't think the issue I'm experiencing with the acquia_contenthub_publisher_update_91002() is unique. I think any large system is going to eventually have tens of thousands of records in its publisher export tracking table. The attached patch may encourage others to chime in. Otherwise, the continuing discussion on this issue will be with Acquia support.

esod → created an issue.

Reroll for Drupal 10.2.7

Reroll for Drupal 10.2.7. I don't have time to look at the test right now.

Confirming this patch solved the problem when applied to v6.1.3 after upgrading from v6.1.2. Thanks.

patch attached.

esod → created an issue.

Missed one. Updated patch.

This patch may solve the problem. Submitted it for testing.

I'm getting the same warnings on a webform that is placed in a webform block in a layout. Anonymous users don't have access to the Rich Text text format, and the webform is (or will be) available to anonymous users.

My webform contains two processed_text elements with '#format': rich_text and one text_format element, with '#allowed_formats': rich_text: rich_text.

Site specifications are:
Drupal 9.5.10
PHP 8.1
webform 6.1.5

Updating webform to 6.2.6-beta6 won't help since $element['#format'] is still written in core/modules/filter/src/Element/TextFormat.php, and $element['#format'] does not exist for anonymous users. If I add anonymous users to the Rich Text text format, the warnings go away, but doing so is not a possible solution.

The warning is being thrown when I switch the theme to Olivero.

Hi @jrockowitz. I had a little confusion when I first opened the MR in Gitlab. But if I stick to the changes link on this page, Gitlab reports the diff correctly.

Anyway, not your problem, nor mine.

Patch included.

esod → created an issue.

This bug surfaced when switching the widget from Entity browser to Autocomplete for an unlimited Entity reference taxonomy field. No problem making the switch, but when reloading the node form display, the page fatals. Patch #12 → get the node form display printing again.