Wrong text when entity is layout builder revision

This change seems to do the trick.

One nitpick:

+                  if ($source['source_vid'] == $parent->getRevisionid()) {

should probably use strict comparison.

#2 fixes the problem for me as well

Since 8.x-2.0-beta13, patch #2 no longer applies because of https://www.drupal.org/project/entity_usage/issues/3408306

Updated patch for 8.x-2.0-beta14

I'm closing this issue out! Beta 15 and later seems to gracefully resolve this through https://www.drupal.org/project/entity_usage/issues/3366527.

🥳

I'm still able to reproduce this issue in 2.0.0-beta16 by following the steps in the issue summary. Entities referenced by removed layout builder blocks are still listed as "published". For now, I've adapted the patch from this issue to work with 2.0.0-beta16.

Closed #3527473: "Used in" column is inaccurate for inline content blocks and #3436871: Custom entity within block shown as "Live on page" even when removed from node as dupes.

Created something related #3576178: Layout builder usage can be broken+missing when usage is non default while debugging this.

The patch is a good start but sadly it exposed some bugs.

We're in a tricky situation here because Entity Usage doesn't track target revision IDs, so theres no way to query usage from a layout builder entity to the block content. The `listSources` call in the above patch isnt going to work as-is, not only is it not checking for the 'layout_builder' source, but the bigger issue is determining which revision the usage is associated with.

Lets say you have a usage of a media in a block content. And that block content is inserted into a layout builder entity. Then, you delete the block content. Right now, the patch thinks the association is still there because there are >0 associations between the entity and the block content.

For now I've put together a rather hacky solution, but its working a lot better. It includes some minor refactors for reuse and things, and even accounts for all three of past/current/future, and multiples of each, not just one.

Since this issue was created the usage controller has got some minor LB specific things, as well as Trash things. So maybe this hack is fine for now, but put this in the same "necessary required future architectural considerations for Entity Usage" pile

There is some refactoring of how the module handles tracking of "non-canonical" entities (eg paragraphs, inline blocks in LB, etc) happening in #3547273: Deleting paragraphs causes the entity usage tab to display confusing information . I suspect there might be some overlap with this issue.

@dpi what do you think about making the approach to inline blocks in layout builder more similar to the new approach on #3547273: Deleting paragraphs causes the entity usage tab to display confusing information - i.e. do not consider the inline block to be a real thing that you want to track. What you are looking to track in entity usage across the inline block - so if you embed some media in the inline block the entity usage system shows the usage against the node that contains the inline block.

so if you embed some media in the inline block the entity usage system shows the usage against the node that contains the inline block.

That sounds great, if entity usage is from a non-reusable block it should probably be registered against the layout builder entity rather than the block content.

So long as things can stay in sync when the LB entity is updated on its own, then all child uses should be recomputed, regardless of whether the block entity was updated. A top down approach. There will be cases where custom code, and especially migrations, might touch on block content without triggering a update of the host entity. There should be some handling for that...