When importing config (any config), entityblock fields throw an error:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "field.storage.node.field_xxx" entity type does not exist. in (...) /lib/Drupal/Core/Entity/EntityTypeManager.php:133

The block plugin derivative code should not hard code "content" as the config dependency key?

Comments

John Pitcairn created an issue. See original summary.

johnpitcairn’s picture

Issue summary: View changes
johnpitcairn’s picture

Priority: Critical » Major

Downgrading to major - import does actually succeed I think.

johnpitcairn’s picture

The 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?

johnpitcairn’s picture

Priority: Major » Critical

Back to critical - the config import is not successful. You can't use entityblock if anything depends on configuration imports.

t_stallmann’s picture

I'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 the config: 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 the field.storage.node.field_**** key to a new config: subsection of dependencies:.

t_stallmann’s picture

Patch attached.

johnpitcairn’s picture

Thanks. 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.

johnpitcairn’s picture

Status: Active » Needs review
StatusFileSize
new928 bytes

This patch uses the entity and field getter functions for the dependency keys.

johnpitcairn’s picture

Status: Needs review » Needs work

OK, 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.

johnpitcairn’s picture

Status: Needs work » Needs review
StatusFileSize
new750 bytes

And patch.

Johnny vd Laar’s picture

Status: Needs review » Fixed

Thanks for the patch. I've changed the array syntax because I want to move to short array syntax. Fix has been committed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

jcollyer’s picture

I 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:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "field.storage.node.field_block" entity type does not exist. in ~/core/lib/Drupal/Core/Entity/EntityTypeManager.php:133
Johnny vd Laar’s picture

Status: Closed (fixed) » Active

Hmm 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.

Johnny vd Laar’s picture

Status: Active » Postponed (maintainer needs more info)
shelane’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

I 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.