Integrity constraint violation: 1048 Column 'langcode' cannot be null

Patch #3 working for me. Thanks

Let's trigger tests here. :)

As always we need tests for this. :) Also, a test-only patch so we can ensure that the code fixes the problem.

It is not working for me with the latest dev version. Do I have to enable some sort of translation functions to have this working?

EDIT: My fault, I just realized that this is just working for the Paragraphs Default Widget and not for the experimental one. I will reroll the patch for this one.

Here is the rerolled patch for the experimental module. Sorry I ain't got the time at the moment to write tests :/

Applied the changes to the wrong method ...

#10 works for me when use entity browser create content option.

#10 also worked for me

#10 works for me

We can only fix such fatals / errors with test coverage.

Haven't rolled this into a test, but one way to reproduce:
- Enable Layout builder
- Create a Paragraph type, and create a Custom Block Type w/ Entity reference to the Paragraph type
- Enable Layout Builder for Article (or some content type)
- Try adding the Custom Block Type w/ the Paragraph Entity reference as a "Custom Inline Block" to a section on the Article. Can get all the way through adding and placing it, it will show up on the preview.
- When hit Save Layout, the error is triggered.

I don't know if this being the test is complicated by the fact of using Layout Builder, technically still experimental module. Perhaps there is a better way to evaluate I have not come across, but this is my use case that is breaking.

I can confirm the problem occurs when following the steps in #15. Patch in #10 fixes the problem (for now).

This happens as well for me with Entity Browser and creating content with paragraph. #10 seems to fix the issue.

#10 works for me, thanks!

I have the same situation, as #15, and patch from #10 solved my problem, so I change issue status to RTBC.

We can only fix such fatals / errors with test coverage.

Another +1 to patch #10. This time coming from editing paragraphs using Views Bulk Edit.

Are all of us coming from "Paragraphs-adjacent" use cases?

I needed this. While the patch on #10 does fix the issue, I am not sure on the implementation

1. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1273,7 +1273,11 @@ class InlineParagraphsWidget extends WidgetBase {
   +        $paragraphs_entity->set($langcode_key, $paragraphs_entity->get($langcode_key)->getLangcode());
   

   I don't understand this line, ain't it setting something from what was already set with the same thing?

2. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -1273,7 +1273,11 @@ class InlineParagraphsWidget extends WidgetBase {
   +        if (!empty($form_state->get('langcode'))
   

   I think this one is the actual line that fixes this error

Having said the above, just ignoring the the langcode null might still cause issues later on.

I debugged this trying to come up with a better idea. I actually don't think the root cause of the error is on this module, but rather inline_entity_form.

What I found out is that when the paragraph widget is rendered normally on an entity form, https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21... is run, but this code is never run when using entity_browser and inline_entity_form.

I am proposing a different approach, which is still a bandaid but one that I believe could prevent more issues related to this appear elsewhere.

I set my local up for testings and will try to add a test at some point, so leaving it at Needs work.

Also hit this. Agreed that #24 is a better approach than #10.

+++ b/src/Plugin/Field/FieldWidget/ParagraphsWidget.php
@@ -2284,6 +2284,35 @@ class ParagraphsWidget extends WidgetBase {
+  protected function initFormLangcodes(FormStateInterface $form_state, ContentEntityInterface $host) {

Might make sense to split this out into a ParagraphsWidgetBase to avoid duplicating it in both InlineParagraphsWidget and ParagraphsWidget?

I just updated to 8.7 and ran into this bug when I tried adding a custom block type with Layout Builder. The block type had a paragraph reference field on it. After adding it to a page with LB as an inline block the error occurred. Neither patch #10 or #24 fixed the issue.

Update: Actually, I spoke too soon. Patch #24 did work when adding new blocks with paragraph fields in LB.

While patch #24 works to resolve that issue in LB it causes an issue while using content moderation. Any content sent to a draft state with a paragraph is no longer viewable or editable in LB.
When trying to view a draft in LB instead a user gets this message.
"You are not allowed to view this Paragraph.
You are not allowed to edit or remove this Paragraph.
"

#24 tests successfully for me. I agree with #25 re code duplication.

@sepapp2 - Re #27, what is the behavior before this patch? I suspect the issue described in #27 may be unrelated.

Attached patch is #24 but the duplicate code is moved to a trait. Leaving at 'Needs work' so a test can be written.

in database go to langcode field check the NULL option.

Hi, the patch works as expected: the error has gone.

Should https://www.drupal.org/project/entity_browser/issues/3014194 be closed as duplicate?

P.S: I've updated the patch for current -dev version.

@FiNeX #29 still applies cleanly to the latest dev release and you've made changes to the patch without providing an interdiff or explaining what you've done. Is there a reason you changed both langcodes to $language = \Drupal::languageManager()->getCurrentLanguage()->getId();? This doesn't seem right to me.

@acbramley: when I've tested the patch #31 I was not able to cleanly apply it so I've applied manually and I've recreated the patch. The code you're pointing has been introduced on #31. I've only updated the patch #31 for the current -dev.

Sorry @FiNeX you're right, I skipped looking at #31 since it didn't apply cleanly.

I think we should still consider #29 as the correct approach here. Setting back to NW for tests.

Following. I tried several of these patches and still receive the error. I'm running paragraphs 8-1.9 on Drupal 8.7.0

I had this problem with a paragraph field in a block type using the layout builder. Patch in #29 solves the issue for me

I had a problem with batch-updating nodes and their paragraphs the patch in #29 just applied cleanly and solved the issue

Patch in #29 resolves the error and applies cleanly to 1.10.

Similar setup as #15 with 1.10 and patch applied cleanly and fixed issue.

Confirming patch #33 works for me.

I confirm that #33 works perfectly fine for me. Thank you @FiNeX.

#33 worked for me too in the context of a field on a custom block placed on Layout Builder.

Spotted a typo in patch of #29. If you're coming to this issue please test/review/improve that patch (as per discussion in 34/36)

@see ContetEntityForm::initFormLangcodes() Should be ContentEntityForm :)

#33 fixed this issue for me.

Hi,

I stumbled on this error while reviewing this issue. Specifically, at the "Save layout" I got the error. Applying patch #33 fixed the error for me.

I will leave this to needs work as it still needs tests.

#33 fixed the issue for me in version 8.x-1.11

Minor issue: The patch have some spacing (tabs) issue at file src/Traits/FieldWidgetTrait.php

Adding another +1 to #29 fixes the issue on new Paragraph entities embedded within a Custom Block on a Layout per the guidance in #15. I did have to recreate the entities to inherit the langcode, but it did work.

Marking still 'Needs Work', per #2901390-47: Integrity constraint violation: 1048 Column 'langcode' cannot be null:

I will leave this to needs work as it still needs tests.

However, I am extending the work of #29 with the small typo change in #45.

Patch and interdiff attached. Typo down, now let's get some tests written and get this into a release.

The above patch seems to include an unnecessary .orig.

Whoops, thanks for catching the unnecessary .orig - updated my helper patching tool to mitigate that moving forward.

Re-rolling #29 with changes as requested in #45.

#51 applies cleanly to 1.12 and fixes the error for me when adding a paragraph field to a layout builder content.

Thanks

#51 works for me too. Thank you @webbeh

#51 worked for me. Thanks for the patch @webbeh.

#51 works for me too on a layout builder paragraph block.

Also tested #51 using Layout Builder and it worked for me.

#51 worked for me. Subscribing.

Also confirming #51, and reiterating for any new visitors that if you have any existing entities created before you apply the patch, you'll still get the error, and must delete them and recreate them to see the fix.

#51 works well

+1 RTBC, #51 works well for me

I can also confirm #51 works. Thanks to all for the efforts!

I've also used #51 to solve this issue in the Views Entity Form Field queue:

https://www.drupal.org/project/views_entity_form_field/issues/3067248.

My thanks as well for all the good work.

#51 works great! Thanks @Webbeh!

Patch in #51 works for me. Thank you!!! D8.9 + Paragraphs 1.12

Is anything else needed on this; can it be rolled into a release?

The patch in #51 worked great for us. Thanks for the work!

D9.0.1 + Paragraphs 1.12

#51 works for me as well when using paragraphs with layout builder.

Is anything else needed on this; can it be rolled into a release?

We still need automated test coverage for this, before it could be set as RTBC.

Besides that, ATM I don't agree with the implemented approach of patch #51. As for the $form_state->set(...) calls I see there, it seems to handle the symptom, not solving the root cause. Other inline-embedded entities not being paragraph types seem to work properly, thus it might be something wrong with setting the langcode values of new paragraph entities. It might happen during the logic of the widget plugins, but I'm not sure whether the form state is the right place to manipulate there.

Results from performing a manual test using the case of #15: Patch from #51 has the effect, that the fatal error described in issue summary doesn't appear anymore and the paragraph items will be saved in the database. But it introduces a new bug.
Steps to reproduce:
- Have multiple languages installed, use one as default language for creating new custom blocks (e.g. English).
- Create an inline block within the Layout Builder, using a custom block that uses paragraphs.
- Within the block form, choose another language that differs from the default language selected (e.g. German).
- Add the inline block having at least one paragraph item and save the layout.
Result:
- The block_content instance is saved with the chosen language (correct)
- The paragraph items belonging to the block_content instances have the default langcode (wrong, should be same as block_content).

Also when trying to change the language of an already existing inline block, the paragraph items will be always updated with the previously set langcode of the parent instance, not the (probably changed) submitted langcode.

Trying to work on a solution, focussing on use case #15.

Feel free to add "Needs tests" tag again if the written one is not enough (or wrong).
No interdiff provided as it's another approach.
Please review and test this one for your use cases. It works on my use case for using Layout Builder's inline blocks with paragraph fields.

Same as #71, only trying to make it compatible with tests running with D8.

There's a bug in #72 which doesn't exist in #51 where removing a paragraph item and resaving the block triggers a similar error when saving the layout:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'langcode' cannot be null: UPDATE {paragraphs_item} SET "revision_id"=:db_update_placeholder_0, "type"=:db_update_placeholder_1, "uuid"=:db_update_placeholder_2, "langcode"=:db_update_placeholder_3 WHERE "id" = :db_condition_placeholder_0; Array ( [:db_update_placeholder_0] => [:db_update_placeholder_1] => link [:db_update_placeholder_2] => c111cd8b-8414-4c7f-9aa9-9124a6a2aa9f [:db_update_placeholder_3] => [:db_condition_placeholder_0] => 21973 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 810 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php). 

To reproduce:

1. Create a block with multiple paragraph items in a single field
2. Save the block + page
3. Re-edit the layout and block and remove a paragraph from the middle of the list
4. Re-save the layout

I'm trying to reproduce #74, but no luck so far.
I'm using the Layout Builder's standard layout form (no modal extension, also no further module like symmetric translations etc.). I use the "create custom block" element (inline block). I always first click on "Update" within the inline block form and then save the layout.
All my content entities are configured to be translatable and use the site's default language as default language. I have the language field enabled within the form, but also tried to reproduce without having the field enabled.

There seems to be a constellation in site configuration which might lead to the case of #74. Could you please maybe try to provide a little bit more details about that constellation? An automated test which leads to that case could help too.

Edit: I tried to reproduce #74 on a fresh standard profile using Paragraphs, Layout Builder and a content block with a paragraphs field. I placed it within Layout Builder via inline block form. Unfortunately still no luck on reproducing the case. Could maybe someone try it too, and if reproduced, provide configuration details?

Hello Everyone,

First of all I want to thanks everyone who is working on this issue. I checked the code and tried to apply the patch which is mentioned in the comment #72. The patch didn't got applied because of some reason. However, with reference to patch at comment #72, I made some changes based on the current version.

Patch #76 works for me.

I got the same issue as #74 when using paragraph in layout builder. It happened in a nested paragraph though. The website is only in english.

It seems we cannot make progress without an automated test written for the use case mentioned in #74 / #78, or please provide more details. Of course we still can discuss other options, but I think due to the complexity it surely helps if we have more tests to reproduce the remaining problems.

I got the same issue as #74 using patch #76 and #72, when using paragraph in layout builder.

1- Create a block with multiple paragraph items in Layout Builder
2- Save the block
3- Save node
4- Re-edit the layout and block, remove a paragraph and add another.
4- Re-save the layout

Site only in english.

PHP 7.4.7, MYSQL 5.7.16, Drupal 9.1.4

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'langcode' cannot be null: UPDATE {paragraphs_item} SET "revision_id"=:db_update_placeholder_0, "type"=:db_update_placeholder_1, "uuid"=:db_update_placeholder_2, "langcode"=:db_update_placeholder_3 WHERE "id" = :db_condition_placeholder_0; Array ( [:db_update_placeholder_0] => [:db_update_placeholder_1] => banner [:db_update_placeholder_2] => b29b6335-1d35-4c65-b6a7-134805d73da0 [:db_update_placeholder_3] => [:db_condition_placeholder_0] => 182 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 810 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Still I'm getting the below issue when updating the existing paragraph or removing the existing paragraph on the layout builder of a node.

This issue occurs with and without applying the patch #76 and #72.

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'langcode' cannot be null: UPDATE {paragraphs_item} SET revision_id=:db_update_placeholder_0, type=:db_update_placeholder_1, uuid=:db_update_placeholder_2, langcode=:db_update_placeholder_3 WHERE id = :db_condition_placeholder_0; Array ( [:db_update_placeholder_0] => [:db_update_placeholder_1] => 33_33_33_image_with_text [:db_update_placeholder_2] => 6ef454bb-0f05-46ba-b087-c86e51a70c2f [:db_update_placeholder_3] => [:db_condition_placeholder_0] => 18 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 846 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Let's try with this one.

Hi @mxh,

Applied the patch #82 but no luck still facing the issue. Please find the attachment.

Some notes:

• If you added a block before applying the patch, then trying to save the layout with that added block, it will not work, because the Layout Builder's intermediate blob state is not being addressed here. What is being addressed here is the process of adding the block via the form. To test if the patch works for you, you need to test with a completely new layout (not with an already existing intermediate state of the layout). IMO it does not make sense trying to fix the intermediate state of blobs. What gets into the blob, stays in the blob.
• If you still encounter the error - then once more like I already said in #79 please - at least provide a deterministic way to reproduce the error like #80 or even better write an additional Unit / Kernel or functional test. Having an automated test would help us to reduce misunderstandings, we can directly address the problem and proceed with this issue.

Added clarifiers and to-do's from 84 into original issue to hopefully encourage productive testing and edge-case issue reproduction.

Reformatted issue to hopefully give a brief synopsis of the issue.

Confirming the patch in #82 fixes the issue for me.

Patch in #82 fixed it for me too, thanks!

Using Drupal 9.2.1 and paragraphs 8.x-1.12, #82 applies cleanly via composer and resolves the issue. I started with a new layout as noted in #84. Thank you!

In case anyone might still experience issues with patch from #82, please report accordingly, best case would be to reproduce with further Unit/Kernel/etc tests.

I am also confirming that patch in #82 is applied cleanly and is working as expected.

Patch #82 fixed the issue, Thanks!!!

I just wanted to confirm too that #82 is working for me as well.

Thanks!

I currently don't know how we could push this any further to get it fixed. Do we need more tests?

#82 works for us in Open Y distribution. Thanks
+1 RTBC

#82 fixed the issue I was having with a paragraph widget in a custom form. Thanks

I currently don't know how we could push this any further to get it fixed.

I would assume at this point, our remaining tasks were to determine if anyone has any issues after application of #82. I haven't seen any real concerning impact, so we should probably reach out to the maintainers (via Drupal Slack or email) and ping them about this issue, as it would be great to get this issue resolved.

Maintainers have been pinged and aware of the issue. Will try to find some time to get it committed.

#82 applied perfectly and fixed the breaking error I had when adding a paragraph to custom block.

Moving to 8.x-1.x-dev and queuing a retest.

This issue happens with Drupal core 9.3.3 also

#82 failed to fix the error for me on D9.3.5. Our use case is adding a block type containing a paragraph within layout builder.
Edit: had "The URL alias field needs to be installed", fixing that fixed the issue with the patch.

This is a complex change and not too fond of adding (another) entity to the form structure that is then serialized, that won't help with performance. But I also understand that this apparently helps a lot of people so I'll commit this.

Did clean up the test a bit, D9 deprecations and not fond of random machine names and labels, that just makes debugging something harder. Also renaming widget references, it's legacy/stable now, not classic/experimental.

Committed. Note that this isn't in the 8.x-1.13 release, I deliberately did that first, so this can be tested a bit more in the dev release.

#103 seems to work for us. Only used it a little, but the errors went away and we can add inline blocks to layout builder when multilingual is used on the site.

#103 is not applied for D9.4.5. Will you be updating it?

This patch is modified according to #10. Although part of the code in this issue has been merged, the problem still exists. When I apply paragraphs in a block, this block is applied in layout build. When saving the layout, this error will be prompted.
drupal version is 10.1

The bug does exist in Drupal 11 also, while using paragraph reference field in block types, currently using patch from #109, but not sure if it could cause issue somewhere else or will continue to work properly.

Thanks