Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
node system
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
16 Aug 2013 at 18:14 UTC
Updated:
29 Jul 2014 at 22:47 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
bomoko commentedAssigning to myself
Comment #2
bomoko commentedI wanted to check, should I be searching for the phrase "EntityInterface $node" across the _entire_ code base? Including tests?
Further, I was wondering if there were any other discussion threads on DO that give the background to this, so I can understand the context of the task slightly better.
Comment #3
berdirBasically yes, but it might make sense to start somewhere, e.g. node.module. and first change those and check the test results.
The reason is that we want to have a specific type hint so that IDE's can autocomplete on the methods. We already had them, but had to change it due to do something that since has been changed again, the way translations are handled. See #1391694: Use type-hinting for entity-parameters for one related issue.
Comment #4
bomoko commentedOkay here is a first shot patch - as suggested by Berdir, I've taken a swing at node.module.
There are a few places where there are still EntityInterfaces in the node module (mainly where the tests were failing) - I'll trace through the code and work out if and whether these need to be changed to NodeInterface's too - any pointers in expunging these (whether they even need to be killed, for instance) would be greatly appreciated as I'm not yet comfortable with the core source (which is, of course, why I'm trying to do these novice tasks).
Comment #5
berdirThis is an $entity, not a node, so this one shouldn't be replaced.
This looks great already. This overlaps with a few big issues (page callback conversions, node BC removal, converting search to plugins) that will remove or touch some of those functions. Those are currently more important to get in, so this will require a re-roll after they are.
You might want to follow #1939994: Complete conversion of nodes to the new Entity Field API, #2003482: Convert hook_search_info to plugin system and the not yet committed, node related issues in #1971384: [META] Convert page callbacks to controllers and wait with a re-roll until they landed.
Comment #7
bomoko commentedokay cool - following them. Should I leave the ticket assigned to myself while we wait? (not quite sure about the protocol for this)
Comment #8
bomoko commentedunassigning from myself for now
Comment #9
xjm(Merging "node system" and "node.module" components for 8.x; disregard.)
Comment #10
berdirThe blockers are through now, would be nice to finish this :)
Comment #11
jdillick commentedComment #12
jdillick commentedComment #13
jdillick commentedRerolled this patch as part of core mentoring. This patch does not deal with books, comments, forum, history, menu, taxonomy, tracker, devel implicit use of EntityInterface for apparent Node objects.
I'll probably reroll once more to include these things after test run for this patch.
Point of discussion though. If there is not loss of functionality with the current use of the more generic interface, why would we want to enforce the more specific interface? Regardless of the intended use of the node api, why not allow other objects conforming to the EntityInterface to work with the node api?
I would think it is generally a good thing to air on the side of using the least specific interface necessary to enforce the method calls used in the implementation. In the interest of not bike-shedding on this, I'm going to assume there is a good reason to proceed that isn't obvious to me.
John
Comment #14
berdirThanks! (remember to set issues to needs review when you upload a patch)
node hooks work with node entities. Passing anything else to them is not valid. So the type hint should be on NodeInterface. Otherwise, modules would have to add an if ($node instanceof NodeInterface) to their code to be able to rely on methods provided by that interface. There are separate hook_entity_* hooks that are invoked for all entity types, the point of hook_node_* (hook_$ENTITY_TYPE_) is that they only receive entities of a specific type.
Comment #16
jdillick commentedComment #17
jdillick commentedComment #18
jdillick commentedComment #19
berdirComment #21
berdirYou can't change it here, becauseEntityInterface is enforced by the parent class.
Same here, everywhere where it says "@ineheritdoc" means that it's enforced by a parent class or interface to be EntityInterface.
Or an outdated Overrides/Implements docblock in a class method.
Comment #22
jdillick commentedOk, thanks... I learned something, was under mistaken idea that you could change the fingerprint if you were overriding a class. I knew you couldn't override the fingerprint if implementing an interface, but I didn't know it enforced the interface in the parent class too.
Here I've rerolled that patch to remove those attempts.
Comment #23
jdillick commentedComment #24
jdillick commentedDo we want to fix those old docblocks, or would that be better for another ticket?
Comment #25
yesct commented@jdillick to trigger the testbot, instead of a review tag. it's under the field "Status". No worries, you will get the hang of it. :)
taking off the Needs reroll tag since this new patch does apply ok to the current 8.x head.
Unless someone else has a good reason, I would suggest only changing just the docs (@param, ...) that you *have* to to keep the code accurate, and open another issue to do a clean up of old docs. If you open another issue, please link it to this one. :)
Thanks! And ask any questions you have. :)
oh, adding tag: Needs issue summary update. This issue doesn't have a summary. :) Here are instructions: https://drupal.org/contributor-tasks/write-issue-summary (I hightly recommend installing dreditor in your browser, it has a nice issue summary button to insert the issue summary template)
ps. In case you are curious, or want to provide a new contributor opinion, #2013222: Add "Issue tasks" to project issues and correlate tasks with handbook documentation is where we are discussing a new field for "needs" tasks.
Comment #27
xanoRe-rolling, plus reverting some incorrect changes to node type code.
Comment #29
xanoComment #30
berdirFinding weird things in the documentation but that's not the problem of this issue. Thanks, looks good!
This isn't true anymore I think, but let's not touch that there.
Didn't we kill that stuff? :) Again, not our problem here.
Comment #31
WarrenK commentedComment #32
alexpottNeeds a reroll
Comment #33
internetdevels commentedre-roll
Comment #34
internetdevels commentedchanged to "need review"
Comment #35
berdirThis doesn't exist.
Also not 100% if we should change this, if this would be a default method on the entity class, we wouldn't be allowed to do so.
Otherwise the re-roll looks fine.
Comment #36
xanoComment #37
andypostRelated issue #2030191: Clean-up api examples of node module just about to clean-up
node.api.phpComment #38
berdirThanks.
Comment #39
alexpottdrupal_2067345_36.patch no longer applies.
Comment #40
xanoRe-roll because of NodeAccessController.
Comment #42
xanoComment #43
andypostback to rtbc
Comment #44
webchickYayyyy this patch makes me so happyyyyyy! :D
It touches a bunch of stuff though, in sensitive areas where we have a lot of criticals/majors at the moment.
I'm going to tentatively commit this, but if it breaks something more important, we'll need to roll this back and schedule it just after the next alpha instead.
Committed and pushed to 8.x. Thanks!