🇵🇱Poland @Luke_Nuke

Just a heads-up, that this module is not abandoned, and I'll be looking into all reported stuff soon, so thanks for the feedback, and thanks for your patience ^^

Thanks for the contribution!

Luke_Nuke → made their first commit to this issue’s fork.

That was helpful, thanks!

Luke_Nuke → made their first commit to this issue’s fork.

That's great, thanks guys!

Luke_Nuke → made their first commit to this issue’s fork.

smustgrave → credited Luke_Nuke → .

I apologize for a very late respond, but better late than never. Nids absolutely can be static. You just need to set ID of the entity before saving it, and it will be saved under this ID.

I decided to grind through the last patch to fix the tests and the remaining issues, and now all coding standard errors are fixed! It's of course thanks to you because otherwise, and without having a base to start from, I probably wouldn't be able to force myself to do this. :)

Thank you for your contributions!

@Prashant.c dpi is correct. The 3.0.x branch dropped support for PHP < 8.0; however, you should still be able to use the latest 2.0.x version if you need it to work on D9 with PHP < 8.0. It is not supported by me, but it functionally is not different from the 3.0.x right now and will work virtually the same. I would recommend you to upgrade your PHP to at least 8.0, though, which would be in accordance to Drupal's recommendation.

If you guys can't wait for D10 support, you may also look into another module that covers most of the similar use cases: https://www.drupal.org/project/content_snapshot → . It just had a D10 compatible release.

Disclaimer: I'm its author and maintainer.

Thanks for your contribution! Unfortunately, it appears that the latest patch breaks tests, so we need a bit more work on it. Also note that there was a 3.0.0 release, so we need to apply the patch to a new branch.

I'm changing priority to minor as it doesn't affect the module's functionality, although I agree that it would be very nice to have it sorted.

Thanks j-vee! I believe the changes shouldn't be applied to the main branch on the fork though, but to the separate branch. See: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → . I made a few changes:

• We don't need to up the PHP requirement. It should still be compatible with older Drupals as well.
• Submodules had to be made Drupal 10 compatible also.

Thanks for your contribution!

Luke_Nuke → made their first commit to this issue’s fork.

This issue blocks layouts from being exportable by any module attempting that (default_content, content_sync among others). As most people from issue queues of these modules will end up here, I decided to write up the possible solution here.

If you really want to have this working on 8.7.x (and possibly 8.8.x), you would have to apply the attached patch. It's just workaround though, because it has some security implications mentioned by Wim Leers . But that's not enough, you also would have to write custom normalizers for Layout elements. It is what was attempted by #24 . There are more issues if you want to use this exporting capability to later import these nodes with layouts. For example exported references to revision ids of inline block contents in layouts configurations won't match with the real ones, so there is more logic required to get proper references on import. I managed to make it work for my use case, and assuming the attached patch has been applied - it can be done by contrib module.