🇸🇮Slovenia @KlemenDEV

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

This will break websites that use HTML in comment bodies of "Default mail text for sending out notifications to commenters" or "Default mail text for sending out the notifications to entity authors", which includes some of our websites.

As it was possible to put HTML there so far, I think it is reasonable to expect this to continue to work.

Left RTBC for https://www.drupal.org/project/comment_notify/issues/3474577 🐛 Unable to access Configuration area after module Install Active

Tested on Drupal 11.1.1 and 10.4.1 and the configuration page opens in both instances with this MR applied as a patch

Will do, let me spin D11 test env, a good chance to test other modules that have already been updated too

RTBC from my side too!

Any updates on this?

Seems the two linked issues are RTBC

For a few of our websites, this is the only module we are waiting for D11 support to land

Thank you for work on this and big thanks to the sponsors!

Thanks for the clarification and happy holidays!

So this is fixed, but not released, right? Because I still can't update toolbar to 2.0 due to version constraints with Gin 4.0.0

I have reported this too but apparently

This isn't meant to fix all memory issues.

Thank you for looking into this!

When I click the user icon, the page just reloads, and I stay on the home page.

Additionally, there seems no way to access the dashboard in the new UI

Thanks to everyone involved in making this happen, especially to joseph.olstad for pushing the work :)

Does lack of this patch in 2.0.x make this module not usable in this release branch, or it still works and is this just a warning?

It was exactly that, users with email null. I am not sure how this can happen that user has null email, but removing those entries fixed the problem.

We have some users in the database that use "originalname+alias@domain.org" email formats. How is this handled after the recent case sensitivity cases?

Could this trigger the warning we see, or is something else also going on here?

Thank you everybody for your outstanding work on this! :)

klemendev → created an issue.

That is some very exciting news!

I think this is sort of duplicate of https://www.drupal.org/project/issues/advagg?categories=All →

But yes, seems this project stalled with Drupal 10.1+

Closed. Issue with custom module.

klemendev → created an issue.

Are there any outstanding changes needed on the module itself to run on Drupal 11?

This could work. But still keep the local files option available, because there are use cases/users (most of our websites, for example), where local files are used.

Awesome, thanks! :)

RTBC for a month now, should be good to merge?

We will do tests in the upcoming weeks, need to wait for some other modules to get a bit more ready and update internal modules