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.
Part of meta-issue #2225347: [META] Replace calls to ENTITY_TYPE_load() and ENTITY_TYPE_load_multiple() with static method calls
See the detailed explanations and examples there.
Comment | File | Size | Author |
---|---|---|---|
#55 | 2322639-55.patch | 28 KB | hussainweb |
#55 | interdiff.txt | 305 bytes | hussainweb |
#54 | interdiff.txt | 1.75 KB | hussainweb |
#46 | 2322639-46.patch | 27.92 KB | hussainweb |
#46 | interdiff-43-46.txt | 4.17 KB | hussainweb |
Comments
Comment #1
Temoor CreditAttribution: Temoor commentedComment #2
Temoor CreditAttribution: Temoor commentedReplaced #machine_name callback with NodeType::load in NodeTypeForm.
Comment #3
MKorostoff CreditAttribution: MKorostoff commentedTo test this, I grepped the codebase for the following patterns, before and after applying the patch.
1.
node_type_load(
Before patch: 6 instances
After patch: 2 instances (just the function definition and its corresponding doc block)
Status: Resolved
2.
node_type_get_types(
Before: patch 10 instances
After patch: 10 instances
Action taken: I have replaced these instances with
\Drupal\node\Entity\NodeType::loadMultiple();
with the exception of two places:- /core/scripts/generate-d7-content.sh (used for D7 sites, not a candidate for ungrading)
- node.module (the original function definition)
3.
entity_load('node_type
Before patch: 31 instances
After patch: 0 instance
Status: Resolved
4.
entity_load_multiple('node_type
Before patch: 1 instance
After patch: 1 instance
Action Taken: I have replaced this with
\Drupal::entityManager()->getStorage('node_type')->loadMultiple()
Updated patch and interdiff attached.
Comment #6
omers CreditAttribution: omers commented@MKorostoff your patch applies cleanly at commit 093ea79.
I made a reroll and works fine for me :), i have some problems with the interdiff, if someone can give me a hand, I would appreciate it.
Comment #7
omers CreditAttribution: omers commentedComment #8
oenie CreditAttribution: oenie commentedI'm starting work on a reroll of the patch, because it doesn't apply anymore.
Comment #9
oenie CreditAttribution: oenie commentedRerolled
Comment #10
legolasboI will review this starting right now
Comment #11
legolasboThe patch in #9 doesn't apply cleanly because it contains irrelevant changes.
Reversed (or previously applied) patch detected!
Reversed (or previously applied) patch detected!
Reversed (or previously applied) patch detected!
Comment #12
oenie CreditAttribution: oenie commentedReroll of the patchn without the unneeded extra's.
I mistakenly compared with a branch that wasn't up to date.
Comment #13
oenie CreditAttribution: oenie commentedComment #15
legolasboThe patch applies cleanly now and looks good to me. Marking it RTBC expecting all tests to pass.
Comment #16
alexpottLooking good - there is some unrelated change that has crept into the patch and a couple of plugins that should have the node type storage injected rather than just using the static method.
Unrelated change
Unrelated change
Unrelated change
Should be injected
Should be injected
Comment #17
oenie CreditAttribution: oenie commentedHi alex, could you elaborate on that DI vs static method issue ?
I guess i'm just unclear about when DI is the way to go and when it isn't.
Should we always be using DI in a class context ?
If you could point me to some documentation, that would be good as well :)
All i found was https://www.drupal.org/node/2133171, but i guess i'm missing the 'best practices' side of it all ...
Comment #18
hussainwebI have rerolled the patch and then fixed for comments in #16. The interdiff is only for the fixes for comments and not the reroll.
I hope I got the DI part right.
Comment #20
hussainwebWow, that was a silly error. Attaching the interdiff and patch.
Comment #21
hussainwebI think that we can fix some of the method names to fit the naming convention. Does it make sense to do it here or a new issue?
Comment #22
oenie CreditAttribution: oenie commentedFrom other patches i have gathered that mixing in new changes into existing patches is generally not a good idea.
As for the patch (which i was planning to do today since i just figured out what to do ... seems you beat me to it :))
Your dependency injection looks like what i wanted to do too, just a small remark/question:
Shouldn't these be more specific ? It's actually creating a Type plugin object (by first calling the PluginBase construct method but then adding the storage to it)
It seems that throughout the Drupal code, the documentation is not very consistent on this subject.
Comment #23
hussainweb@oenie: I hope you don't mind. It was 3 days old and I just went for it.
You are right, it is generally not a good idea to mix various issues, but I am not sure if changing the method name had another issue, and if this is the only instance (it is almost like a private method) it doesn't follow the convention, we could consider just fixing it here. I would say it is important as this is Drupal core and even if this method is not extended, there are good chances that someone will use this as reference for writing their own modules and it wouldn't look good.
About the comment, you are right again. I just copied the constructor from another argument (Vid.php, I think). I will have to do some more looking around to see if there is a reason we mention the base object here.
Comment #24
oenie CreditAttribution: oenie commentedNot at all. I was just waiting for input from alexpott, but it turns out i was looking at the wrong class for the DI.
Things need to move on ! And i just finished another patch with DI, so i got around to understanding it there ...
I copied stuff too, and that's how things like this propagate. I was thinking however that, when you can write 'inheritdoc' (for the create method), it's actually doing the same thing. It's copying the docs from the parent and thus putting something like 'Creates a something something base class'.
Consistency is something to strive for, just no sure how important it is in this case.
Comment #25
hussainwebThat's true. I agree about the consistency. Very important.
If you are thinking about inheritdoc, we can't put it on the constructor because that particular constructor does not have the same parameters as the parent. There is an additional parameter (the one we injected) and we have to document that. As for create, the parameters are same and it's there. :)
Comment #26
oenie CreditAttribution: oenie commentedI was actually referring to the fact that by putting 'inheritdoc' above the create method, you are (as the name says it) inheriting the parent documentation.
Which would mean, if you generate the documentation, that for the derived class, there would a be a line that says something like 'Creating an object of type
', instead of 'Creating an object of type ', which is what i was trying to avoid in #22. Which would be kinda rendering our consistency ... well ... inconsistent :)
Comment #27
legolasboComment #28
daffie CreditAttribution: daffie commentedComment #31
pcambraRe-rolled. Also took into account #22
Comment #32
BerdirMoving this to the right component :)
Comment #33
chanderbhushan CreditAttribution: chanderbhushan commented#31 apply successfully
Comment #34
unstatu CreditAttribution: unstatu commentedThe patch does not apply. I am working on the reroll.
Comment #35
unstatu CreditAttribution: unstatu commentedRerolled.
Comment #36
unstatu CreditAttribution: unstatu commentedComment #37
mglamanEdit: .... I posted a reverse interdiff. Pardon.
BulkFormAccessTest.php cropped up with entity load.
Comment #40
LinL CreditAttribution: LinL commentedReroll following #2345833: Convert assetEqual to assertIdentical in migrate_drupal
Comment #41
LinL CreditAttribution: LinL commentedAnother reroll for #2357199: Consider CommentManagerInterface::addDefaultField() as deprecated and remove in favour of CommentTestTrait
Comment #42
mihai7221 CreditAttribution: mihai7221 commentedApplied patch in 41 against
cab6a8c22d11ef93637d7806cd62591ec1a2f66a
without problems, all good.Comment #43
LinL CreditAttribution: LinL commentedReroll for #2413759: Move D6 dumps to avoid collisions with D7 dumps
Comment #44
JeroenTStill one call to node_type_get_types in generate-d7-content.sh but I think we don't have to worry about this one?
Still an occurrence of node_type_load. Should be replaced with NodeType::load() ?
Rename this to $node_type_storage for clarity?
Rename this to $node_type_storage for clarity?
Why are we using \Drupal::entityManager()->getStorage('node_type')->loadMultiple() here and NodeType::load() earlier in this file?
Add use statement above and just use NodeType::loadMultiple() here.
Add use statement above and just use NodeType::loadMultiple() here.
Comment #45
pcambraAlso, a couple of nitpicks
This is not a Database service object
This is unused
Comment #46
hussainwebAddressing comments in #44 and #45. For #44.6 and #44.7, I was going to say it was okay as this is just a reference file and is probably a good idea to show the entire path (as only that section will come up in doc pages). But then I saw that there were other use statements and added accordingly.
Comment #47
JeroenTComment #48
kyuubi CreditAttribution: kyuubi commentedComment #49
kyuubi CreditAttribution: kyuubi commentedRerolled.
Comment #50
kyuubi CreditAttribution: kyuubi commentedRemoving Needs reroll tag.
Comment #51
benjy CreditAttribution: benjy commentedLets move this onto multiple lines.
Same for this.
Other than that, looking good.
Comment #52
hussainweb@benjy: Is this what you meant? (interdiff attached)
Comment #53
benjy CreditAttribution: benjy commentedNo i meant:
Comment #54
hussainwebGot it :)
Comment #55
hussainwebOops! Made a mistake in #54. The interdiff is still against it for continuity.
Comment #57
benjy CreditAttribution: benjy commentedThanks, this looks good to me.
Comment #59
hussainwebThis issue was committed (live at DrupalSouth, might I add). I think this should be fixed.
@webchick: You always thank people for contributing, but let me thank you for showing the entire process to everyone in the room. It was a great experience!