🇵🇱Poland @dmitry.korhov

I disagree with closing.
The problem is still there - loading all items at once.
It should be split into chunks or batches.

So, if aggregate query cannot be use, then let's try chunked loadMultiple?
E.g. we have 1000 blocks and we do load them in memory 50 per iteration.
Some iterators/generators stuff might help with memory utilization (see https://www.drupal.org/project/drupal/issues/2577417 📌 Add an entity iterator to load entities in chunks Needs work )

dmitry.korhov → created an issue.

Marking this ticket to "Needs work" again as there are still some issues for blocks that have few translations with different info (see previous comment to MR)

We found an issue with aggregated approach, when we add a new block into Layout of a page the block's plugin is considered as "broken/missing".
The root cause is in query itself, it does work differently in comparison with default approach:

count($this->blockContentStorage->loadByProperties(['reusable' => TRUE])); // 5932

count($block_contents = $this->blockContentStorage->getAggregateQuery()
      ->condition('reusable', TRUE)
      ->condition('langcode', $this->languageManager->getDefaultLanguage()->getId())
      ->groupBy('uuid')
      ->groupBy('info')
      ->accessCheck(FALSE)
      ->groupBy('type')
      ->execute();
); // 6277

> Lots of bug fixes are blocked from coming to the attention of project maintainers by reviewers who argue against allowing them to be fixed.

Many bug fixes go unnoticed by project maintainers due to a lack of motivation for contributors to review them. This is the real problem that needs to be addressed, rather than relying on workarounds like patches.

If you maintain your codebase manually using Composer, patches, etc., then we can agree that, in some cases, applying patches (hacks) is the only urgent solution.
However, Drupal CMS is designed as a one-click installation that works out of the box (OOTB). It should not require any patching—otherwise, it cannot be considered a production-ready application.

By supporting patches in Drupal CMS, we shift the system’s focus away from content creators and towards developers, who will then have to manage all these patches instead.

dmitry.korhov → created an issue.

> deployment as in config deployment?
drush deploy -y
The module should be able to be enabled without requiring configuration and without generating any log messages that could prevent deployment.

I disagree. Most use cases for this module involve Drupal CMS. For anything else, we have Composer, which supports patches.
Drupal CMS must be user-friendly - even if that means imposing some limitations, so that workarounds like patches aren’t necessary to make it work.
However, if Drupal CMS is not mature enough to work as intended OOTB, then the Drupal community and core maintainers have a real problem.

Hey, let’s not do this.

Patches are meant to be a temporary fix for a single issue: the delay in maintainers responding and merging changes.
Relying on patches as a long-term solution would make the system unstable and unpredictable.

Now, imagine having 30 core patches listed in your composer.json, and then trying to install another module on shared hosting—it would be a headache for everyone! Let’s not open that Pandora’s box for Drupal CMS :)

Instead, let’s focus on finding a better way to speed up fix merges so we can avoid relying on patches in the first place.

dmitry.korhov → created an issue.

the problem is that we have everything configured and it works flawlessly right after deployment w/o any further changes :)

dmitry.korhov → created an issue.

After clicking on icon user nothing is happened (see login-issue.mov).
It might be related to existing session from old www.drupal.org domain present but there is no menu to logout or refresh token in new frontend.

create a new issue https://www.drupal.org/project/gin/issues/3489203 🐛 Save button missing in modal for editing media using Media Library Edit module Active as the current one cannot be reopened

dmitry.korhov → created an issue.

If that's for Drupal CMS and not for every installation, why not to use separate `node/config/install` sub-folder that will install the relevant config?

smustgrave → credited dmitry.korhov → .

gitlab shows that there is a conflict in .module file, please rebase and fix

It seems that no more work is needed so we can go further

Looks good, approved.

@andy_w, shall we close this one and focus on https://www.drupal.org/project/drupal/issues/3485030 📌 MenuTreeStorage shouldn't invalidate cache tags if the menu didn't change Active instead?

@alexpott

vendor/bin/drush ev "var_dump(\Drupal\Core\Site\Settings::get('yaml_parser_class'));"
/vendor/drush/drush/src/Commands/core/PhpCommands.php(32) : eval()'d code:1:
NULL

Drupal version : 10.3.5
PHP version : 8.3.13
Drush version : 12.5.3.0

Looks straightforward, so there are no issues with merging this.

patch from latest comment did not apply on macOS, re-created fromdiff

dmitry.korhov → created an issue.

dmitry.korhov → created an issue.

dmitry.korkhau → created an issue.

Hi laurii,

Would be nice to respect all the contributors with credit for participating in resolving this issue.

Thanks

Rebased on latest 10.1.2 (10.1.x)

re-rolled agains latest version of module which is compatible with drupal 10.1

re-rolled for 10.1

re-rolled for 10.1

rebased for 10.1.1

dmitry.korhov → made their first commit to this issue’s fork.

driverok → credited dmitry.korhov → .

re-compile .js from es6.js

re-roll on drupal 9.5.x branch

dmitry.korhov → created an issue.

Hi @mark_fullmer,

We are using this patch for almost 3 months and I can confirm that it works as expected.
Thanks for your efforts (and marking it as RTBC :) )

driverok → credited dmitry.korhov → .

dmitry.korhov → made their first commit to this issue’s fork.

MR: https://git.drupalcode.org/project/dosd/-/merge_requests/9

dmitry.korhov → created an issue.

`mixed` return type should not be used, we know what kind of entity|variable is returned.

The field only displays overridden layouts, it does not work with default layouts.

There is a workaround for it, we managed it by triggering Enhancer (from JSONAPI Extras) manually in some event

@kuhikar please add interdiff

Any news so far? This functionality is pretty essential for decoupled Drupal.
Is https://www.drupal.org/project/drupal/issues/3151275 → a blocker?
Can we have this patch released at least as experemental module?