Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
It is recommended to use dependency injection instead of calls to \Drupal::
in OO-code.
This project fails to do so. While the current code works, it is the recommended way to do things.
Proposed resolution
Identify the code that need to be replaced and fix them.
Comment | File | Size | Author |
---|---|---|---|
#4 | content_access-use_dependency_injection-3170415-4.patch | 1.22 KB | gisle |
|
Comments
Comment #2
Gnanagowthaman sankar CreditAttribution: Gnanagowthaman sankar as a volunteer and at UniMity Solutions Pvt Limited commentedHi,
I had attached the patch please review and let me know for any changes.
Thanks & regards,
Gnanagowthaman Sankar
Comment #4
gislePatch failed testing. To me, it looks like the patch in #2 was made against a very outdated version of the project.
Made a new patch aginst HEAD.
Comment #6
gisleComment #8
TR CreditAttribution: TR commentedThis commit (41767c3) needs to be reverted.
Everything about this commit is wrong. It just broke things, it didn't fix anything. And specifically it didn't *inject* anything - $entityTypeManager is defined but it is not set anywhere, so it is always NULL. That can never work. And $configFactory is never even defined and also never set. Again, this will always be NULL.
Blindly following recommendations for dependency injection without understanding how to actually inject dependencies and without understanding how traits are used for code reuse is sheer folly. All this did was break the code.
Comment #9
gisleI'll take your word for it. Any additional advice you can offer shall be appreciated.
Comment #10
TR CreditAttribution: TR commentedI opened #3226616: Revert commit from issue #3170415 because I didn't have permission to reopen this current issue and I didn't know if anyone would see my comment on this closed issue. We don't need both open.
My advice is to do a
git revert 41767c3
, which will commit the inverse of 41767c3. The result will be like the above patch never happened. That is what we want, because everything in the patch is wrong.There are two uses of \Drupal:: in the trait that this will restore, but because that trait needs to be refactored and eliminated (these really should be methods on the plugin base class, and NOT be in a trait), those two uses can be handled in the refactoring issue as appropriate.
There's a lot of work needed to get the Rules integration working - it was never really ported from D7 properly. This was just the first thing I noticed immediately when looking at the code for the trait and trying to figure out what it was supposed to do. I will be opening a separate meta issue for all the other Rules-related things I'm finding.
Comment #12
gisleIt is now rolled back to commit fcd3522.
Revert "Issue #3170415 by Gnanagowthaman sankar, gisle: Use dependency injection"
This reverts commit 41767c3c6ea47a7545f9e1e7e8faddf0ec760c65.
Please review that this worked out OK.
I'm going to reapply those subsequent commits that was removed by this reversal, i.e.:
Comment #14
TR CreditAttribution: TR commentedIt looks like you used
git reset
or something other thangit revert
. Withgit revert
, it just should have committed the inverse patch, so no other commits should be affected and you shouldn't have to re-commit anything else.But I think the end result of what you did is correct. I will check.
Comment #15
gisleNo further comments. Closing as outdated.