Problem/Motivation
Traits can't use the $module property, to quote the manual: "if a trait defines a property then a class can not define a property with the same name unless it is compatible (same visibility and type, readonly modifier, and initial value), otherwise a fatal error is issued", emphasis mine. And you can't do anything else because you can't extend the private getModulesToEnable method either.
This is used in pantheon content publisher tests. It uses two kinds of tests, each with own setup but one test requires both setups. Since PHP does not support multiple inheritance the only way to solve is to move one setup into a trait. And so that trait needs to be able to require a module.
Steps to reproduce
Try to define a trait that requires a module.
Proposed resolution
Make it protected, it's just a test class. The trait then can override getModulesToEnable to call parent::getModulesToEnable and adds it own. If two traits do this then an appropriate alias can be provided for these methods.
Remaining tasks
Review
User interface changes
N/A
Introduced terminology
N/A
API changes
getModulesToEnable is now protected
Data model changes
N/A
Release notes snippet
N/A
Issue fork drupal-3517808
Show commands
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:
- 3517808-allow-traits-to
changes, plain diff MR !11757
Comments
Comment #3
nicxvan commentedComment #4
nicxvan commentedComment #5
smustgrave commentedIs there an example test that needs that could be converted.
Comment #6
nicxvan commentedThis might be better defined as a feature request. You can't do this with a trait so there is nothing to convert.
Comment #7
smustgrave commentedLet’s see what committers think!
Comment #8
ghost of drupal pastComment #9
alexpottI'm not sure about this one. Drupal is really special in how we futz with the autoloader to make test traits autoloadable (and in fact all the tests). This is not normal behaviour.
The issue summary needs to be updated with a concrete use case of why this is or might be a good idea. Atm the issue summary is just about why you can't do it not why to do it.
Comment #10
nicxvan commentedI updated the Issue summary with some more detail.
Comment #11
ghost of drupal pastComment #12
smustgrave commentedSorry to be late to the conversation, but should traits declare dependencies? I always thought of traits as helper functions or common stuff. But if I have multiple tests that need specific setup then I make a test base file.
Comment #13
smustgrave commentedTo not stall it and summary appears to be updated going to mark it and see what committers think.
Comment #15
longwaveI don't have a problem with this, we are usually wary of using private anyway in Drupal because we are quite permissive about what we allow downstream users to do, and this seems to be no exception - especially as this is tests only, if someone really wants to override this behaviour in a test, what are we to stop them?
As a feature this is only eligible for minor releases, but I also see no harm in backporting this to 10.6.x.
Committed and pushed bb6ce4e4d46 to 11.x and 27ec7850b62 to 10.6.x. Thanks!