Closed (fixed)
Project:
Drupal core
Version:
10.2.x-dev
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
2 Aug 2022 at 00:36 UTC
Updated:
19 Jun 2025 at 00:26 UTC
Jump to comment: Most recent
@trigger_error('The ' . get_class($test) . '::$modules property must be declared protected. See https://www.drupal.org/node/2909426', E_USER_DEPRECATED);
This could be enforced by phpcs or rector, the other option is throwing an exception here but there's no version information in the deprecation message so that'd probably have to change to $version_it_was_added to be enforced in 11.0.0
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
catchComment #4
gábor hojtsy@mglaman worked on a rector rule for this recently at https://github.com/palantirnet/drupal-rector/pull/210 and phpstan rule at https://github.com/mglaman/phpstan-drupal/issues/463
The deprecation still needs updating to have the expected version format and deprecate in Drupal 11.
Comment #6
gábor hojtsyProposed an update based on the suggestion in the issue summary. The original CR at https://www.drupal.org/node/2909426 says this is going to be required from Drupal 9.0.0 so that needs updating if/when this lands.
Comment #7
quietone commentedI searched for change records and found the following.
#2833984: $modules property on BrowserTestBase and KernelTestBase is protected : Announced the change to protected in 8.2.x.
#2909426: $modules is now a protected property in tests : States "Starting with Drupal 9.0.0 this property should now always be protected. In 9.1.0-alpha1 and above, making the property public will cause a deprecation to be thrown."
So, yes the new deprecation message is correct.
Comment #8
mondrakeIMHO the point of this issue should be to remove completely the deprecation message and the implementation of the check in DrupalListener, not to change the string of the error.
However, there's no phpstan-drupal implementation yet (and that's the one that would be relevant here for core, since the PHPStan check is run at every test, not the rector one), so for me the actual status should be postponed on upstream.
Comment #9
xjmI think I agree with #8. Thanks!
Comment #10
xjmTagging "needs followup" for filing an issue against phpstan-drupal (even though it's actually a blocker rather than a followup).
Comment #13
mondrakeIt's done upstream https://github.com/mglaman/phpstan-drupal/issues/463, we need a point relaease to pin to and then we can get rid of the check.
Comment #14
mondrakeComment #15
mondrakeComment #16
mondrakemglaman/phpstan-drupal just released 1.2.1. Once that's updated in core, this issue will be feasible.
Comment #17
quietone commentedAdded #3399419: Update mglaman/phpstan-drupal to 1.21 for 3301205
Comment #18
quietone commented#3399419: Update mglaman/phpstan-drupal to 1.21 for 3301205 was committed. This is no longer postponed.
Comment #19
quietone commentedComment #22
mondrakeMR 5310 is OK. It bumps the minimum phpstan-drupal release to the one that performs the check, hence the hash in composer.lock needs to change. Tests for the feature removed from the listener and added to phpstan-drupal are performed upsteram, so this is just a net removal.
Thanks
Comment #23
spokjeDamn @mondrake, that's very quick and _exactly_ the reasoning I was about to put into the IS! :)
Looking at
\Drupal\Tests\Listeners\DrupalListenera bit closer, I feel we can replace (and then deprecate\Drupal\Tests\Listeners\DrupalComponentTestListenerTrait) with another phpstan-drupal rule. I feel core is doing work in that trait that is now coverable by PHPStan.After that is done, I think
DrupalListeneris basically an "empty" wrapper around\Symfony\Bridge\PhpUnit\SymfonyTestsListenerand might be up for removal?But the latter is me treading into waters that are above my pay grade.
I'll open up an issue for
DrupalComponentTestListenerTraitin here (postponed) and one in themglaman/phpstan-drupalqueue shortly.Comment #24
spokjeComment #25
mondrake#23 cool.
The follow-up is great.
General point with listeners: they are deprecated and simply no longer there in PHPUnit 10.
So my approach is: any steps taken to thoroughly remove them is good; any step in the direction of refactoring them but keep them is a waste of time.
Comment #26
spokjeThanks for the confirmation @mondrake, I try to keep up with all the PHPUnit/Symfony-bridge work you're doing, but it's hard to keep up with your good work.
Comment #27
mondrakeThanks... honestly I'm not even sure where Symfony's phpunit-bridge is going, see e.g. https://github.com/sebastianbergmann/phpunit/issues/5532.
So, ATM we're pretty much sitting on the river's bank...
Comment #30
longwave+1 to removing the listeners as it is a step towards PHPUnit 10 even if that seems to be getting no closer every time I look at it.
Committed and pushed to 11.x and 10.2.x, thanks!