EntityStorageException when saving existing paragraph revision via Inline Entity Form

@joseminosa many thanks, you've saved my night. For making this fix visible in search, it helped me with next error:

> Drupal\Core\Entity\EntityStorageException: An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision.

@joseminosa and @zviryatko I was receiving the error on my end, but I solved enabling the option "Create new revision" on Widget form configuration.

Same issue and the patch #2 resolved the issue! Thanks @joseminosa

@igor.barato Could you clarify where to find the "Create new revision" option in the interface you're referring to? Did you manage to solve the problem with or without the patch? Thanks again!

I ran into the same issue with an error, "An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision.".

Following #4 comment by enabling Create a Revision on the node form display for the field using the inline entity form solved my problem.

I can confirm that the error "An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision." that occurs when saving a node with a paragraph field can be resolved by checking the node's paragraph "Create new revision" box.

To make this abundantly clear.

1. Navigate to the offending content type form display page (e.g., /admin/structure/types/manage/article/form-display)
2. Find your paragraph field in the list of fields (my wiget happened to be Inline entity form - Simple)
3. Select the settings icon on the paragraph field to right
4. Check the Create new revision box
5. Click Update button on the field
6. Make sure click the Save button the form too

Thank you to @igor.barato comment #4 and @grgcrlsn321 comment #8!

Overall, I think the Create new revision option should no longer be manually configurable in the widget settings. The patch’s overall approach looks good, but the part that still allows toggling revision: true/false should probably be removed, since applying the patch effectively means the Create new revision setting is no longer respected anyway. Revisions should be created automatically, as suggested in the patch:

if ($entity instanceof \Drupal\Core\Entity\RevisionableInterface) {
  $entity->setNewRevision(TRUE);
  $entity->isDefaultRevision(TRUE);
}

I’m wondering whether there is any valid reason or use case for not implementing it this way.

Claude Code says:

Concerns

1. Blast radius is too broad (high-priority). The conditional fires for every revisionable entity saved through IEF — nodes, media, paragraphs, blocks, custom content entities. Forcing setNewRevision(TRUE) + isDefaultRevision(TRUE) unconditionally breaks:
- Content Moderation — draft/pending revisions must not be the default.
- Workspaces — revisions are workspace-scoped; forcing default-revision here bypasses that.
- The node form's "Create new revision" checkbox — user's explicit choice is overridden.
- Bundles that disable revisions — they'll now get revisions anyway (the RevisionableInterface check only tells you the entity type supports revisions, not that the bundle enables them).
- entity_reference_revisions / Paragraphs — ERR has its own revision-handling logic; double-setting here is at minimum redundant and likely conflicting. This is a dev dep of IEF, so a real collision path.

2. Root cause is unclear. The title is "EntityStorageException when saving" but the fix is "force new default revision." The commit message doesn't explain the mechanism linking the two. This reads like it might paper over a narrower bug (probably an ERR/Paragraphs scenario where a stale revision ID is being saved) with a change that alters behavior globally. Worth checking issue #3532374 on d.o for the reproduction case before merging.

3. Coding standards. \Drupal\Core\Entity\RevisionableInterface is used FQCN-inline; the rest of the file uses use imports. Minor, but inconsistent.

4. isDefaultRevision(TRUE) is awkward. It's valid (the method is getter+setter), but calling an is…() method purely for side effect is unusual. At a glance it looks like dead code.

5. No tests. A behavior change of this scope needs at least one regression test — tests/src/FunctionalJavascript/ComplexWidgetRevisionsTest.php is the obvious home — covering both the EntityStorageException repro and the content-moderation/revisions-disabled cases that this change risks breaking.

Recommendation

Don't merge as-is. Before landing: pull the reproduction from issue #3532374, narrow the conditional to the specific situation that triggers the exception (likely ERR-backed paragraphs, or entities whose loaded revision ID no longer matches the default), and add a regression test plus a "does not clobber draft revisions" test. If the real fix turns out to be just clearing a stale revision ID rather than forcing a new default revision, that would be much safer.

Note that phpunit now shows two failures, both traceable to the five added lines in WidgetSubmit::doSubmit(), which sharpen the picture of what a correct fix has to look like.

Failure 1: ComplexWidgetRevisionsTest::testRevisionsAtDepth with data set "0" (false)

Failed asserting that two strings are equal.
--- Expected '4'
+++ Actual '7'

This data set runs with the inner IEF widget's "Create new revision" setting = FALSE and asserts that no new revision is created for the level-3 entity. The patch calls setNewRevision(TRUE) unconditionally on every revisionable entity at save time, overriding that setting — so a new revision is created and the VID increments (4 → 7).

This is the concern from comment #12 that the patch's impact is too broad: the widget already exposes a user-facing "Create new revision" setting (InlineEntityFormBase::defaultSettings(), default FALSE), and form build already honors it at src/Element/InlineEntityForm.php:138-139. The patch bypasses both. Any fix has to leave that setting authoritative.

Failure 2: SimpleWidgetTest::testEntityWithoutBundle

The text "IEF simple entity no bundle Node title has been created." was not found anywhere in the text of the current page.

This one exposes a straightforward bug in the MR, independent of the design concerns above. The test uses entity_test__without_bundle (defined in tests/modules/inline_entity_form_test/src/Entity/EntityTestWithoutBundle.php), whose @ContentEntityType annotation declares neither a revision key nor a revision_table — the type is not revisionable.

The gate added by the patch is:

  if ($entity instanceof \Drupal\Core\Entity\RevisionableInterface) { ... }

RevisionableInterface is implemented on ContentEntityBase itself, so every content entity passes this instanceof check, including types that aren't actually revisionable. Core's ContentEntityBase::setNewRevision() throws a LogicException when called on a non-revisionable type, and that exception aborts the IEF save before the host node is created — which is why the success text never appears.

The correct predicate for "this entity is actually revisionable" is the one form build already uses at src/Element/InlineEntityForm.php:138:

  if ($entity->getEntityType()->isRevisionable()) { ... }

What these failures suggest for moving the MR forward

1. Swap instanceof RevisionableInterface for $entity->getEntityType()->isRevisionable(). That alone clears failure 2.
2. Don't override the widget's "Create new revision" setting. Failure 1 is the existing contract rejecting the override; if a new revision is going to be forced at save time, it needs to be gated on the same setting form build uses — or on a narrower condition specific to the reported bug.
3. Add a failing FunctionalJavascript test that reproduces the original steps in #1 — Paragraphs type with revisions enabled, IEF-complex widget with "Allow editing", edit an existing paragraph on an existing host, save. Without a reproduction landing in CI, it's hard to tell whether the change actually fixes the reported EntityStorageException or happens to paper over it for a subset of cases.
4. Worth investigating whether the underlying problem is "missing new revision" at all, or rather "in-memory isDefaultRevision got flipped to FALSE on a revision that storage has as the default." The exception's exact wording — "An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision" — is raised in exactly that state. If so, the minimal fix may be closer to: when saving an existing revision without creating a new one, don't allow isDefaultRevision to regress below the loaded value. That would leave Content Moderation drafts and Workspaces-owned revisions alone, which the current approach does not.