🇸🇮Slovenia @KlemenDEV

We have some custom extensions that we serve via CDN and this limitation even at 5 characters prevents us from using CDN for those file types

Glad to hear this, hope we get a stable version covered by the security team soon!

Replied there :)

This is what we have done previously, but it only seems to work for a while, then the warning is back. Btw is there any problem of having this warning if we don't use antispambot?

Although, we would love to be able to use this feature eventually

I can also confirm this. I will try the patch later

Yes, the patch is still applied as we apply patches using Composer and have not removed any of the patches from the list.

The error reads:

"CleanTalk SFW update error: updateWorker: Wrong update ID. Please, save settings to run new SFW update and wait for an hour."

I may consider it after I get the hang of how this works (hook vs library), thanks for the assistance :)

This is the first time me working with hook_js_settings_alter. I must have misread the docs as I sort of understood one can alter JS via this hook or alternatively with custom JS library

Sorry, just posted the edit. It may have been reports from people already having the page open from before I made this change. I will wait some more, but the frequency of them has already reduced, so I assume this is likely what happened/is happening.

I have now tried

function CUSTOM_MODULE_js_settings_alter(array &$settings)
{
    if (!empty($settings['raven']['options'])) {
       $settings['raven']['options']['defaultIntegrations'] = false;
    }
}

and I can see defaultIntegrations set to false in the frontend, but I am still receiving JS errors in Sentry.

We are getting the fault again, despite the patch being applied

I have tried this, but it does not seem to work:

function CUSTOM_MODULE_js_settings_alter(array &$settings)
{
    if (!empty($settings['raven']['options'])) {
        $settings['raven']['options']['beforeSend'] = Markup::create('function (event) { return null; }');
    }
}

What would be the correct way to apply filtering in a way not to send any JS errors to Sentry (while keeping web vitals tracking)?

Wouldn't this also disable performance tracing of frontend?

klemendev → created an issue.

As I was asked to open a new issue, here it is: https://www.drupal.org/project/redis/issues/3550431 🐛 Out of memory on /admin/reports/redis Active

More context: disabling the "Render cache entries with most variations" section fixes the issue.

Would it be possible to somehow sort those entries or aggregate them to only show the worst ones?

I see, thanks for this clarification, in this case, it is actually closer to 80%, so closing this ticket :)

I measure rate by comparing hits vs misses, I observe the graph in NewRelic Redis monitor. I see, I will check if I can setup monitoring for reads vs writes.

That the page fails high redis maxmemory is known and there area some existing issues.

Last time I wrote on one of those issues I was asked to make a new one for my specific case, so I did that now, fingers crossed it can be improved so I can see some stats directly from Drupal without manual scripts.

Sorry for bumping this, but is there a way to remove "user.permissions" context from blocks that we are 100% sure can be shown to all users to reduce cache use of same blocks with different cache keys?

Opened a separate issue at https://www.drupal.org/project/redis/issues/3550431 🐛 Out of memory on /admin/reports/redis Active for reports page running out of memory

klemendev → created an issue. See original summary → .

That is a good idea with a configurable list.

The issue with reports is that the report page runs out of memory when trying to load cache contexts. I will open a separate report for this.

Btw, I have seen ~5% improvement if using allkeys-lru instead of volatile-lfu. Is using allkeys-lru safe with this module and the configuration above? I do not see docs reporting allkeys-lru as being ok to use, so I wanted to double-check on that

klemendev → created an issue.

Found it.

The problem is recipient is now a user, while before it was an email string. Now thus printing in mimemail-message.html.twig breaks sending. We have fixed changed twig template to not use "recipient", but it may be good to have a notice about this on the release page.

A side question: how are we supposed to determine if the "recipient" twig variable is a string or a user variable? In some cases it will be string, when we want to print raw value, in other cases it is user, where we need to convert it to email to use it as email field like we did before

LGTM functionality-wise, but will leave to someone else to approve it code-wise

I more or less just have the module installed, default configuration. Unfortunately, I don't seem to get a stack trace, only a line log with the error shown above. I will try to get the stacktrace

So I have comment notify installed (and ajax comments, but don't think this is relevant), both more or less stock configuration, and when a new comment is posted with 2.0.0 mimemail, ajax request from ajax comments returns 500, and checking server logs, the "user cannot be printed" error is logged

I have verified email templates and we don't do any direct printing of user in templates, so the issue must originate from something else that changed in this module in this version

Could this introduce this bug? https://www.drupal.org/project/mimemail/issues/3549125 🐛 Comments stopped working after updating to Mime Mail 2.0.0 combined with Comment Notify Active

Fixing phpmailer lib to 6.10.0 "fixes" the issue

klemendev → created an issue. See original summary → .

klemendev → created an issue.

Thank you for running the project forward @mark_fullmer!

Glad to see getting potential new maintainer and eventually D11 release!

As per my comment #15, RTBC from my side

I am not sure if it makes to apply this patch to the module, it is more of a workaround. I posted the patch for anyone needed a quick solution rather than as a suggestion to be merged to the module.

The right solution is https://www.drupal.org/project/drupal/issues/3522463 🐛 FileValidationEvent may not report the correct file size Active

I also agree with #39 that the ClamAV event subscriber should run before the resizing happens. I suggest going back to needs work and changing the order of subscribers, but this is not something I know how to implement.

I do believe as per rules you linked it was RTBC, also as per o'briat judgement of why tests were failing, but I will not leave to someone else to RTBC this issue/MR :)

I confirm the merge request fixes the issue with ClamAV not working with resized images.

The MR also applied cleanly to 10.5.x

Closing as duplicate of https://www.drupal.org/project/drupal/issues/3522463 🐛 FileValidationEvent may not report the correct file size Active

I agree it would make sense to run ClamAV first. During resizing, a carefully crafted payload could already execute malicious code technically.

Anyways, I can confirm this is fixed by changing how the file size is read or by patching core by https://www.drupal.org/project/drupal/issues/3522463 🐛 FileValidationEvent may not report the correct file size Active .

Attaching a patch for this module.

Closing as a duplicate of https://www.drupal.org/project/clamav/issues/3058018 🐛 Use of Max Resolution on Image Field causes ClamAV Timeout in Deamon mode Needs review

Since https://www.drupal.org/files/issues/2025-02-11/drupal-11-compatibility-3... → looks ok and both other issues are RTBC, marking this as RTBS too. Hope we get a Drupal 11 release soon!

Is there any alternative module that provides similar functionality to avoid having websites stuck on D10?

Any updates on this?

My doubt was mostly based on this comment: https://www.drupal.org/project/drupal/issues/3506242#comment-15990457 🐛 FileValidationEvent is not drop-in replacement for hook_file_validate Active

I am doing testing and will report back on the file size fix

Updated issue to use full template and filled out to best of my knowledge

Thanks, I will try both this and the branch on the other issue and report back

Don't think it is relavant, as ClamAV only uses/used hook_file_validate where the file size passed is incorrect if the file is resized

klemendev → created an issue.

Any updates on this? The module does not seem to be usable if images are resized starting with version 2.1.0

Thanks to helpful support from the support team, we were able to pinpoint the issue to stubborn caches.

I can confirm this fixes the cookie size at 16 bytes and value "0" which is fine and does not cause huge cookie issues.

Marking RTBC, hopefully this patch makes it into the module release :)

Opened ticket 49611

I can not send the video here. If needed, I can open a private ticket on your support pages to send it there.

But with https://www.drupal.org/files/issues/2025-06-30/skip_cookie_ct_pointer_da... → applied and all caches possible cleaned, I can confirm this patch makes it so ct_pointer_data has value "0" all the time and Chrome shows constant size 16, which is acceptable.

I have noticed it only happens if I log in to the website with admin account, so I guess this patch sort of fixes the issue for all users but admin.

Still strange why on the logged in admin account, ct_pointer_data still grows without limits.

Logged in or anonymous user, values are:

* ct_use_alt_cookies is 0
* ct_use_bot_detector is 1

I see, thanks for the clarification! In this case, this patch looks good and can be merged :)

"Use CleanTalk JavaScript library" is enabled on our website (checkbox is checked), and this patch ( https://www.drupal.org/files/issues/2025-06-30/skip_cookie_ct_pointer_da... → ) applied; however, we noticed that the size is still non-zero, and also grows significantly in some cases if moving the mouse and clicking a lot. It starts at size 16 and then grows.

EDIT: I have noticed it only grows when logged in. If the user is anonymous, it remains at size 16

This seems to work since it disables SFW updates if SFW is off. Since we don't use it right now, this is fine. If we need to use it, we may need to look into a more proper solution later down the road as this technically just "masks" the problem

I see, thanks!

klemendev → created an issue.

I can confirm that applying both patches at the same time fixes the issue:

- https://www.drupal.org/files/issues/2025-07-04/get_email_for_custom_node... →
- https://www.drupal.org/files/issues/2025-07-08/use_provided_user_email_o... →

I have reapplied the patch back to the site, so your developers can check our frontend again. From my checks, it seems patch was applied but pointer data cookie is still created

The patch fixed so the email is added correctly to the new content, but the patch does not add the same code to the forum topic handling code in the method cleantalk_validate_forum_topic, so when posting forum topics, the email is still not sent.

Thanks for the patch. I will install it and try it out later today. Will report back :)

You currently don't see the patch because we did not want to leave the patch that did not work on the production site, so we removed it after unsuccessful testing.

I am sure that the patch was applied correctly, but will do it again / install attached module zip later today.

If the use of alternative cookies is unacceptable. We decided to exclude this cookie if the "Use CleanTalk JavaScript library" option is enabled. Please install the attached patch for this.

Is this correct? Because looking at patch, only cleantalk_bot_detector and cleantalk_alternative_cookies_session parameters are checked, which we both have set to false on our production site.

Yes, "drush cr" and also in-UI "Performance -> Clear caches" and browser by going incognito.

In Google Chrome dev tools in cookies list, ct_pointer_data was still created.

"Use CleanTalk JavaScript library" is enabled, "Enable alternative cookies" is disabled, bot firewall setting is disabled too

Tried the patch with "Use CleanTalk JavaScript library" checked, but

ct_pointer_data

the cookie was still generated. Tried in incognito and made sure to clear all caches. Enable alternative cookies in the plugin settings may not be an option for us as we have relatively high-traffic website, although, I can't really estimate an impact of this alternative cookies option

Ok, will do so. Thanks!

Ok, I will provide more details there :)

We have "Use CleanTalk JavaScript library", so I will apply this patch and report back. Thank you for a quick reply and the patch :)

klemendev → created an issue.

Now uninstall fails every time. Is there any other way to fix the SFW update error?

I also don't think this was fixed. Should I open new ticket, or should this one be re-opened?

klemendev → created an issue.

CleanTalk SFW update error: updateWorker: Wrong update ID. Please, save settings to run new SFW update and wait for an hour..

This issue still appears from time to time and full module uninstall, cache clear and reinstall is needed. In some cases, uninstall causes WSOD before being able to fully uninstall too.

I figured that out as well :) Sorry for the inconvenience.

1)

PHP: 8.3.11
Drupal: 10.5.1
Server: nginx/1.24.0 with MySQL DB

2) We have observed this on forum topics by forum module, as well as when users post custom content types, but with built-in node forms. When editing nodes, the message body seems to be empty in every case.

We also have custom validators applied to those node forms using a custom module, but those validators only check for certain patterns in e.g., topic body and fail server-side form validation by using "setErrorByName".

Here you can see some examples with an empty message in logs:

I see, have a good weekend! :)

It also seem that when editing a certain node, empty message is sent in all cases - 100% reproducible

Any updates on this?

Could it be because we use Redis?

klemendev → created an issue.

Using 2.0.4 and it seems it indeed does not block some bots anymore

Done: https://www.drupal.org/project/drupal/issues/3522463 🐛 FileValidationEvent may not report the correct file size Active

klemendev → created an issue.

This may also be happening because the images are downsized if too big, and then two different sizes are in question - the true size and the resized one. Related: https://www.drupal.org/project/drupal/issues/3292350#comment-16093652 🐛 file_validate_image_resolution does not update file size after resizing Needs work

I think this becomes a problem again if FileValidationEvent is used instead of hook_file_validate, as since ClamAV module switched to this event, uploading of files that are later downsized is no longer possible as the module has wrong file size info again

This issue is back on ClamAV 2.1.0 that uses the new event instead of validation hook.

It seems resizing happens before that.

With https://www.drupal.org/project/drupal/issues/3292350 🐛 file_validate_image_resolution does not update file size after resizing Needs work applied, uploading works if too big image is uploaded and resized, but in 2.1.0, this is broken again

One inspiration may be File Hash module, which uses both FileValidationEvent and BaseFileConstraintValidator: https://www.drupal.org/project/filehash/issues/3383726 📌 Create file constraint and validator; and FileValidationEvent subscriber Fixed as a replacement of hook_file_validate

klemendev → created an issue.

Also, shouldn't this event still provide the correct file size when uploading, as if you check my post, the uploaded file data is not correct when using FileValidationEvent?

I don't have the knowledge to implement BaseFileConstraintValidator, would anyone be willing to mentor me in getting this resolved together?

Seems ClamAV module broke in some cases - https://www.drupal.org/project/clamav/issues/3503176 🐛 File upload stopped working after updating to 2.1.0 Active - after replacing hook_file_validate with FileValidationEvent

Looking at this change record - https://www.drupal.org/node/3363700 → - it recommends replacing hook_file_validate with FileValidationEvent. Is the change record wrong in this case? Because, as explained at https://www.drupal.org/project/clamav/issues/3503176#comment-15967597 🐛 File upload stopped working after updating to 2.1.0 Active , the module adapted the recommended event replacement