🇸🇮Slovenia @KlemenDEV

Account created on 7 October 2016, about 9 years ago
#

Recent comments

🇸🇮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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

Replied there :)

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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."

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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.

🇸🇮Slovenia KlemenDEV

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.

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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)?

🇸🇮Slovenia KlemenDEV

Wouldn't this also disable performance tracing of frontend?

🇸🇮Slovenia KlemenDEV

klemendev created an issue.

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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?

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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.

🇸🇮Slovenia KlemenDEV

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?

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

That is a good idea with a configurable list.

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

klemendev created an issue.

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

Fixing phpmailer lib to 6.10.0 "fixes" the issue

🇸🇮Slovenia KlemenDEV

klemendev created an issue.

🇸🇮Slovenia KlemenDEV

Thank you for running the project forward @mark_fullmer!

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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.

🇸🇮Slovenia KlemenDEV

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 :)

🇸🇮Slovenia KlemenDEV

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

The MR also applied cleanly to 10.5.x

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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.

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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!

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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 :)

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

"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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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.

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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.

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

Ok, I will provide more details there :)

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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?

🇸🇮Slovenia KlemenDEV

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.

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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:

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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?

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

🇸🇮Slovenia KlemenDEV

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

Production build 0.71.5 2024