// Steps to reproduce
This error occurs when a block is saved, or the block layout page is saved.

// Expected behavior
I expected the block to save and the layout page to reload with the updated block.

// What happened
After saving a block (basic block) I got the error below. When I reload the page I see that the block was created and placed into the correct region, but the weight is always set to zero. Adjusting the weight is not possible through the UI because it errors and never updates the weight. I was able to change the block weight manually through config while testing. 

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">LogicException</em>: Getting the base fields is not supported for entity type Block. in <em class="placeholder">Drupal\Core\Entity\EntityFieldManager-&gt;buildBaseFieldDefinitions()</em> (line <em class="placeholder">209</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/EntityFieldManager.php</em>). <pre class="backtrace">Drupal\Core\Entity\EntityFieldManager-&gt;getBaseFieldDefinitions(&#039;block&#039;) (Line: 330)
Drupal\Core\Entity\EntityFieldManager-&gt;getFieldDefinitions(&#039;block&#039;, &#039;block&#039;) (Line: 223)
Drupal\entity_usage\EntityUsageTrackBase-&gt;getReferencingFields(Object, Array) (Line: 164)
Drupal\entity_usage\EntityUsageTrackBase-&gt;trackOnEntityUpdate(Object) (Line: 115)
Drupal\entity_usage\EntityUpdateManager-&gt;trackUpdateOnEdition(Object) (Line: 41)
entity_usage_entity_update(Object, &#039;block&#039;)
call_user_func_array(&#039;entity_usage_entity_update&#039;, Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler-&gt;invokeAll(&#039;entity_update&#039;, Array) (Line: 349)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;invokeHook(&#039;update&#039;, Object) (Line: 535)
Drupal\Core\Entity\EntityStorageBase-&gt;doPostSave(Object, 1) (Line: 460)
Drupal\Core\Entity\EntityStorageBase-&gt;save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase-&gt;save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;save() (Line: 381)
Drupal\block\BlockListBuilder-&gt;submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter-&gt;executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter-&gt;doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;block_admin_display_form&#039;, Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder-&gt;buildForm(Object, Object) (Line: 217)
Drupal\Core\Form\FormBuilder-&gt;getForm(Object) (Line: 116)
Drupal\block\BlockListBuilder-&gt;render(&#039;example&#039;, Object) (Line: 60)
Drupal\block\Controller\BlockListController-&gt;listing(&#039;example&#039;, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

// Some related notes
I had a few broken blocks lingering for a while but I deleted then recreated them and removed all the offending block config. The broken block log messages cleared up but the error persists.

CommentFileSizeAuthor
#12 entity_usage_3101451_12.patch724 bytesuseernamee
#10 Screenshot 2024-05-22 at 12.20.03.png501.64 KBfernly
#3 3101451-3.patch3.44 KBmarcoscano

Comments

jnycz created an issue. See original summary.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Project: Drupal core » Entity Usage
Version: 8.7.9 » 8.x-2.x-dev
Component: block.module » Code

As indicated by the backtrace, this is a bug in a contrib module

marcoscano’s picture

marcoscano
Primary language Portuguese, Brazil
Location Barcelona, Spain
commented
Status: Active » Needs review
StatusFileSize
new 3101451-3.patch3.44 KB

Thanks for reporting. It's not 100% clear to me how to reproduce the error, but after checking the stack trace I do see a method that could use an early return to avoid such errors.

Patch attached, I hope it solves it for your scenario.

yusufhm’s picture

yusufhm
Primary language English
Location Hallam, Victoria
commented

Patch at #3 worked for me, but your comment led me to dig deeper @marcoscano.

This seems to happen when you choose a config entity type as a source in Enabled source entity types. For instance, when installing the module and initially configuring, I thought I had to check Layout in order to get Layout Builder tracking enabled, which is actually not the case. Same thing would happen if I checked Block as well. When I removed those and left only the content entity types (File, Media, Content, Term, Custom Menu Link), the error goes away.

  • So for people having this issue, I'd make sure I've disabled all the config entity types from Source; checking them wouldn't work anyway, which brings me to another point.
  • If none of these config entity types work, they should be in that list to begin with. Should we remove them?
rivimey’s picture

rivimey
she/her
commented

Encountering this error too. I cannot answer your question as to whether config entities should be included, but it is quite possible to have content entities that are not fieldable, so the problem is not config vs content, but fieldable vs non-fieldable.

So, the right fix will detect non-fieldable entities and not call field operations on them.

Whether that then means the module cannot work I don't know -- if so, only fieldable entities should be included in the settings list.

drcolossos’s picture

drcolossos commented
Status: Needs review » Reviewed & tested by the community

Patch from #3 works for us.

We had tracked "Snippet"s that can be embeded via a "Reference Field"s. The patch above allows saving of a Snippet without the mentioned error.

So this already gave a use case in favor of tracking non-fieldable (config) entities.

I'm setting it to RTBC in case no other discussion should arise from my given example. We would need a way to track entites like Snippets. If this is removed from the module, there should be other means of tracking developer defined entites.

  • marcoscano committed 60fd108 on 8.x-2.x 
    Issue #3101451 by marcoscano, jnycz, rivimey, tim.plunkett, DrColossos,...
marcoscano’s picture

marcoscano
Primary language Portuguese, Brazil
Location Barcelona, Spain
commented
Status: Reviewed & tested by the community » Fixed

Going with the patch in #3 for the moment. Thanks all for contributing.

Status: Fixed » Closed (fixed)

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

fernly’s picture

fernly commented
StatusFileSize
new Screenshot 2024-05-22 at 12.20.03.png501.64 KB

Issue still occurs when trying to use the batch update. Using version 8.x-2.0-beta12 and Drupal core 10.2.4.

p.kasianov’s picture

p.kasianov commented

Got same issue for D core 10.2.4+.

Any updates?

useernamee’s picture

useernamee commented
StatusFileSize
new entity_usage_3101451_12.patch724 bytes

Here's a quick fix for batchupdate issue.
I guess it would be better for the catch statement to be more precise but it is a general direction where the fix should go.

cgmonroe’s picture

cgmonroe commented

FYI - This issue prevents entities that cause this problem from being selected as sources.

#3505220: Limit source entities in settings to ones that have fields