Hungary, Budapest
Account created on 24 May 2006, over 18 years ago
  • developer at Gizra 
#

Merge Requests

More

Recent comments

🇭🇺Hungary aron novak Hungary, Budapest

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.

🇭🇺Hungary aron novak Hungary, Budapest

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.

🇭🇺Hungary aron novak Hungary, Budapest

I added local_vars_dump too, this is also essential to avoid OOM errors on more complex sites.

🇭🇺Hungary aron novak Hungary, Budapest

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.

🇭🇺Hungary aron novak Hungary, Budapest

We tested it on a client project, worked well.

🇭🇺Hungary aron novak Hungary, Budapest

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.

🇭🇺Hungary aron novak Hungary, Budapest

Aron Novak created an issue.

🇭🇺Hungary aron novak Hungary, Budapest

Aron Novak created an issue.

🇭🇺Hungary aron novak Hungary, Budapest

I am happy to merge a MR, there are some conflicts actually.

🇭🇺Hungary aron novak Hungary, Budapest

Partially addressed, thanks!

🇭🇺Hungary aron novak Hungary, Budapest

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.

🇭🇺Hungary aron novak Hungary, Budapest

We need to note that not all feeds were affected, 4 of ~20 only. However those generated ~50 GB disk usage.

🇭🇺Hungary aron novak Hungary, Budapest

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

🇭🇺Hungary aron novak Hungary, Budapest

it is caused by a patch, it is not broken in the module itself.

🇭🇺Hungary aron novak Hungary, Budapest

Aron Novak created an issue.

🇭🇺Hungary aron novak Hungary, Budapest

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

  1. Install PHP 7.4 or higher.
  2. Use the Symfony YAML Unescaper class to unescape characters in a YAML string.
  3. 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

🇭🇺Hungary aron novak Hungary, Budapest

Aron Novak created an issue.

Production build 0.71.5 2024