Account created on 13 January 2016, over 8 years ago
#

Merge Requests

More

Recent comments

πŸ‡³πŸ‡±Netherlands Spokje

After watching a server die in the first test-run:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[08S01]:
Communication link failure: 1053 Server shutdown in progress:

, the second test came out just fine => RTBC for me.

πŸ‡³πŸ‡±Netherlands Spokje

Sadly this needs a reroll after the update of CKEditor landed

πŸ‡³πŸ‡±Netherlands Spokje

Lemme have a go at this, as I presume that @longwave is busy enough with more important RC1 stuff (like all other core committers ofc)

πŸ‡³πŸ‡±Netherlands Spokje

Code changes make sense and tests are green => RTBC

πŸ‡³πŸ‡±Netherlands Spokje

Fun stuff:

Apparently, if we don't add a core/.npmrc file with engine-strict=true, the restrictions in core/package.json "engines" are happily ignored.
https://stackoverflow.com/a/50798589

πŸ‡³πŸ‡±Netherlands Spokje

in which case why do we have glob 11 which only supports node 20?

Not sure but the whole MR was created using:

$ nvm use lts/hydrogen
Now using node v18.20.3 (npm v10.8.1)

Maybe glob isn't enforcing its own restrictions? *shrug*

πŸ‡³πŸ‡±Netherlands Spokje

- Tested MR!455 against the site on which I created the screenshot in the IS. Double check-boxes are gone, there's now only one, as expected.
- JS changes make sense.

This is RTBC for me.

Thanks for the _very_ quick turn-around!

πŸ‡³πŸ‡±Netherlands Spokje

Well, that's all (I can do for this issue) folks!

πŸ‡³πŸ‡±Netherlands Spokje

Apples are green, but since we have a cspell-bump, let's also do a $ yarn spellcheck:make-dict.

πŸ‡³πŸ‡±Netherlands Spokje

With all of the above mentioned dependencies taken out, we're left with:

@floating-ui/dom ---^1.6.5  => ^1.6.7 
cspell -------------^8.8.1  => ^8.10.4
glob ---------------10.3.14 => 11.0.0 
jsdom --------------^24.0.0 => ^24.1.0
postcss-preset-env -^9.5.11 => ^9.6.0 
postcss ------------^8.4.38 => ^8.4.39
prettier -----------^3.2.5  => ^3.3.2 
terser -------------^5.31.0 => ^5.31.1
webpack ------------^5.91.0 => ^5.92.1

Let's see how Testbot likes them apples!

πŸ‡³πŸ‡±Netherlands Spokje

Regarding:
-

Bah, we can't update stylelint because of stylelint-formatter-gitlab: https://gitlab.com/leon0399/stylelint-formatter-gitlab/-/issues/3

@longwave in #3439522-16: Update JavaScript dependencies for Drupal 10.3/11.0 β†’

Seems like stylelint-formatter-gitlab is basically abandoned.

Since we shouldn't be held back by test-formatting-tools to upgrade our tooling, we might want to look for an alternative.
This might be one, although not a composer, but rather a JS dependency: https://github.com/tijsverkoyen/stylelint-formatter-gitlab-code-quality-....

Unsure how to proceed with this.

πŸ‡³πŸ‡±Netherlands Spokje

nightwatch breaks tests (won't say per usual, whoops I just did) when doing the major upgrade (https://git.drupalcode.org/project/drupal/-/merge_requests/8714) as well as the minor upgrade (https://git.drupalcode.org/project/drupal/-/merge_requests/8715).

Since I'm not exactly sure what the status is on this with regards to the (great) lullabot/* improvements lately, I need some guidance if we want to try and do this update for drupal 11 or not.

Not creating a child issue for that until that happens.

πŸ‡³πŸ‡±Netherlands Spokje

glob is doing a major jump from 10.3.14 to 11.0.0, which should give it a child issue, however, in a test-MR I prepared earlier, there are no test-failures when upping it.
(See https://git.drupalcode.org/project/drupal/-/merge_requests/8713)

I therefore think we can roll that upgrade into this issue.

πŸ‡³πŸ‡±Netherlands Spokje

Current situation:

$ yarn upgrade-interactive

? Pick the packages you want to upgrade.          Current          Range            Latest

   @ckeditor/ckeditor5-alignment --------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-autoformat -------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-basic-styles ------------ β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-block-quote ------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-code-block -------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-editor-classic ---------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-editor-decoupled -------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-essentials -------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-heading ----------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-horizontal-line --------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-html-support ------------ β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-image ------------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-indent ------------------ β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-language ---------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-link -------------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-list -------------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-paste-from-office ------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-remove-format ----------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-show-blocks ------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-source-editing ---------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-special-characters ------ β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-style ------------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @ckeditor/ckeditor5-table ------------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   @floating-ui/dom ---------------------------- β—‰ ^1.6.5 ------- β—― ^1.6.7 -------
   ckeditor5 ----------------------------------- β—‰ ~41.3.1 ------                  β—― ~42.0.0 ------
   cspell -------------------------------------- β—‰ ^8.8.1 ------- β—― ^8.10.4 ------
   eslint -------------------------------------- β—‰ ^8.57.0 ------                  β—― ^9.6.0 -------
   glob ---------------------------------------- β—‰ 10.3.14 ------ β—― 10.4.4 ------- β—― 11.0.0 -------
   jquery-ui ----------------------------------- β—‰ ^1.14.0-beta.2                  β—― ^1.13.3 ------
   jquery -------------------------------------- β—‰ 4.0.0-beta ---                  β—― 3.7.1 --------
   jsdom --------------------------------------- β—‰ ^24.0.0 ------ β—― ^24.1.0 ------
   nightwatch ---------------------------------- β—‰ 2.4.2 -------- β—― 2.6.25 ------- β—― 3.6.3 --------
   postcss-preset-env -------------------------- β—‰ ^9.5.11 ------ β—― ^9.6.0 -------
   postcss ------------------------------------- β—‰ ^8.4.38 ------ β—― ^8.4.39 ------
   prettier ------------------------------------ β—‰ ^3.2.5 ------- β—― ^3.3.2 -------
   stylelint-config-standard ------------------- β—‰ ^34.0.0 ------                  β—― ^36.0.1 ------
   stylelint-prettier -------------------------- β—‰ ^4.1.0 -------                  β—― ^5.0.0 -------
   stylelint ----------------------------------- β—‰ ^15.11.0 -----                  β—― ^16.6.1 ------
   terser -------------------------------------- β—‰ ^5.31.0 ------ β—― ^5.31.1 ------
   webpack ------------------------------------- β—‰ ^5.91.0 ------ β—― ^5.92.1 ------
πŸ‡³πŸ‡±Netherlands Spokje

Should we do something similar to πŸ“Œ Update Composer dependencies for 11.0.0-rc1 Needs review for JS-dependencies?

πŸ‡³πŸ‡±Netherlands Spokje

Fine by me, RTBC.

πŸ‡³πŸ‡±Netherlands Spokje

Ah ok, so my question boils down to: If we raise the recommended version and the version we run tests on is 1.11.7, should we still advertise the 1.11.1 version as a minimum, or should we bump to 1.11.7 in the root composer.json?

Highly unlikely this will break something in this instance, but might do in a future update and it "just" feels weird to allow a minimum version that we don't actively test on.

But n=1, yadada and if it's decide that's OK, I'm fine with it.

πŸ‡³πŸ‡±Netherlands Spokje

As far as I can tell the latest commit on the MR changes the version of PHPStan core/tests/PHPStan/composer.json to 1.11.7?
https://git.drupalcode.org/project/drupal/-/merge_requests/8701/diffs?co...

πŸ‡³πŸ‡±Netherlands Spokje

Dropped a comment in the MR.

πŸ‡³πŸ‡±Netherlands Spokje

Added a 10.3.x MR, which is basically the diff from the 11.x MR, without the deprecations.

πŸ‡³πŸ‡±Netherlands Spokje

Thanks sherlock mstrelan, seems like it's indeed not needed.
RTBC for me.

πŸ‡³πŸ‡±Netherlands Spokje

Thanks @benjifisher for the (very clear) rewrite of the IS and @berdir for explaining why the current solution is what it is, and might/could/should be the way forward.

Putting this up for review once more, so this major issue won't get stalled/lost-in-limbo.

πŸ‡³πŸ‡±Netherlands Spokje

I think you've beaten Moriarty @mstrelan!

Since this adds a PHPCS-rule and might break contrib/external-CI in some places, I think we need a CR for this.
Besides that, I'm all for RTBC.

πŸ‡³πŸ‡±Netherlands Spokje

De-confusing comment confirmed, RTBC for me.

πŸ‡³πŸ‡±Netherlands Spokje

Seeing that this was for rdf, would this be the place it was set: https://git.drupalcode.org/project/rdf/-/blob/2.x/rdf.module?ref_type=he...

If it is, it was removed from core with the move of rdf to contrib.

πŸ‡³πŸ‡±Netherlands Spokje

Nice, this even detected the sole usage in Olivero, so I'm more than happy to RTBC this.

I've decided not to create any follow-ups, since this shows we have a working solution for this case and I'm against Death-By-Admin, but if anyone wants to fill out templates and create a new issue, I'm all for it.

πŸ‡³πŸ‡±Netherlands Spokje

The deprecation process of theme-template-stuff is not very clear, (at least to me): https://www.drupal.org/about/core/policies/core-change-policies/drupal-d... β†’ .

Looks like the current deprecation message isn't added to the ['node']['variables'] return of node_theme(), but instead is overwriting it, leaving all node-theming logic without the actual node. Hence the gazillion test-failures.

If I look here, we can only deprecate the root level itself and not anything specific below it? https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

If I use that option for this issue, we're getting a deprecation warning _every_ time node_theme() is used.
We _could_ ignore that deprecation warning in core/.deprecation-ignore.txt, but maybe this would be the time to introduce deprecation at lower levels of theming functions return arrays?

πŸ‡³πŸ‡±Netherlands Spokje

- Updated deprecated/removed version numbers
- Added `@` to `trigger_error`, which, AFAICT, is still the default for `E_USER_DEPRECATED`.
- Added `E_USER_DEPRECATED` to `@trigger_error` in `\Drupal\user\Form\EntityPermissionsForm::access`

πŸ‡³πŸ‡±Netherlands Spokje

Spokje β†’ changed the visibility of the branch 11.0.x to hidden.

πŸ‡³πŸ‡±Netherlands Spokje

Spokje β†’ made their first commit to this issue’s fork.

πŸ‡³πŸ‡±Netherlands Spokje

Wonder if it's too late for 10.3-beta too?

The 10.x branch will stay on SF 6.4 AFAIK.

πŸ‡³πŸ‡±Netherlands Spokje

Since the parent has priority "Critical", bumping this issue to the prio as well.

(Look mam, I'm doing critical stuff!)

πŸ‡³πŸ‡±Netherlands Spokje

@catch: Ah, of course, this eludes me every once in a while. Thanks for explaining.

Moving to correct version.

πŸ‡³πŸ‡±Netherlands Spokje

Thanks @catch.

Since there's not yet a version-tag for 11.1.x in the dropdown (nor Git), I think the correct status for this issue would be postponed and we whack a [11.1.x] in the title to have some kind of visual queue?

πŸ‡³πŸ‡±Netherlands Spokje

Idea is nice, code looks fine, tests are green.

The only thing that I wonder about if there's still time to deprecate/remove in 10.3.0/11.0.0 since the BETAs of both are already out.
I _think_ we're too late and need to deprecate/remove in 10.3.1/12.0.0, but am not sure
I know I've seen documentation on this before somewhere, but my search-fu is failing me now.

Putting this on RTBC so core committers can decide on this.

πŸ‡³πŸ‡±Netherlands Spokje

Spokje β†’ changed the visibility of the branch 3406971-non-silenced-deprecation-message to hidden.

πŸ‡³πŸ‡±Netherlands Spokje
$ composer diff
| Prod Packages                   | Operation | Base         | Target     |
|---------------------------------|-----------|--------------|------------|
| symfony/console                 | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/dependency-injection    | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/error-handler           | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/event-dispatcher        | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/filesystem              | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/finder                  | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/http-foundation         | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/http-kernel             | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/mailer                  | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/mime                    | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/process                 | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/psr-http-message-bridge | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/routing                 | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/serializer              | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/validator               | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/var-dumper              | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/yaml                    | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |

| Dev Packages         | Operation | Base         | Target     |
|----------------------|-----------|--------------|------------|
| symfony/browser-kit  | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/css-selector | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/dom-crawler  | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |
| symfony/lock         | Upgraded  | v7.1.0-BETA1 | v7.1.0-RC1 |

πŸ‡³πŸ‡±Netherlands Spokje

a handful of quick fixes in MR!7547 cut it down by about 25%.

Great, but not sure this is part of this issue? Or even what an acceptable amount of added errors to a baseline would be?

Personally, (n=1, yadayada) this seems like follow-up issue material to me and might be derailing the original intent?
But what do I know? _shrug_

πŸ‡³πŸ‡±Netherlands Spokje

3.9.2 landed and made it all better.

πŸ‡³πŸ‡±Netherlands Spokje

To be fair, we can still:

- Bump twig/twig to 3.9.1 which fixes Exception: Warning: Undefined variable $blocks.
- Bump to that version in composer.json, since lower version won't pass with the yield changes.

Did that just now.

πŸ‡³πŸ‡±Netherlands Spokje

Ah, thanks

πŸ‡³πŸ‡±Netherlands Spokje

With 3.9.1 less errors, more Since twig/twig 3.9: Twig node "Foo" is not marked as ready for using "yield" instead of "echo"; please make it ready and then flag it with the #[YieldReady] attribute..

https://github.com/twigphp/Twig/issues/4008 Still messes with (at least) our Twig deprecation testing.

πŸ‡³πŸ‡±Netherlands Spokje

Not a big fan of lowering versions of dependencies, but seeing that:

- None of our other dependencies need it
- Tests are green
- PHPUnit 10 waits for no man...

I'm going to RTBC

πŸ‡³πŸ‡±Netherlands Spokje

Spokje β†’ created an issue.

πŸ‡³πŸ‡±Netherlands Spokje

Added two CRs.

πŸ‡³πŸ‡±Netherlands Spokje

Let's bump it to RTBC and see if the core committers think we still need FM approval and if so, if they can ping them :)

πŸ‡³πŸ‡±Netherlands Spokje

- Approach makes sense, seeing there is precedence.
- Code changes make sense (Personally I find the new logged warning a lot more clear than before).
- Tests are green.

The only thing from RTBC-ing this is the CR link, which needs, at least for me, mentioning the new required LoggerInterface $logger, in Roles::__contruct().

πŸ‡³πŸ‡±Netherlands Spokje

One argument against staggering would be that raising the PHPStan level would be disruptive to (almost) all open MRs for each bump, so bumping more then one level would make it less disruptive.

That might be the case when the baseline was in the NEON format, and IIRC was one (of many) reasons the Bump-to-L9 issue is stalling.
But as part of that issue, we switched the baseline over to PHP with the reasoning that Git would be much smarter about merging it.

Is bumping a PHPStan level (with each one bringing in loads of changes on the baseline file) still as disruptive to other MRs as we (or at least I) think, or is this a non-issue by now?

If we're in non-issue land on that, I'm all about staggering, if not, we might want to prevent all/a lot of open MRs grinding to a rebase-halt each time we stagger-bump and do it in one go?

πŸ‡³πŸ‡±Netherlands Spokje

Thanks @mstrelan, should have found that myself, but somehow didn't. (Makes mental note to check caffeine-percentage of new bought coffee-brand).

Seeing those checks and also the fact that if we want to do it with the least amount of disruptions to other MRs, it's probably now or when D12 arrives, I'm pulling the trigger and put the ball in core commiters court: RTBC for me.

πŸ‡³πŸ‡±Netherlands Spokje

Looks like when we bump to PHPStan L2 we get an initial addition of ~7800 suppressions.
Seeing the amount of active issues to tackle the L1 suppressions, I think it's safe to assume these won't go away quickly.

So the benefit would be preventing new L2 issues creeping in new/refactored code.

It's probably my lack of Google skills, but what are the extra checks in L2 compared to L1, what will be prevented from creeping in by us doing PHPStan L++?

πŸ‡³πŸ‡±Netherlands Spokje

Ah crap, of course, forgot that in my "rage" about the baseline formatting.

πŸ‡³πŸ‡±Netherlands Spokje

Note: Creating a new PHPStan-baseline exposed some formatting differences between the generated and committed-in-HEAD one.
Let's use this issue to reconcile these.

As a side note: If people are manually editing the baseline, let's make the GitLab job fail on these differences, so we don't need this kind of reconciliation.

πŸ‡³πŸ‡±Netherlands Spokje

Spokje β†’ changed the visibility of the branch 10.3.x to active.

πŸ‡³πŸ‡±Netherlands Spokje

Spokje β†’ changed the visibility of the branch 10.3.x to hidden.

πŸ‡³πŸ‡±Netherlands Spokje

Spokje β†’ changed the visibility of the branch 11.x to hidden.

πŸ‡³πŸ‡±Netherlands Spokje

"Interestingly" \Drupal\Tests\views\Functional\UserBatchActionTest passes locally and on Gitlab on PHP 8.1 (https://git.drupalcode.org/issue/drupal-3390360/-/jobs/1183273#L65) but fails on PHP 8.3.

Also I would have expected either no or a bunch of failures, not just one test that (on first glance) doesn't seem to do anything to wild.

πŸ‡³πŸ‡±Netherlands Spokje

Spokje β†’ made their first commit to this issue’s fork.

πŸ‡³πŸ‡±Netherlands Spokje

Explanation makes sense
Code changes make sense
Tests are green
-------------------------+
RTBC

πŸ‡³πŸ‡±Netherlands Spokje

Looks like the __sleep alias can be dropped, which would prevent future-us from trying to drop the whole Trait.

πŸ‡³πŸ‡±Netherlands Spokje

Spokje β†’ made their first commit to this issue’s fork.

πŸ‡³πŸ‡±Netherlands Spokje

Makes sense to me, and tests are green => RTBC

πŸ‡³πŸ‡±Netherlands Spokje

Thanks @mondrake, I'll take a 50% success rate any day...

RTBC for me now.

πŸ‡³πŸ‡±Netherlands Spokje

Like the approach, like the MR, but we've might have a few stragglers (at least, if I understand the scope correctly):

- \Drupal\Tests\Component\Plugin\Discovery\StaticDiscoveryDecoratorTest::testGetDefinition: https://git.drupalcode.org/project/drupal/blob/b73c68de45491739c0752d859... and https://git.drupalcode.org/project/drupal/blob/b73c68de45491739c0752d859...
- \Drupal\Tests\Core\Entity\Sql\SqlContentEntityStorageTest::testLoadMultiplePersistentCached: https://git.drupalcode.org/project/drupal/blob/654b1f2074ea90b75a8750f2b...
- \Drupal\Tests\Core\Entity\Sql\SqlContentEntityStorageTest::testLoadMultipleNoPersistentCache: https://git.drupalcode.org/project/drupal/blob/654b1f2074ea90b75a8750f2b...
- \Drupal\Tests\Core\Entity\Sql\SqlContentEntityStorageTest::testLoadMultiplePersistentCacheMiss: https://git.drupalcode.org/project/drupal/blob/654b1f2074ea90b75a8750f2b...
- \Drupal\Tests\Core\Entity\TypedData\EntityAdapterUnitTest::setUp: https://git.drupalcode.org/project/drupal/blob/9add7f71ff26864477f80e349...

πŸ‡³πŸ‡±Netherlands Spokje

Explanation and code changes make sense. Overall a nice cleanup!

πŸ‡³πŸ‡±Netherlands Spokje
Let's clear out everything in the current baseline, then bump it to level 2 or 3

This is the current plan anyway,

To be fair, that plan is not going fast, or to be more precise, seems to have been grinded to a halt.

There's so much BC in play with fixing even the low hanging issues, that even determining what arethe low hanging fruits is difficult and leads to much discussion.

I myself have (almost) given up on working on PHPStan base-level issues, since they really suck the life-force out of my contributing spirit.

Having said that, although I can see some advantages in upping to level 9 and at the very least be warned when new PHPStan issues creep in, the sheer amount that would have to be committed to the baseline because of the BC-promises made, would be nullifying those advantages IMHO.

So I personally don't see advantages upping to any level above the current level 1, until we have either more persons willing to contribute on fixing the current issues with the current PHPStan level and/or have a long hard look at BC policies we currently have and if they're perhaps holding us back to much.

But of course, n=1, personal opinion and all that.

πŸ‡³πŸ‡±Netherlands Spokje

MR actually extends the existing test-coverage and replaces the (as said) only occurrence of getObjectForTrait().

πŸ‡³πŸ‡±Netherlands Spokje

This MR replaces getMockForTrait() with adding a test class which uses the Trait.
AFAICT this is indeed the recommended way to do this.

After applying the MR there are no references left regarding getMockForTrait(), tests are green => RTBC.

Production build 0.69.0 2024