Closed (cannot reproduce)
Project:
Entityblock
Version:
8.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
14 Nov 2016 at 04:34 UTC
Updated:
27 Oct 2021 at 23:20 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
johnpitcairn commentedComment #3
johnpitcairn commentedDowngrading to major - import does actually succeed I think.
Comment #4
johnpitcairn commentedThe config manager is trying to find missing dependencies and the dependency string it receives for the entityblock field isn't what it expects. Line 472 in ConfigManager.php is:
// Format of the dependency is entity_type:bundle:uuid.list($entity_type, $bundle, $uuid) = explode(':', $content_dependency, 3);But the content dependency string it receives is
field.storage.node.field_block,list()complains about undefined offsets, then EntutyTypeManager throws an exception.I'm not familiar enough with Drupal 8 configuration to diagnose further right now. Anyone?
Comment #5
johnpitcairn commentedBack to critical - the config import is not successful. You can't use entityblock if anything depends on configuration imports.
Comment #6
t_stallmann commentedI'm working on fixing this locally and the bug appears to be due to the fact that the entityblock module exports field dependencies to the
content:section of the dependency section of config files, and not to theconfig:section. I'm working on a patch, but in the meantime it's possible to fix the immediate import issue by manually editing the yml files for any entityblock blocks and moving thefield.storage.node.field_****key to a newconfig:subsection ofdependencies:.Comment #7
t_stallmann commentedPatch attached.
Comment #8
johnpitcairn commentedThanks. I had already ditched entityblock and switched to a custom block with a content reference field, but entityblock is a cleaner solution. The patch fixes the issue, but from what I've seen elsewhere the config keys should use the getter function, not be hard coded. Tweaked patch to follow.
Comment #9
johnpitcairn commentedThis patch uses the entity and field getter functions for the dependency keys.
Comment #10
johnpitcairn commentedOK, that's no good. There isn't a getter for the content dependency key. So we should hard code that, and just use the getter for the config key.
Comment #11
johnpitcairn commentedAnd patch.
Comment #13
Johnny vd Laar commentedThanks for the patch. I've changed the array syntax because I want to move to short array syntax. Fix has been committed.
Comment #15
jcollyer commentedI hate commenting on closed tickets, but this issue seems to have cropped up again. We're running alpha4, but during config-import I'm getting the same entity type error:
Comment #16
Johnny vd Laar commentedHmm perhaps the order in which things are reverted causes problems. So perhaps it first tries to create the block plugin type and then it creates the field or something...
I'll investigate, but I'm not really working on any websites with this module enabled so might take some time.
Comment #17
Johnny vd Laar commentedComment #18
shelaneI have seen this issue come up with "x" plugin and it's actually an issue in core and not with the module. The fix is to run a cache rebuild prior to the config import when you see this.