Add langcode column to inline_block_usage

Looking good. Thanks for breaking this out.

1. +++ b/core/modules/layout_builder/layout_builder.install
   @@ -92,8 +92,13 @@ function layout_builder_schema() {
   +      'langcode' => [
   +        'type' => 'varchar_ascii',
   +        'length' => 12,
   +        'not null' => TRUE,
   +      ],
   

   Need a description here. Also probably default looking at other langcode fields.

2. +++ b/core/modules/layout_builder/layout_builder.install
   @@ -136,3 +141,24 @@ function layout_builder_update_8602() {
   +  $spec = [
   +    'type' => 'varchar_ascii',
   +    'length' => 12,
   +    'not null' => TRUE,
   +  ];
   

   Description and default

3. +++ b/core/modules/layout_builder/src/InlineBlockEntityOperations.php
   @@ -137,6 +137,18 @@ public function handleEntityDelete(EntityInterface $entity) {
   +   * @param EntityInterface $entity
   +   *   The parent entity translation.
   

   Need to fully namespace @param

4. +++ b/core/modules/layout_builder/src/InlineBlockUsage.php
   @@ -38,12 +39,21 @@ public function __construct(Connection $database) {
   +      // @todo
   

   Is this @todo done?

5. +++ b/core/modules/layout_builder/tests/src/Kernel/InlineBlockUsageTest.php
   @@ -0,0 +1,83 @@
   +    $this->assertCount(1, $this->inlineBlockUsage->getUnused());
   

   We should probably confirm the correct block_content_id is returned.

6. +++ b/core/modules/layout_builder/tests/src/Kernel/InlineBlockUsageTest.php
   @@ -0,0 +1,83 @@
   +    $usage = $this->inlineBlockUsage->getUsage(2);
   

   We could also test

   $this->inlineBlockUsage->getUsage(1)
   

   and both calls to

   getUsage()
   

   before the translation is removed.

7. +++ b/core/modules/layout_builder/layout_builder.install
   @@ -92,8 +92,13 @@ function layout_builder_schema() {
   +      'langcode' => [
   +        'type' => 'varchar_ascii',
   +        'length' => 12,
   +        'not null' => TRUE,
   +      ],
   

   Needs a description

8. We could also test removeByLayoutEntity(). it wasn't changed here but it will be removing more rows now.

1. re #11.6 Actually looking at getUnused() I don't think we need the extra test coverage here because that is unrelated to this change.
2. re #8 nevermind.

3. +++ b/core/modules/layout_builder/layout_builder.install
   @@ -136,3 +142,26 @@ function layout_builder_update_8602() {
   +    'initial' => \Drupal::languageManager()->getDefaultLanguage()->getId(),
   

   I realize now that we can't just set the initial value to the site default language.

   Even though the layouts could not be translated before this patch you could still have entities that where the default language was not the sites default language. So inline blocks used in those entities should have the langcode of the entities.

   But as it is now we have to have an initial value here because langcode column can't be null.

   Maybe langcode should be allowed to be null.

4. +++ b/core/modules/layout_builder/src/InlineBlockUsage.php
   @@ -38,12 +50,20 @@ public function __construct(Connection $database) {
   +    if ($entity instanceof TranslatableInterface && $entity->isTranslatable()) {
   +      $data['langcode'] = $entity->language()->getId();
   +    }
   +    else {
   +      $data['langcode'] = $this->languageManager->getDefaultLanguage()->getId();
   +    }
   

   If the entity isn't transable we assign the site's default language here. But maybe we shouldn't.

   The entity is not translatable maybe should have null for langcode.

5. attaching patch that just fixes test failure for now

1. @johndevman yes I agree we shouldn't set this to NULL.
   This patch sets the initial value to LanguageInterface::LANGCODE_NOT_SPECIFIED

   And then attempts to update all the records

   Since there could be thousands of records I didn't want to have to load all the entities.
   Also would loading the entities even work because it would give us the latest revision and this might not be the revision that where the inline block was used which could have a different language value(I think).

   This also has to consider config entities like entity view displays which do have a language returned.

2. +++ b/core/modules/layout_builder/src/InlineBlockUsage.php
   @@ -38,12 +50,20 @@ public function __construct(Connection $database) {
   +    if ($entity instanceof TranslatableInterface && $entity->isTranslatable()) {
   +      $data['langcode'] = $entity->language()->getId();
   +    }
   +    else {
   +      $data['langcode'] = $this->languageManager->getDefaultLanguage()->getId();
   +    }
   

   I think regardless of whether entity is translatable or not
   $data['langcode'] = $entity->language()->getId();
   will give use the correct value since language() is on EntityInterface and it should always return a language object.

1. #16 @johndevman thanks testing. I followed you steps and got the same error, which read "The default translation flag cannot be changed" which looks like it comes from here \Drupal\Core\Entity\ContentEntityBase::onChange()

   I could find an existing issue. It seems like bug just because of the fatal error but it is always a pretty edge case series of steps. But not related layout builder but maybe tells as far as what might not be possible.

   I think the problem would be

   1. user creates english node.
   2. user creates layout override with inline block creating new revision
   3. user changes node to spanish
   4. layout_builder_update_8701 runs
   5. since node is currently spanish this will be added to the inline_block_usage_table
   6. user creates an english translation
   7. user deletes the english translation
   8. This would delete the revision that use the line block but not the inline_block_usage row or the block_content entity.(need to test to confirm)

   This series of step leaves an orphaned non-reusable block_content entity that isn't referenced anywhere which is suppose to happen
   it is not horrible because:

   1. it would only happen to entities before this update where the language is set and then changed with an inline block being added before the change
   2. the block would still get deleted when the entity is deleted completely
   3. it won't happen for inline blocks after this update because will be adding the langcode as we go.

   I am trying to think of situation where you could delete a translation and the inline block is deleted when is shouldn't be(as opposed to not deleted when it should be) but I can't think of one.

2. Here is the start to an update test. I had to make the a fixture with layout builder enabled for the inline_block_usage table to be there. I s there a way to do this without an install fixture?
   I made a patch without the fixture for review

NW for more tests

If this issue is still needed, I think it's postponed on #2946333: Allow synced Layout override Translations: translating labels and inline blocks