Nice! I see the commit is in 1.1.12, so this is merged and should be closed.
Pushed resolution.
kazajhodo → created an issue.
Updated patch for 2.0.6.
Patch from the commit if anyone wants it.
This happens in php 8.1 as well.
This can be deleted, duplicate of #3442310. Not sure why I'm still having the issue when I pull 2.0.3.
kazajhodo → created an issue.
Updated patch for 2.0.5.
Patch for the meantime.
@aimevp, I think that makes sense. The only place in the code that jquery_ui is found, is the comment within focal_point.libraries.
Throw a commit at the fork quick.
It looks like this issue has returned in 9.5.10.
Within focal_point.libraries, replacing '- core/drupal.dialog' with '- core/jquery.ui.dialog' resolves the issue.
I pushed a commit to the issue branch.
kazajhodo → made their first commit to this issue’s fork.
This is for clarity if someone attempts the patch as I did.
#5 is correct, this patch does not fix the problem. It does fix the error, and allows the form to submit/save; however it masks the actual issue that caused the error in the first place.
The error is caused because the radio options have no default value, in some cases the 'Data Layer' textfield as well. As #5 stated, because the installer did not run/work.
As #5 stated, reinstalling the module will resolve the issue. Then there is no error to patch.
I'm not sure if I'm doing this right, but I found that layout builder would crash and throw duplicate primary key errors on entity clone. This would also create orphaned inline_block_usage rows, with empty layout_entity_id.
The cloned entity would also no longer save, due to the orphaned references.
I added a check in InlineBlockEntityOperations->saveInlineBlockComponent(), for entity id. Line 233.
The entity is always set, but in some cases the entity id would be empty, causing addUsage() to fail. This seems to work fine and nodes save layout builder properly.
This is against 9.5, however I think its relevant to this issue? Its exactly the same as the 10.1 patch, with an addition if statement- so should be fine for 10.1 as well. If the check is in the proper spot, thats an entirely different question. At my experience level... I believe so, but not positive.
I made a patch... of a patch.
When I went to apply my patch, I was editing already patched code.
My combined patch is attached. I did it this way as I'm not all that convinced its the correct way to do it; but at my experience level it seems like the proper place.
This seems to make the clone work fine, and then saves as expected.