🇸🇮Slovenia @KlemenDEV

As this issue is still stalling, does anyone have a patch for 10.3 at hand, otherwise I can try to prepare one later?

Great work, can't wait to have this in the release! :)

Is this needs work, or needs review?

The last patch seems to fix the ajax part of the problem I had

Thanks! :)

What would that translate to in the UI selection? Thanks for help!

What is the default caching strategy on a fresh install for the default search view? (to know what to revert to)

I have scanned the whole codebase with an automated script for any whitespace or new lines before <?php, but found none, however, I still experience AJAX problems such as modals not working. Is there something else I should also scan for?

It seems multiple modules as well as the core itself were affected by some change in 10.2 that caused this. This issue prevents many websites from updating to 10.2, while 10.1 EOL is getting closer and closer (17. 6. 2024)

I would be happy to help further if I understood the details of this, but this issue is probably preventing many websites from updating to 10.2

You have linked to this same page where there is no #35 comment

My issue is the JS error, but not style.

My issue is both in JS error (due to missing style) and missing style

I think this issue should be reduced to the original case of responsive images not working in rewritten fields and a new ticket should be open for other HTML tags needed.

I think the issue is deeper as this patch only fixes the consequence, but not the reason why styles are not properly passed to AJAX dialogs/popups

Additional findings show that https://www.drupal.org/project/drupal/issues/3414753 🐛 Drupal ajax error after D10 update from version 10.0.11 to 10.2.1 Needs review does not fix this issue

Ok so in my tests, https://www.drupal.org/project/ajax_comments/issues/3412943 🐛 Delete comment modal dialog broken with Drupal 10.2.x Active is partially (see my comment at https://www.drupal.org/project/drupal/issues/3409505#comment-15461560 🐛 Uncaught TypeError: Cannot read properties of null (reading 'style') (toolbar.js) Needs work ) fixed by https://www.drupal.org/project/drupal/issues/3409505 🐛 Uncaught TypeError: Cannot read properties of null (reading 'style') (toolbar.js) Needs work , but not fixed at all by #16 from this issue.

I have reported some findings at https://www.drupal.org/project/drupal/issues/3409505#comment-15461560 🐛 Uncaught TypeError: Cannot read properties of null (reading 'style') (toolbar.js) Needs work

I can confirm patch #2 fixes https://www.drupal.org/project/ajax_comments/issues/3412943 🐛 Delete comment modal dialog broken with Drupal 10.2.x Active , however, the look (CSS styling) of the popup dialog is still broken

Probably also related to https://www.drupal.org/project/drupal/issues/3409505 🐛 Uncaught TypeError: Cannot read properties of null (reading 'style') (toolbar.js) Needs work

RTBC from me too, I hope this can get into 10.2.x

Could this be related? https://www.drupal.org/project/drupal/issues/3409505 🐛 Uncaught TypeError: Cannot read properties of null (reading 'style') (toolbar.js) Needs work

Thanks, I will take a look :)

I will try to test if this is the case for this issue too when I get some time: https://www.drupal.org/project/ajax_comments/issues/3412943 🐛 Delete comment modal dialog broken with Drupal 10.2.x Active

It is also custom link dialog + bootstrap theme + css + js

KlemenDEV → created an issue.

MR got some confirmations at https://www.drupal.org/project/clamav/issues/3058018 🐛 Use of Max Resolution on Image Field causes ClamAV Timeout in Deamon mode Needs review too, so I believe the MR fixes the problem.

Will this be merged in 11.x only or will 10.1/10.2 get a backport of this?

I can now confirm RTBC based on 2-week running experiment on one of the sites, LGTM

I am currently lost what to take for the next step in debugging this, but would be happy to help if anyone has any suggestions for the next steps to take

Could this be duplicate of https://www.drupal.org/project/ajax_comments/issues/2896916 🐛 Ajax not working when using non-default view mode. Needs review ?

Oh sorry, didn't catch that one

KlemenDEV → created an issue.

KlemenDEV → created an issue.

This is happening again, now when I updated from Drupal 10.1.x to 10.2.x

This allso happens with Bootstrap's modal dialogs

#3410303: FilterHtml data loss when iframe and/or textarea is allowed indeed fixes this issue

RTBC by me

Could any maintainer merge this into a release? This issue could be preventing people from updating to 10.2.x unless they opt to use a patch

Ok I have used a wrong term. I mean data loss on render, not in the database. Sorry for the confusion.

I will spin up local instance of our system and try it out and report back

Could be, I am also using iframe as the HTML tag allowed, alongside some div tags with custom classes

I can confirm the MR fixes the bug for our websites and does not seem to introduce any additional regressions.

In further tests, it seems this only happens if one defines HTML tags that already exist or variations of them with custom attributes or attribute values allowed. If a tag added here is a tag that is not added by any other plugin, it seems to work fine.

KlemenDEV → created an issue. See original summary → .

KlemenDEV → created an issue.

#12 seems to fix this problem for me

If one references MR directly (e.g. https://git.drupalcode.org/project/drupal/-/merge_requests/5877/diffs.patch), additional MR pushes will reflect in the patch file on the link too. Technically, someone could push malicious code and when updating with the composer, those changes would be picked up.

On drupal.org, uploaded patches can't be altered, so once validated by the user using it, they can be sure the contents of the file on the link will not change.

I can't find the original page where this was mentioned, but here is a similar discussion: https://github.com/cweagans/composer-patches/issues/347

Thanks @O'Briat! Since it is advised to use patches from drupal.org and not from drupalcode.org, I am attaching a patch file for the ones needing this on 10.2.x and want to use the patch made from the MR

New MR seems to work for me

Ok another attempt, this time only modifying legacy test and not FileImageDimensionsConstraintValidatorTest

I have attempted to make a patch for 10.2.x myself. Feel free to use the patch for the merge request as making one myself is outside my knowledge of Drupal's Git system currently.

Can confirm #49 still applies to D10.2 and fixes the original issue of this ticket before it branched to fixing more than just that:

Xss::filterAdmin() is currently stripping out the picture & source html elements that are part of the Core module Responsive Image. $adminTags sets the elements that are whitelisted and would need to be updated.

I hope this issue will be merged into the core soon as without this fix, responsive images can't be used in the views rewrite filter at all.

Could someone merge this with 10.2.0, so the patch can be used on Drupal 10.2.0 websites? Thanks!

Doing tests with my patch for 1.10.x from comment #42, I can confirm it fixes the problem and works fine for me

I can confirm applying patch from #3292350 fixes this issue too

Ok, so I have figured out how to make a patch from the MR. I am attaching a patch for 10.1.x in case someone needs it.

Is there any patch for this for 10.1.x?

Turns out it was apparmor issue on Ubuntu. Adding Drupal files folder to AppArmor read permission for clamav fixed this.

I will leave issue open if someone wants to add some logging (if this is technically doable) to this module to not just silently fail in those cases

This is still bug in D10

Is this related to https://www.drupal.org/project/drupal/issues/2833968 ✨ Upload progress using jQuery.form plugin instead of 3rd party PHP libraries Needs work ?

Is this related to https://www.drupal.org/project/drupal/issues/1561866 📌 Add support for built-in PHP session upload progress Needs work ?

Related: https://www.drupal.org/project/views_distinct/issues/3384098 ✨ Drupal 10 Compatability Active

I think this is indeed a file permissions issue as the daemon can't access the files.

It may be good to log some error when this happens

Hi, thanks for the suggestion. I will verify this asap

Ok tested with 2.0.2, same problem. Nothing is logged in the logs, the status page detects ClamAV correctly, though.

Code still seems to hang at $response = trim(fgets($scanner_handler));

I've had this happen with 2.0.2-rc1. Did you change anything else that made it work?

Needs work or is it needs review?

CKEditor fixed the issue https://github.com/ckeditor/ckeditor5/issues/14146 and https://github.com/ckeditor/ckeditor5/issues/5154

Thank you for the release!

Very glad to see this in RTBC :)

Possible duplicate/related to https://www.drupal.org/project/advagg/issues/3308099 📌 Document which parts of the module are still relevant after aggregation changes in 10.1.0 Needs review . Seems at the time of writing advagg is not suitable for use with Drupal 10.1.x+. We are waiting for maintainers to make a plan forward with this module, but for now it may be better to use core aggregation and compression features

Possible duplicate/related to https://www.drupal.org/project/advagg/issues/3308099 📌 Document which parts of the module are still relevant after aggregation changes in 10.1.0 Needs review . Seems at the time of writing advagg is not suitable for use with Drupal 10.1.x+. We are waiting for maintainers to make a plan forward with this module, but for now it may be better to use core aggregation and compression features

Nice to see this moving!

Any new findings? Or a way to get this working/workaround?

Just wanted to confirm that I have been using dev version for a while now and all looks good :)

I have tested the patch from #60 (#68) on copies of some of our websites and it seems to work correctly. Hoping the remaining issues get fixed and this gets into 10.1.x. Forum functionality works and I did not notice anything problematic logged.

As this is holding back the update of many of the websites, could someone with more knowledge on this confirm whether we can use 10.1.x without this patch applied and ignore the status page error, or are there other consequences?

To clarify on #25, bundler does not work if advagg is disabled, meaning all advagg logic will need to run in order to use bundler right now

Given #60, is this needs review, or still needs work?

There is the ADVAGG bunder module where one can set a number of files it is aggregated to, meaning one can set it to eg. 15 files which is good trade-off for HTTP2. I think something similar in core would be very beneficial.

Thanks for the info @prudloff. I guess bundler could then be its own module in the future.

Btw is there any new progress on the plans for the advagg as a whole?

I can confirm again #8 works fine on multiple production sites and this issue seems RTBC and for release

I can confirm again #17 works fine on multiple production sites and this issue seems RTBC and for release

Thanks, will try it out!

Is there any workaround that we can use until this gets fixed in the core? This issue is holding back us from updating to Drupal 10.1

Neat, thank you for taking a look into this and fixing it :)

Thanks for the tests @prudloff. So bundler seems to work even if "Enable advanced aggregation" is not enabled?

Could be similar to https://www.drupal.org/project/drupal/issues/3368769 🐛 10.1.x breaks Nginx + PHP-FPM with too many redirects even when nginx config is changed Closed: works as designed

Are you testing as that role on a comment that has been created less than 60 seconds ago?

Yes, it is done in 60 seconds timeframe. The testing also goes well if the module version is reverted (same config and same test procedure).

Attached is the content type config.

Authenticated user has the following permissions (I can't screenshot this page due to confidentiality):

* "Content: Allow (content type) Comments hard delete"
* "Delete own comments"