In-place editing of custom blocks broken *again* (because attributes and contextual links of custom blocks are lost)

+++ b/core/modules/quickedit/quickedit.module
@@ -165,9 +165,9 @@ function quickedit_preprocess_field(&$variables) {
-function quickedit_entity_view_alter(&$build, EntityInterface $entity, EntityViewDisplayInterface $display) {
+function quickedit_entity_build_defaults_alter(&$build, EntityInterface $entity) {

This is less than ideal, because this hook is invoked always, even on render cache hits, because it is was IIRC added specifically to allow modules to alter the cache ID of render cached entities.

Finally, this hook is not invoked for all entities, only for those that extend the default EntityViewBuilder.

The key problem is that blocks use the #pre_render pattern, but entities (and hence the block_content) entity does too. But BlockViewBuilder::buildBlock() needs to "lift" (move) the #attributes and #contextual_links properties from the block contents (in this case of the block_content entity's render array) to the block itself. This works fine for all blocks except for the block_content blocks, because they are entities that themselves are rendered lazily (using the #pre_render pattern)… just because they are entities.
The solution is therefore simple: don't apply the #pre_render pattern to block_content entities. The #pre_render pattern is applied to do less work in case of a render cache hit, but block_content entities are always rendered as blocks and blocks already have their own render caching.

This patch therefore applies the #pre_render callback immediately, and disables render caching of block_content entities.

Test coverage is still needed.

#4: Ok, that's true, but that's an insane edge case. The 99% use case is that these content_block entities will be rendered in blocks, and in that case, render caching is completely unnecessary. Therefore I think this change is fine; it doesn't break the Views use case that you mention.

Any chance you want to write test coverage? :)

A duplicate of this was reported at #2350741: Quick Edit not displayed in contextual links after Minimal profile install.

We should have a comment as to why this is acceptable.

Done.

Tests added.

Kyna: that's probably a bug in your custom theme. But since that's a separate problem, please create a new issue. And like Alex says, you shouldn't post user login details publicly. That's why I asked you to send them to me via my d.o contact form! :)

Another duplicate of this was reported at #2375849: Quick Edit missing .