In our project, the error is most frequently caused by a URL like https://www.example.com/search?search=test&type= – so without parameter array notation and without a value. Shouldn't this be handled as an empty parameter? It also feels like a bug to me.
Here is a thread about this topic in crowdsecs support forum: Is CrowdSec acting against european privacy regulations?. It supports Jürgen's argument in #2 that the IPs may be transmitted for security purposes (see also https://www.privacy-regulation.eu/en/recital-49-GDPR.htm). If in doubt, you can also deactivate the transmission (this may only be possible in the paid version).
This module integrates with the CrowdSec API using their PHP SDK to verify the IP address of each request getting to your Drupal site against their block list and should an IP be listed for being banned, those requests will be rejected and responded with a 403 HTTP response status code.
No worries, the block list is cached locally, and no performance implications are expected.
Do I understand correctly that the IP addresses of incoming requests are only checked against a local block list and are not transmitted to CrowdSec or other third parties? So the transmission to Crowdsec only takes place for suspected bad IPs in order to share them with the community?
Since the update to Drupal 10.3, these errors are also occurring for us according to the log. I also don't know how to reproduce them, except by customizing the URL.
This issue is not present in current 8.x-1.x-dev because it has been resolved with Exposed filters don't work correctly in Drupal 10.1 due to GET request being used instead of POST 📌 AJAX GET in core: Alter ajax url query parameters Needs review . Closing this as a duplicate. I hope there will be a new release soon.
Here is a patch for the latest changes and an additional one with changes from #53 to support seven theme. Not sure if this theme be supported and therefor to be addressed in the MR.
I've added an extra option to address #15 but I guess we still need to update existing views, although I've used a default option which should not break them. Not sure how to do this update.
Setting version to next minor one for this new feature.
pminf → made their first commit to this issue’s fork.
We updated Drupal from 9.5.10 to 10.1.4.
@lendude The template doesn't seem to matter. The markup of all our field based feeds changed from
<pubDate>
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'core/themes/stable/templates/views/views-view-field.html.twig' -->
Tue, 26 Sep 2023 12:55:17 +0200
<!-- END OUTPUT from 'core/themes/stable/templates/views/views-view-field.html.twig' -->
</pubDate>
to
<pubDate>
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'themes/contrib/stable/templates/views/views-view-field.html.twig' -->
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'time' -->
<!-- BEGIN OUTPUT from 'themes/contrib/stable/templates/field/time.html.twig' -->
<time datetime="2023-09-26T12:55:17+02:00">Tue, 26 Sep 2023 12:55:17 +0200</time>
<!-- END OUTPUT from 'themes/contrib/stable/templates/field/time.html.twig' -->
<!-- END OUTPUT from 'themes/contrib/stable/templates/views/views-view-field.html.twig' -->
</pubDate>
As you can see we are using a theme based on contrib stable. But the issue is also present when using the current stark theme with core/modules/system/templates/time.html.twig:
<pubDate>
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'core/modules/views/templates/views-view-field.html.twig' -->
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'time' -->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/time.html.twig' -->
<time datetime="2023-09-26T12:55:17+02:00">Tue, 26 Sep 2023 12:55:17 +0200</time>
<!-- END OUTPUT from 'core/modules/system/templates/time.html.twig' -->
<!-- END OUTPUT from 'core/modules/views/templates/views-view-field.html.twig' -->
</pubDate>
I can confirm the workaround from #5:
<pubDate>
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view_field' -->
<!-- BEGIN OUTPUT from 'themes/contrib/stable/templates/views/views-view-field.html.twig' -->
Tue, 26 Sep 2023 12:55:17 +0200
<!-- END OUTPUT from 'themes/contrib/stable/templates/views/views-view-field.html.twig' -->
</pubDate>
(Ignore the whitespaces. They are not present if theme debug is disabled.)
Could you give some details, please. Which "trouble" did you had? How to check if everything works as expected?
Looks good to me. There seems to be no more open Drupal 10 issues and the module is still working as expected.
@Sam152, could you please commit these changes and publish a new release, which is compatible with Drupal 10? Drupal 9.5 EOL is coming very soon.
I made a rebase.
@rogerpfaff I reverted your commit from #25 and set the issue back to its previous state. Tests will pass and everything will be OK again :)
To solve the issue, I've catched the invalid argument exception when trying to get the URL from path.
We still need a test for URLs like https://my.site/:foo or https://my.site/:foo/bar.
The support for IE11 has been dropped → since Drupal 10.0.x. Furthermore Safari does support all methods of classList since version 7. So meanwhile the polyfill is only needed for Opera Mini (see supported browsers → and browser support for classList). I've updated the issue title and summary accordingly.
The last patch does include the polyfill for IE11 and Safari and therefore needs work (maybe just alter comments).
I've addressed #9 and made a separate MR based on 10.1.x (previous one has to be rebased).