claudiu.cristea → made their first commit to this issue’s fork.
Wouldn't it be better to have this code in a separate sub-module? What do you think?
I think it would be overkill. The module is simple and, if you want to override the label then the description comes naturally.
It would be nice to have tests but I see the whole module lacks tests.
For me this works as expected.
You wrote "causes errors" but did not specify the errors. What are the errors?
I'm getting this error while running this Drush core command:
ddev drush why:module filter --type=module
TypeError: array_map(): Argument #2 ($array) must be of type array, string given in /var/www/html/vendor/drush/drush/src/Commands/core/DrupalDependenciesCommands.php on line 157 #0 /var/www/html/vendor/drush/drush/src/Commands/core/DrupalDependenciesCommands.php(157): array_map()
#1 [internal function]: Drush\Commands\core\DrupalDependenciesCommands->Drush\Commands\core\{closure}()
#2 /var/www/html/vendor/drush/drush/src/Commands/core/DrupalDependenciesCommands.php(156): array_map()
#3 /var/www/html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/ValidateHookDispatcher.php(53): Drush\Commands\core\DrupalDependenciesCommands->validateDependentsOfModule()
#4 /var/www/html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/ValidateHookDispatcher.php(42): Consolidation\AnnotatedCommand\Hooks\Dispatchers\ValidateHookDispatcher->doValidator()
#5 /var/www/html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/ValidateHookDispatcher.php(29): Consolidation\AnnotatedCommand\Hooks\Dispatchers\ValidateHookDispatcher->callValidator()
#6 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(195): Consolidation\AnnotatedCommand\Hooks\Dispatchers\ValidateHookDispatcher->validate()
#7 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#8 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#9 /var/www/html/vendor/symfony/console/Command/Command.php(318): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#10 /var/www/html/vendor/symfony/console/Application.php(1073): Symfony\Component\Console\Command\Command->run()
#11 /var/www/html/vendor/symfony/console/Application.php(356): Symfony\Component\Console\Application->doRunCommand()
#12 /var/www/html/vendor/symfony/console/Application.php(195): Symfony\Component\Console\Application->doRun()
#13 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#14 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#15 /var/www/html/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run()
#16 /var/www/html/vendor/bin/drush.php(119): include('...')
#17 {main}
TypeError: array_map(): Argument #2 ($array) must be of type array, string given in array_map() (line 157 of /var/www/html/vendor/drush/drush/src/Commands/core/DrupalDependenciesCommands.php).
[warning] Drush command terminated abnormally.
Failed to run drush why:module filter --type=module: exit status 1
It happens because dependencies is decoded as string rather than an array. The MR is fixing the issue.
claudiu.cristea → changed the visibility of the branch 4.x to hidden.
claudiu.cristea → changed the visibility of the branch 3363017-fix-upgrade-status-test-error-typo to hidden.
claudiu.cristea → changed the visibility of the branch 3538270-4.x to hidden.
We are getting the same error in 4.0.0-alpha4. Could you, please, reopen (I can't) and port to 4.x + a new release?
Composer lenient plugin is nothing without this. Luckily we have now tests but still needs:
- A change record
- Prepare a pice of text to update the documentation at https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-or-... →
claudiu.cristea → made their first commit to this issue’s fork.
claudiu.cristea → made their first commit to this issue’s fork.
Nice to see this completed. Thanks to all involved
Plural support has been added ✨ Support for plurals for 'config' plugins Active .
Closing this as duplicate of ✨ Support for plurals for 'config' plugins Active . It would be good if someone can test that.
In 📌 Support for plural strings (locale source) Needs review there is a MR which works for Locale strings but I've opened also ✨ Support for plurals for 'config' plugins Active to deal with configuration
Tests added. I've created
✨
Support for plurals for 'config' plugins
Active
as a followup to add plural support for config source plugin
claudiu.cristea → created an issue. See original summary → .
Also, this is not covering the tmgmt_config plugin, which has the same problems for translatable with plural. That should be subject for a followup
I think we don't need an update path for potential locale job items whose data is using the old structure (with only "singular" key). They will continue to work wit the old logic. But definitely, needs tests
claudiu.cristea → made their first commit to this issue’s fork.
This looks good, thank you all
@bojan_dev, if merged, could you, please, cut a new release?
We need a test that replicates the bug when the fix is not applied
Thank you for the fix. I have tested manually the MR and works as expect. However, given the impact of this bug, I'm sure it deserves a regression test.
On MR I've also proposed some minor improvements to documentation.
I can reproduce the issue with some page_manager routes. After installing simple_oauth, suddenly, the routes created by page_manager, normally accessible by authenticated user, are returning 403. I see this as Critical as breaks an existing site.
Alternative to CID namespacing is to create separate bins with a factory. Services that need a memory cache will just fabricate a new bin. I've suggested this in #17 🌱 [policy] Standardize how we implement in-memory caches Needs work
Nice that this has been finally fixed. I wonder if #2562107: EntityDisplayBase should react on removal of its components dependencies → could be reworked to use this standard approach.
I disagree. The module it's about users requesting but also managing OAuth2 clients (like manage secret and consumer's label). I do agree that the name is quit generic but it's not wrong. It's not only to request clients but also a user UI to list and manage their clients.
claudiu.cristea → changed the visibility of the branch 3552129-drupal-11.3 to hidden.
I can see the improvement. Thank you for your contribution.
Updating the IS after clarified the scope of this issue in #13 🐛 Allow default scopes to be set regardless of grant type Needs work .
More discussions took place on Slack, see https://drupal.slack.com/archives/C1BMUQ9U6/p1757918379890819
I'm fine because we made now everything faster in 📌 Improve ::getStrings() performance Needs review
claudiu.cristea → made their first commit to this issue’s fork.
What is covered:
The performance penalty is caused by the module's architecture, which compiles a long list of string translations by concatenating strings extracted from plugins. This is fragmenting the strings fetching from database.
A big problem is the config plugin which has a bottleneck when parsing the config translatable properties. Even the config translatables are cached, the method is called for each config adding a lot of time and overhead. This needed a special attention
To address the severe performance penalty, I've implemented caching of strings per-language. Each language creates its own cache entry.
The best architecture for this it turned to be a "strings cache collector", which allows to resolve cache misses on the fly.
Technical: