Actually the try-catch is already there, it merely generates a watchdog entry.
The patch was applied to latest dev as a MR, also I added test coverage.
Let's see if tests do pass.
aron novak → made their first commit to this issue’s fork.
We could reproduce it while creating media entities via a bulk upload form, also during migrations.
aron novak → created an issue.
I had the chance to think about it more.
For the sake of as realistic integration test as possible, we'd still prefer to have all parts of Crowdsec enabled, like on LIVE.
(Any non-trivial software can and will cause surprises. An example: https://github.com/sirbrillig/phpcs-variable-analysis/issues/340 - a widely used and trusted package suddenly broke our CI.)
What if we introduce a "dry mode"? It's like doing really everything, except that it does not use Ban module to block the IPs, but for instance the logger to say it would ban that IP for X amount of time in non-dry mode. How does this sound?
During installation, we faced with this edge case. let's not assume that the IP is always present.
This is extracted from https://git.drupalcode.org/project/crowdsec/-/merge_requests/5 , that was abandoned in the end.
aron novak → created an issue.
I agree that `$config['crowdsec.settings']['whisper']['enable'] = 0;` should be fine in these cases.
There was one robustness improvement in the MR that's still valuable, I'll propose that separately.
Going to set back the status where it was originally.
I just added support for username too, good point.
One of the large Drupal-specific PaaS providers does expose Redis to the public internet, so you can debug it easily, then, they of course protect it with authentication.
Of course we can make it configurable.
If the MR is in good direction, we can extend it to handle IPv6, loopback and so on.
I think this is generally valid that non-public addresses should not be included in the business logic of this module.
We needed to solve it for the sake of our automated tests.
And I am sure crowdsec must be enabled during the tests. If ever it would cause a crash somewhere, the test suite of the site must be aware of that.
Will provide a MR soon.
aron novak → created an issue.
aron novak → created an issue.
For the record, this happens on the same site:
https://www.drupal.org/project/drupal/issues/3116503#comment-15853664
🐛
Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "menu" entity type did not specify a storage handler. in Drupal\Core\Entity\EntityTypeManager->getHandler() (line 27
Active
The entity definition for "menu" is impartial after cache clears sometimes.
We experience this on 10.3.6.
/admin/structure/menu throws this strange fatal error.
$a = \Drupal::entityTypeManager()->getDefinition('menu');
print_r($a);
As you can see, the menu definition gets impartial, but it's not behaving the same way at every cache rebuild.
If there would be a faulty alter hook, I'd expect that it would kick in every time.
A cache clear may or may not fix it. The subsequent cache clear may break it again.
On this site, which is domain-enabled, high traffic site, it seems like a race condition. However I could reproduce it on a low-traffic non-live environment too, while trying to access admin pages during a cache clear.
We do not use Redis, APCU, only pure database backend for the bins.
I added local_vars_dump too, this is also essential to avoid OOM errors on more complex sites.
aron novak → created an issue.
aron novak → created an issue.
joelpittet → credited aron novak → .
Aron Novak → created an issue.
https://www.drupal.org/project/protect_form_flood_control → is a very good candidate for solving this, having IP-based protection, we applied it successfully at a client project.
Aron Novak → created an issue.
We tested it on a client project, worked well.
Aron Novak → created an issue.
Aron Novak → created an issue.
It seems it is already fixed. The current DEV contains:
$url = "https://management.azure.com/subscriptions/" . $subscription_id . "/resourceGroups/" . $resource_group_name . "/providers/Microsoft.Cdn/profiles/" . $profile_name . "/$endpoint_type/" . $endpoint_name . "/purge?api-version=" . $api_version;
And endpoint_type can be "afdEndpoints", based on the settings.
Aron Novak → created an issue.
Aron Novak → created an issue.
Aron Novak → created an issue.
Aron Novak → created an issue.
Aron Novak → created an issue.
Aron Novak → created an issue.
I am happy to merge a MR, there are some conflicts actually.
Partially addressed, thanks!
Thanks ekes!
MegaChriz → credited Aron Novak → .
https://git.drupalcode.org/project/auto_alter/-/merge_requests/8 - some documentation updates
I will try to come up with a test, what I concluded that the problematic Feeds have URLs that returns 404 error, not HTTP 200.
We need to note that not all feeds were affected, 4 of ~20 only. However those generated ~50 GB disk usage.
Aron Novak → created an issue.
Aron Novak → created an issue.
Aron Novak → created an issue.
This patch causes a fatal error actually, see:
https://www.drupal.org/project/physical/issues/3365817
🐛
Fatal error when the unit is not a dropdown
Closed: won't fix
it is caused by a patch, it is not broken in the module itself.
Aron Novak → created an issue.
Aron Novak → created an issue.
Aron Novak → created an issue.
Problem/Motivation
The current code in the Symfony YAML Unescaper class is not compatible with PHP 7.4 due to the use of curly braces for string offset access. This has been deprecated in PHP 7.4 and will result in errors when running the code on newer PHP versions.
Steps to reproduce
- Install PHP 7.4 or higher.
- Use the Symfony YAML Unescaper class to unescape characters in a YAML string.
- Observe the deprecated error caused by the use of curly braces for string offset access.
Proposed resolution
Update the code in the Symfony YAML Unescaper class to replace the deprecated curly braces with square brackets for string offset access, as shown in the provided patch.
Remaining tasks
- Review and apply the provided patch.
- Run tests to ensure compatibility with PHP 7.4 and higher.
User interface changes
None
API changes
None
Data model changes
None
Aron Novak → created an issue.
Aron Novak → created an issue.
Aron Novak → created an issue.
Aron Novak → created an issue.
Aron Novak → created an issue. See original summary → .