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