Update inline block usage on import

Uploading patch for easier Composer usage.

Thanks for the review.

+++ b/src/EventSubscriber/InlineBlockUsageFixer.php
@@ -0,0 +1,156 @@
+    EntityTypeManagerInterface $entityTypeManager,
+    ?InlineBlockUsageInterface $usage,
+    ?SectionStorageManagerInterface $sectionStorageManager

could use https://www.php.net/manual/en/language.oop5.decon.php#language.oop5.deco... to simplify definition above

Thanks @andypost for the feedback and pointing me to a constructor syntax I forgot or didn't know it exists.

But that would raise the PHP minimum version required by the module. And as the module still supports Drupal 9, I am not sure it is a possible change to do right now?

Good point, yes, we need to keep BC!

Is there a way to add basic test for new class?

I don't look at the patch yet and may layout builder understanding is very limited. I don't quite understand why we need to help it maintain its internal info, seems like a workaround for limitations in layout builder itself?

also, the layout builder integration isn't even committed yet, that should be the focus, specifically in regards to tests which it hasn't yet. And if this is really required for it to work properly, it could also be part of the same issue.

Hi,

Thanks both of you for your feedbacks.

and may layout builder understanding is very limited

Me too, so I may have taken the problem in a wrong way.

seems like a workaround for limitations in layout builder itself?

Yes, it may be a workaround for a core bug.

The only place were the inline block usage is inserting entries inthis table is in InlineBlockEntityOperations::saveInlineBlockComponent(), which is only call in InlineBlockEntityOperations::handlePreSave() which is call in layout_builder_entity_presave. So I guess that it should work out of the box.

But in InlineBlockEntityOperations::saveInlineBlockComponent(), there is an if statement before inserting in the table. So I guess the way default_content is exporting Layout Builder data may be wrong (at least when reinstalling a website). And in this case it should be handled in the other issue.

Is there a way to add basic test for new class?

Before doing that, like @Berdir pointed out, it may be a workaround for either a core bug or a bug in the other default_content issue about Layout Builder.

also, the layout builder integration isn't even committed yet, that should be the focus, specifically in regards to tests which it hasn't yet. And if this is really required for it to work properly, it could also be part of the same issue.

Agreed. I needed a generic quick fix now for multiple projects using both Layout Builder and Default Content and I didn't wanted to risk breaking the MR on the other issue with this change in case people get patches for Composer using the MR URL directly.

> Agreed. I needed a generic quick fix now for multiple projects using both Layout Builder and Default Content and I didn't wanted to risk breaking the MR on the other issue with this change in case people get patches for Composer using the MR URL directly.

That makes perfect sense, thanks contributing and working on this publicly.

Specified this patch along with those listed in the description:

            "drupal/default_content": {
                "1 - Import should overwrite files - https://www.drupal.org/project/default_content/issues/3200212#comment-14332801": "https://www.drupal.org/files/issues/2021-12-08/default_content-3200212.patch",
                "2 - Don't add translation, if exist - https://www.drupal.org/project/default_content/issues/3176839#comment-13859359": "https://www.drupal.org/files/issues/2020-10-14/default_content-3176839-2.patch",
                "3 - Add a Normalizer and Denormalizer to support Layout Builder - https://www.drupal.org/project/default_content/issues/3160146#comment-14814050": "https://www.drupal.org/files/issues/2022-12-06/default_content-3160146-53.patch",
                "4 - Update inline block usage on import - https://www.drupal.org/project/default_content/issues/3359137#comment-15042582": "https://www.drupal.org/files/issues/2023-05-09/default_content-3359137-3.patch"
            },

With this, I successfully ran drush dcer node ${NID} --folder=modules/custom/my_custom/content/, imported my database without the content, enabled my_custom module, and the content is there.

THANK YOU for these patches!

I'm running into a similar situation except instead of using Default content, I'm migrating inline blocks. I wonder if there's a deeper issue here.

This depends on another issue and can't be RTBC yet.

And yes, as discussed, it looks like this might be a workaround for an issue in LB itself, but not using that