block_content block derivatives do not scale to thousands of block_content entities

The problem if course is how to get there from the current core implementation, because I honestly have no idea how to achieve that. The BC promise of drupal core makes such a change challenging. Best I can think of would be a setting that allows to switch between exposing them as derivatives vs. such an autocomplete field, then the deriative class would just not do anything if that setting is set and instead there might be a different, conditionally enabled block plugin that would work like that.

Could we add a new always-on block plugin that allows this?

Then we could add a config setting to disable the current derivatives. And then (possibly over a couple of major releases) deprecate all the old derivatives altogether. Seems like it would be hard to do a force-update from one blog plugin to another since classes etc. would change, but if we provide the new method and a killswitch, we can get rid of the old way over time. For example switch the config setting to off for new sites.

That sounds like an option, the option to disable is for now more for those that have the problem with many blocks and could also do the work to switch their current block placements. Forcing everyone over is then for (much) later, if we care enough about it. an intermediate step could be to disable that by default on new sites.

We might need to think about the process for creating new blocks, but it's also a chance for a less confusing process than we have now, the block selection could be similar to the media library where you can select an existing one or create one in a modal.

We might need to think about the process for creating new blocks, but it's also a chance for a less confusing process than we have now, the block selection could be similar to the media library where you can select an existing one or create one in a modal.

That's exactly what we've been discussing in our draft roadmap for block content, so we're on the same page

Drupal core cache all reusable block in cache_entity, I think blocks should be cached on render instead of cache blocks on first run after cache rebuild, a workaround is to make blocks non-reusable

update block_content_field_data set reusable = 0;

@abu-zakham, making the blocks non-reusable will hide them from the block content overview page and they will not be available to add on Block layout page and in the Layout builder.

@yivanov, yes you are right

Adding this to our 10.2 target. Since there’s a 10.1 patch is there a different approach we want to take?

Could use some feedback as I'm having issue with the ajax callback and when to load the blockContent.

Another issue I found with using block_content:uuid in the settings is it messes with the redirects.

Another issue I found with using block_content:uuid in the settings is it messes with the redirects.

Could you elaborate more?

> Sorry it's not clicking for me. How would a new plugin and leaving this one solve the issue?

It won't. But it's impossible to just completely change the existing plugin and keep BC. See #54/55. We add a feature flag, new sites will use the new approach, existing sites will keep using the old plugin, they get a warning and need to convert all their stuff (which likely is going to be painful if they use layout builder). Maybe even with the feature flag, new placements will by default use the new approach, that we have to figure out.

But that can came later, first we need to have a working implementation using the new plugin.

As for the redirect, instead of preselecting block_content:UUID, you need to select block_content_reference or whatever we call it and have an additional reference parameter that you pass along that you then need to read again in config. So you need to read the current block in that order:

1. form state
2. query parameter
3. configuration

(2. and 3 should technically never be set at the same time, so it shouldn't really matter).

Exploring another option here 📌 \Drupal\block_content\Plugin\Derivative\BlockContent::getDerivativeDefinitions could use an aggregate query instead of loadMultiple Active