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
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
Glad to see tracting here again! :)
Getting close to 1kb of CSS once remaining issues are in, this is down from 7kb originally.
That is amazing. Nice work!
I agree with @duaelfr, something should be done as this breaks frontend of non-admin users which can be problematic
Seems the correct approach would be using \Drupal\file\Plugin\Validation\Constraint\BaseFileConstraintValidator instead of what the change record suggested for replacing the hook
Should we move to needs review with the patch updated?
Happy to see movement on this issue. Thanks to everyone working on this!
Seems this module is not using the right event. The one currently used is for altering validation constraints, not for adding new one (source: https://www.drupal.org/project/drupal/issues/3506242 🐛 FileValidationEvent is not drop-in replacement for hook_file_validate Active - #3)
Aha, sorry, got confused for a second. Thanks for the clarification!
This was not released yet, right? I see this issue mentioned in https://www.drupal.org/project/honeypot/releases/2.2.1 → , but afaik 2.2.1 introduced https://www.drupal.org/project/honeypot/issues/3506174 🐛 PHP errors when a webform is closed Active , which is marked as duplicate of this issue
klemendev → created an issue.
Another update on my side. I have added this code snippet to the Unix socket scanner:
$file_size = filesize($file->getFileUri());
\Drupal::logger('ClamAV')->error('Size of file is: ' . $file->getSize() . ', URI is: ' . $file->getFileUri() . 'file size is: ' . $file_size);
When uploading a test file (PNG), on 2.0.3, I get this log:
Size of file is: 387365, URI is: /tmp/phpzipzoEfile size is: 387365
When uploading this same file on 2.1.0, I get this log:
Size of file is: 387365, URI is: /tmp/phpuX8xcsfile size is: 506707
It appears there is a difference between file sizes for some reason. The correct uploaded file size is 387365.
It seems that getFileUri() in 2.1.0 points to the wrong file, as it has a different file size.
Is there a chance the new event subscriber does not work the same as the old hook and does not fire at the same time in the file upload process as before? Therefore the file passed to the Scanner is not written yet/does not exist/has the wrong size?
With 800 sites using 2.1.0 and no one else joining this report, seems this is not a widespread problem.
Does anyone have any ideas on what else I could try or how to debug this problem further?
I can confirm this bug. It breaks the webforms for those users
More testing has been done.
Even if I switch from a Unix socket to a TCP connection, the same thing happens.
In 2.0.3, both socket and TCP connection work, in 2.1.0, the upload simply hangs and file is never uploaded to the website
Are there any updates on this?
That's not true. I just installed the module and put in HTML tags, and they just show up as tags/text in the email.
I use Mime Mail and it sends out HTML tags rendered. So this is true for such users. The module page only recommends the Queue Mail module, but not Drupal Symfony Mailer. It may be good to mention this in the release notes once the release is out :)
Thanks for opening up a follow-up issue for tags support! We use HTML to add a styled button to the email to view the comment.
I don't have xDebug installed unfortunatelly. I have added some debug logs and found out the line where it hangs, it is DaemonUnixSocket.php, this line:
$response = trim(fgets($scanner_handler));
So basically on 2.1.0, when file is uploaded, the upload process on the form gets stuck on this line.
I have checked 2.0.3 to 2.1.0 diff and indeed here nothing was changed, yet on 2.0.3 it works flawlessly and as soon as I update to 2.1.0, it gets stuck when uploading the file. It seems fgets call never returns.
Since scanning logic didn't change, could it be that there is some "contextual" or threading difference between the old hook and new event subscriber that could cause this? I have done some searching and it seems fgets may not play well in a multi-threaded environment (and e.g. multiple users uploading files at the same time). It could be a complete shot in the dark, I have very little experience with PHP and streams.
Glad to see movement here, looking forward to D11 support!
If selecting "Allow unchecked files" does not change the behaviour suggests that there are some issue with setup
I would also usually suspect this, but what sort of disproves this theory is that downgrading to 2.0.3 immediately fixes the problem.
Are there any differences in how 2.0.3 communicates with ClamAV via the Unix socket compared to 2.1.0?
Do you have access to ClamAv logs?
Yes, I do. I have checked logs and in the time interval when I was doing tests with 2.1.0, nothing unusual was logged.
In the meantime I would like you to provide the logs
The problem is nothing is logged, it just doesn't work and gets stuck. Even enabling verbose logging does nothing, it just gets stuck when uploading a file. I have logging redirected to syslog and it is confirmed to work.
Does it timeout or gives you an error?
If I select a file from the computer, file just remains selected but never uploads. No error is shown to the user, it just sits there in the "file chooser form element" and loading bar or throbber (depending on setting) is shown. Then after a few minutes, loading indicator disappears but the file is still not uploaded. Nothing is logged, even with verbose logging on.
Does it connect to ClamAv?
I think so. If I change the unix socket path to something that is not valid, the upload terminates with the following message:
The anti-virus scanner could not check the file, so the file cannot be uploaded. Contact the site administrator if this problem persists.
It also logs that clamav can't be accessed to syslog.
If the path is fixed back to a valid unix socket path, the infinity upload without error behavior comes back.
Does it work when you set Allow unchecked files?
No. Selecting "Allow unchecked files" does not change the behavior of the issue.
---------
I don't know the internals of the module so I can't debug myself, but I can place some debug prints in sections of the code as instructed and can provide what parts of the code are reached if this can somehow help.
Seems recaptcha classic will go soon: https://cloud.google.com/recaptcha/docs/migrate-recaptcha
I have tried making a new key in Google Cloud Console and the website key did not work - recaptcha field then shows invalid website key.
Will this issue fix this or should I open new one?
Solution to anyone also affected. Downgrade to 2.0.3 and everything immediately starts to work again
klemendev → created an issue.
Since #3165283 is not directly D11 related and the other D11 issue seems fine, maybe release without this issue could be made?
Unfortunately https://www.drupal.org/project/comment_notify/issues/3165283 💬 comment:body token arriving with HTML tags RTBC still needs work