CustomBlock has
public function bundle() {
return $this->type->value;
}
This relies on EntityNG magic whizbang.
Depending on where in the callstack this gets called (#1969728: Implement Field API "field types" as TypedData Plugins needs to call $entity->bundle() while the FieldItem object for 'block_body' is being created, during entity_create()), it seems everything might not be properly initialized, and the above returns NULL.
CustomBlock extends EntityNG, and EntityNG just returns $this->bundle, which just works.
Not sure why CustomBlock tries to do differently, but it doesn't seem needed :-)
Same thing for id().
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | remove-block-bundle-n-id.patch | 873 bytes | larowlan |
| #7 | remove-block-bundle.patch | 730 bytes | larowlan |
Comments
Comment #1
yched commentedOK, after some more digging, more precise title, and updated the OP.
Comment #1.0
yched commentedformat
Comment #2
yched commentedComment #3
yched commentedSo my first reaction would be to just remove CustomBlock::id() and CustomBlock::bundle(), and let the implementations from EntityNG apply.
But then I see that Node:id() returns $this->get('nid')->value, and Node::bundle() doesn't exist, just lets EntityNG::bundle() return $this->bundle.
So, WTF :-)
Seems largely inconsistent :-/
Neither $this->type->value nor $this->get('type')->value work when the bundle() method is called early in the lifecycle of the $entity (in my case, it's in the __construct() of the FieldItem for the 'block_body' field).
Comment #4
yched commentedActually, it seems that CustomBlock is the only class to override EntityNG::bundle() right now.
Comment #5
yched commentedComment #6
larowlanComment #7
larowlanLets see what the bot says
Comment #8
larowlangreen
Comment #9
yched commentedbundle() at least should be fine.
The situation about id() is still confusing, but I guess we can at least commit this.
FWIW, relying on entityNG getters (magic or not) to access critical properties like id or revision id seems... worrying.
Comment #10
larowlandrops the id function too
Comment #11
larowlanback to previous status unless bot disagrees
Comment #12
larowlanI think this qualifies for the Quick Fix tag
Comment #13
yched commentedWell, that's where I'm confused. If EntityNG::id() is good enough, then why do Node, Comment (didn't check the other ones) bother adding their own complex override ?
Comment #14
andypost@yched Because node and comment have 'nid' (cid) as keys that's not
idComment #15
yched commented@andypost: of course, but that's not the point :-p
- If EntityNG::id() just does $this->id, why can't Node::id() do $this->nid ?
- node's 'bundle key' is 'type', not 'bundle'. Yet $node->bundle() is EntityNG:bundle(), which is just $this->bundle - and it works.
So why would it work for the "bundle key" and not for the "id key" ?
Comment #16
catchCommitted/pushed to 8.x, thanks!
Comment #17.0
(not verified) commentedMore accurate description of the bug