Content fields disappear from Block layout when Layout Builder is enabled

That's the fault of layout_builder_plugin_filter_block__block_ui_alter(), added in #2968139: Layout Builder field blocks show up on Block UI when they shouldn't.

Not sure what to do about it, but that's why it is happening.

Actually, I'm not sure why that's happening. Because the code I referenced has this check:

$definition['provider'] === 'layout_builder'

Which should exclude any CTools-provided blocks...

We are seeing this error now too. Is there a patch or fix of any kind for this?

Is this still occurring? And only with CTools blocks?

Please write steps to reproduce if so.

I think I just ran into this. I have a taxonomy entity_reference field on a content type and am not seeing it in the list of content blocks I can add to the default layout. This site was built several months ago so not sure when this field was added, but it likely was added after layout builder was already enabled. This is a D9.0 site.

Going to dig into this a bit to see if I can determine the problem, but under time pressure so also looking for the fastest way to work around it. I cannot just disable layout builder because of existing dependencies.

I noticed that in the config YML file for the entity_view_display for the view mode using layout builder, the missing field (field_topic) was down in the "hidden" section at the bottom. It's the only field in that section and probably left over from before layout builder was enabled for this view mode. Disabling layout builder for this view mode and moving the field into the visible section and then re-enabling layout builder doesn't seem to help. Even editing the YML file manually and importing config doesn't help. Feels like this list of allowed field blocks is cached somewhere else.

If I install the layout_builder_restrictions module, I also do not see this field block in the list of allowed blocks that I can whitelist or blacklist. So still not sure what is different about this field.

Also, I don't think this is a CTools block, I think it is just a field_block as defined for layout_builder.

Apparently this field on this content type used to be called something else. Originally there was a shared field_topic and a specific field_blog_topic (on the Blog content type). There was an update hook to migrate field_blog_topic into field_topic and use that shared field on the Blog instead. That process has somehow prevented the field_topic from being available as a field_block for the Blog content type. It *IS* available as a block on other content types.

Doing a DB dump and grepping the SQL file shows no reference to the old field_blog_topic. So it's not still set in some cache table. However, whatever process was used to put the field_topic into the Blog content type must not have set some other table that field_block is looking at. Going to debug into the field_block listing now to track this down further.

OK, confirmed this is a site-specific issue, not a layout_builder issue (at least in this specific case). Debugging the plugin discovery, when it gets to the `getDerivativeDefinitions` within `FieldBlockDeriver.php` in layout builder, it checks the bundles for each field. For some reason on this site the "blog" bundle is not listed in the field_info array for the field_topic.

Still have no idea how this happened since I can edit/create blogs and use the field_topic just fine and all the rest of the site seems to work fine with this field on blog. I'll need to track down where the field_info is coming from in core.

For any others running into this, my site specific problem was that the `key_value` table has a cached `entity.definitions.bundle_field_map` collection for `node` that contains the list of allowed bundles per field. This is "state" data, so clearing cache doesn't alter it. Somehow when this field was renamed programatically, the key_value table didn't get updated. Saving the field on the node doesn't fix this. I had to write an update hook to manually patch the data in this table. This is probably a core bug somewhere, but I've seen plenty of other abuses of the key_value table being used as a permanent cache like this.

Setting this back to active as I think we found a crazy bug @mpotter. What you described in #16 quite exactly seems to match what also happens in other cases like for example if paragraphs module has been uninstalled!

And the error only appears when layout_builder is enabled. We hadn't had layout_builder in use for example, but tried paragraphs weeks before (then uninstalled paragraps). When activating layout_paragraphs, the

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "paragraph" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition()

was thrown!

Reason were (like you described in #16), orphaned "paragraphs" entries in the key_value table, which layout_builder seems to use in any way...

For details see:
#3165612: The "paragraph" entity type does not exist error after uninstallation due to left key_value entries
#3169812: Entity type does not exist when trying to use Layout Builder

So I guess these might be two separate issues like

1. "Paragraphs uninstall (and perhaps other entity modules) leave orphaned entity entries in key_value table"
2. "Layout Builder loads non-existing entity types from key_value"

PLUS what you initially described in this issue (different outcome)

But core maintainers should have a look, I'm not good enough at this topic.