Support adding new entities when translating

Patch #89 does not work for 8.x-1.0-rc14 with Drupal 9.5.3 (it can be applied but it does not solve the problem).

I did not find any other patch or any other solution.

Does anyone have an idea how can I solve this?
Thx.

#93 solved:
"Allow user to make asymmetric translation" has to be activated on Manage Form Display of the conent type.

While testing this patch out I noticed that if the language of the content is changed this does not work quite well with referenced entities and sometimes their language gets changed as well or sometimes the entity remains in its original language and then differs from the one of the content after save ... We should not be assuming that we can simply change the language of the referenced entities since suddenly they might not get displayed in other places if they are reused. Instead, we should be translating them as this is the safe option. Worked on 🐛 Main entity language change does not propagate to nested paragraphs in preview mode Needs review for adding support for propagating the language change and adding support in the patch here as well. I am not sure if this is the right issue though or if another is needed for this.

The last submitted patch, 95: 2822764-95.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

There is a failing test about the same langcode for child entities. IMHO, it's not "valid", because this patch is in the way to allow having asymmetric content. I've removed some lines. Feel free to improve/blame :)

The last submitted patch, 97: 2822764-97.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Forgot to remove a line.

The last submitted patch, 99: 2822764-99.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Updating version to the latest dev

I've prepared a merge request to the 2.0.x-dev branch with an updated patch. For me it works well, appreciate it if anyone else could test it.

Also, attaching a file version of a patch in order to run some tests (cuz it seems for the 2.0.x-dev branch we have disabled tests running).

I'm still using rerolled patch from #90 (due to the same reason which mentioned there) over rc15 and D10.

With Drupal upgrade we have an exception when entity removed from ief widget and parent entity saved:
"Entity queries must explicitly set whether the query should be access checked or not"
This is because of absent accessCheck method on query in 'delete' method.
Added this check to patch from #90

Also this should be added to patch #99 because otherwise it'll throw an exception on D10 as well.

Sorry, wrong file was attached

I create a new patch for drupal 10.1.x, thanks for @quadrexdev, the #103 is useful for me. At the same time, I merged the patch in this issue Parent form entity builders run on IEF resulting in fatal errors 🐛 Parent form entity builders run on IEF resulting in fatal errors Active into the new patch.
And I added the code for checking entity langcode and form langcode to get the corresponding entity.

I could not apply the #106 patch on Drupal 9.5.9 with PHP 8.1 on the 8.x-1.0-rc15 version. Was anyone able to use this patch cleanly?

Indeed the #106 patch is already based on the one you linked @drupalevangelist.

Here's the one that does not need any pre-patch :)

Thank you! I was able to apply cleanly #111 patch on 8.x-1.0-rc15. But now I'm not encountering the following error when I try to create nodes using certain content types that has the Inline Entity Form widget configured:

Error: Call to a member function bundle() on null in Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection->stripAdminAndAnchorTagsFromResults() (line 289 of core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php).

111 did not worked on 1.0-rc15 so I made some slight alterations for anyone interested.

Reroll against 3.0.0-rc19

Refactored patch because of failed tests in #114

Fixed broken tests

Adding refactored patch for the 3.x branch (c753ec1).

- The following code is reinstanted back to InlineEntityFormComplex.php file as removal of these caused namespace reference loss for existing code:

use Drupal\Component\Utility\Tags;
use Drupal\Core\Entity\Element\EntityAutocomplete;

Here's the follow-up update to the patch in #117.

- The following code is reinstanted back to InlineEntityFormComplex.php file as removal of these caused namespace reference loss for existing code:

use Drupal\Component\Utility\Tags;
use Drupal\Core\Entity\Element\EntityAutocomplete;

This is the patch is the same as #118, but rerolled for 3.x-rc19.

The patch is same as #113, re--rolled it for 8.x-1.0-rc17

The last submitted patch, 120: 2822764-inline_entity_form-120.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

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

robin.houtevelts → changed the visibility of the branch 3.x to hidden.

The latest commit of https://git.drupalcode.org/issue/inline_entity_form-2822764/-/tree/2822764-support-adding-new-entities-when-translating applies cleanly to 3.0.0-rc20 as a patch. I made a small change to remove @label from the translatable markup that was never actually getting replaced.

The failing TranslationTest needs to be fixed and it seems to me that this patch has unintentionally changed the behavior even when allow asymmetric translations hasn't been enabled as the test fails on line 108 which is well before we enable it.

    // Both inline nodes should now be in English.
    $first_inline_node = $this->drupalGetNodeByTitle('Kann ein Känguru höher als ein Haus springen?');
    $second_inline_node = $this->drupalGetNodeByTitle('Can a kangaroo jump higher than a house?');
    $this->assertSame('en', $first_inline_node->get('langcode')->value, 'The first inline entity has the correct langcode.');
    $this->assertEquals('en', $second_inline_node->get('langcode')->value, 'The second inline entity has the correct langcode.');

#126

The website encountered an unexpected error. Try again later.

Error: Call to a member function isTranslatable() on null in Drupal\inline_entity_form\Form\EntityInlineForm->delete() (line 346 of modules/contrib/inline_entity_form/src/Form/EntityInlineForm.php).
Drupal\inline_entity_form\WidgetSubmit::doSubmit()
call_user_func_array() (Line: 113)
Drupal\inline_entity_form\ElementSubmit::doSubmit() (Line: 83)
Drupal\inline_entity_form\ElementSubmit::trigger()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult() (Line: 39)
Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 704)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Looks like this patch was on the right path from #95 and then veered away from it. I strongly agree with #95 that we should be translating entities rather than changing their langcode as that is destructive and would confuse editors. I believe the fix in #52 might have been trying to address that but it may be redundant now. Also, it only prevents deleting entities used by the parent node but that could mean they are still deleted if referenced by other entities. Heavily based this MR off #95.

Changes in MR 120:

1) Inline entities are translated rather than having their language changed.
2) Re-attached the submit handler from #95 that was removed and handled the case where the main entity form is submitted but the inline entity form hasn't been opened yet.
3) Removed the deletion code that was trying to prevent entities being removed if referenced by the parent entity (I think that is probably better handled by something like entity_reference_integrity module). See above for reasons.
4) Translations get their own created/updated timestamps when they are created rather than inheriting from the default translation. This helps them show up in the /admin/content view when the parent page is translated.
5) Rename the testTranslation test to testSymmetricTranslation and added cases for translations and timestamps. Also created a new testAsymmetricTranslation test to test asymmetric behaviors which was more thorough than the previous behaviour.

Feedback welcome.

Regarding the comment in #127 the line number you indicated the error on doesn't match up with my MR so I don't think its related. Anyway I'm working on MR 120 now.

One more update on #129, I have a use case that on certain languages that are English language variants e.g. en-GB and translate from a default en node, that the IE shouldn't be translated to en-GB by default. Rather than translations, they are localizations. Currently a new translation would be copied from the en inline node, and the languages would split, so it's not possible to share content across languages.

In this case, en-GB should still be able to reference en nodes without translating them. There could be other use cases, so the most flexible way is to introduce a new ShouldTranslateEvent that gets dispatched just before translation but keep the behavior described in #129.

I am adding a static patch 2822764-129.patch based on #129 ✨ Support adding new entities when translating Needs review / MR #120

Looks like this patch will make previously created translations not have a value.

@jksloan2974 do you mean the patch from #131. Do you have any steps to reproduce? I think if you were to apply that patch to a site that was using the previous method from an earlier patch (where the language of the entities was changed rather than translated) I could see that happening but not sure how it would occur on a fresh site.

I think it is because I have an inline entity form reference to an eck inside a paragraph. I will see if I can generate steps to reproduce

Ok after doing a bit more research it appears at least in my example. Content and translations were created before the field was set to be translatable. Once I went into the field settings and made the field translatable that is when the translation will not display the fields any more.

Does anyone know if there is a way to fix the issues describe below?

1. Entity reference field referencing ECK is set to not allow translations (created through IEF - when creating node)
2. Content is created
3. Entity Reference Field allow translations is turned on
4. Translations are now missing the Entity Reference field that was created in step 2.

Is there an automated way to create those translation that are now missing?

With the issue above I was also having this when moving a paragraph field to translate. Someone created a patch that when a asymmetric paragraph get turned on to translation content will be migrated to it's own translation.

https://www.drupal.org/files/issues/2023-06-07/2992777-paragraphs_asymme... →

We are also experiencing issues with this patch https://www.drupal.org/files/issues/2024-12-17/2822764-129.patch →
InvalidArgumentException: Invalid translation language (und) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 985

When using 3.x dev version with patch https://www.drupal.org/files/issues/2024-02-23/inline_entity_form-282276... →
things work as intended....at least for our setup. Entity reference field on a node and translations disabled

Thank you to everyone trying to fix this problem.

We had encoutered some very weird issue with the MR120 and 3.x where configuration forms where not being saved.

The most problematic one was "Content language and translation" /admin/config/regional/content-language where you couldn't change the value of a field translation.
Go to this config form, open the "Content" accordion, then choose a CT (article for example) and check or unchecked the title to make it not translatable anymore, then save.
When the page reload, the title won't have its status changed.

If you remove the MR, then the form works again.

We also encountered this on media_directories module in the UI section and it seems to affect nested configurations.

So for the moment we're sticking to 8.x-1.0-rc17 and patch #113.

Due to this problem which seems pretty important, I'm switching the status to Needs Work.

Thanks for the steps to reproduce @tostinni. I just tried toggling the translatability of the Article title field but it was correctly saved. I'm using IEF 3.0.0-rc20 and Drupal core 10.3.14. Might be a version thing or another conflicting module? Hard to say. If other people could test that would be great.

@undersound3 #138 What were you doing when that issue occurred. Does the parent node or the inline entity you're trying to translate not have a source language set? i.e. und. There are quite a few core/contrib issues about the same thing so it might be something that needs to be accounted for

When using nested content blocks and Complex widget in Layout builder, the following error occurs:
Error: Call to undefined method Drupal\layout_builder\Form\UpdateBlockForm::getEntity() in Drupal\inline_entity_form\Plugin\Field\FieldWidget\InlineEntityFormComplex->extractFormValues() (line 731 of /data/sites/web/xxxxx/web/modules/contrib/inline_entity_form/src/Plugin/Field/FieldWidget/InlineEntityFormComplex.php).

There is no getEntity-method for the layout builder form which triggers an error here:

$main_entity = $form_state->getFormObject()->getEntity();

Created a patch based on https://www.drupal.org/project/inline_entity_form/issues/2822764#comment... ✨ Support adding new entities when translating Needs review and combined with the Called to undefined method getEntity when using in Layout Builder as mentioned in https://www.drupal.org/project/inline_entity_form/issues/2822764#comment... ✨ Support adding new entities when translating Needs review