Problem

Starting with Drupal 10.2+/11.x, core enforces that an existing default revision cannot be saved as a non-default revision without creating a new revision (see #3499181). This causes an EntityStorageException when saving host
entities (nodes, taxonomy terms, etc.) with composite entities as drafts.

This affects all composite entity types using Entity Reference Revisions, including but not limited to:
- Paragraphs
- Cohesion Layout (Site Studio)
- Any custom composite entity type 

  The error message is:                                                                                                                                                                                                              
  Drupal\Core\Entity\EntityStorageException: An existing default revision of the '[entity_type]' entity type can not be changed to a non-default revision.

Root cause

There are two locations in EntityReferenceRevisionsItem where composite entities are saved, and both need to handle this case:

1. In preSave() (line ~331)

When the composite entity content changes, preSave() saves the entity:

$this->entity->save();

A fix was partially implemented (line ~327) but may not cover all scenarios depending on execution order.

2. In postSave() (line ~405-406) — NOT FIXED

When metadata needs to be updated (parent_id, parent_type, field_name), the code explicitly forces setNewRevision(FALSE): 

  if ($needs_save) {                                                                                                                                                                                                                 
    $entity->setNewRevision(FALSE);  // ← Problem: ignores revision state                                                                                                                                                            
    $entity->save();                                                                                                                                                                                                                 
  }

This causes the exception when:
1. The composite entity was loaded as the default revision (wasDefaultRevision() === TRUE)
2. The host entity is being saved as a non-default revision (draft)
3. The composite entity's isDefaultRevision has been synced to FALSE

Steps to reproduce

1. Create a content type with a composite entity reference field (paragraph, cohesion_layout, etc.)
2. Create and publish a node with a composite entity
3. Edit the node and save as draft
4. Edit again and save as draft → EntityStorageException is thrown

The bug is intermittent because it depends on whether $needs_save is TRUE in postSave(), which happens when parent metadata changes.

Proposed resolution

Apply the same defensive check in both preSave() and postSave(): before saving, check if the entity was a default revision and is becoming non-default. If so, create a new revision instead of forcing setNewRevision(FALSE).

Impact

This bug affects any site using:
- Content Moderation with drafts/workflows
- Any composite entity type (Paragraphs, Cohesion Layout, custom types)
- Drupal 10.2+ or 11.x

Without this fix, editors cannot reliably save drafts on content with composite entities.

CommentFileSizeAuthor
#12 fix_default_revision_sync-3571637-12.patch2.43 KBanton4uk
entity_reference_revisions-fix-default-revision-sync.patch1.78 KBegruel

Issue fork entity_reference_revisions-3571637

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

egruel created an issue. See original summary.

dtfabio’s picture

dtfabio commented
Status: Active » Reviewed & tested by the community

I had to solve this same problem for one of our customers: a page with paragraphs could no longer be saved after editing one of the paragraphs. This problem occurred after rolling out the D11 updates, and the patch in this issue solved the problem.

Core version 11.3.2
PHP version 8.3.27
MySQL version 8.4.5
Entity reference revisions module version 1.13.0

Before applying the patch, the site displays the following message to the user:

"The content could not be saved. Contact the site administrator if the problem persists."

And throws the following error in the logs:

Drupal\Core\Entity\EntityStorageException: An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (regel 815 van /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

trace	
#0 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityBase.php(370): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\paragraphs\Entity\Paragraph))
#1 /var/www/html/web/modules/contrib/entity_reference_revisions/src/Plugin/Field/FieldType/EntityReferenceRevisionsItem.php(317): Drupal\Core\Entity\EntityBase->save()
#2 /var/www/html/web/core/lib/Drupal/Core/Field/FieldItemList.php(237): Drupal\entity_reference_revisions\Plugin\Field\FieldType\EntityReferenceRevisionsItem->preSave()

After adding the patch, the error has disappeared and it is possible to save the node again.

So, as far as I'm concerned, this ticket can be moved to RTBC and hopefully the fix can be included in the module.

yonailo’s picture

yonailo
He/him
commented

I am able to reproduce this issue too.

In my case it is enough to revert to and old revision and trying to make edits afterwards. I've got this in the drupal logs :

Drupal\Core\Entity\EntityStorageException saving node form: An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 815 of /var/www/drupal/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php)

#0 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityBase.php(370): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\paragraphs\Entity\Paragraph))
#1 /var/www/drupal/web/modules/contrib/entity_reference_revisions/src/Plugin/Field/FieldType/EntityReferenceRevisionsItem.php(319): Drupal\Core\Entity\EntityBase->save()
#2 /var/www/drupal/web/core/lib/Drupal/Core/Field/FieldItemList.php(237): Drupal\entity_reference_revisions\Plugin\Field\FieldType\EntityReferenceRevisionsItem->preSave()
#3 /var/www/drupal/web/core/lib/Drupal/Core/Field/FieldItemList.php(195): Drupal\Core\Field\FieldItemList->delegateMethod('preSave')
#4 /var/www/drupal/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(1076): Drupal\Core\Field\FieldItemList->preSave()
#5 /var/www/drupal/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(1026): Drupal\Core\Entity\ContentEntityStorageBase->invokeFieldMethod('preSave', Object(Drupal\node\Entity\Node))
#6 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(568): Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('presave', Object(Drupal\node\Entity\Node))
#7 /var/www/drupal/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(882): Drupal\Core\Entity\EntityStorageBase->doPreSave(Object(Drupal\node\Entity\Node))
#8 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(522): Drupal\Core\Entity\ContentEntityStorageBase->doPreSave(Object(Drupal\node\Entity\Node))
#9 /var/www/drupal/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(804): Drupal\Core\Entity\EntityStorageBase->save(Object(Drupal\node\Entity\Node))
#10 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityBase.php(370): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\node\Entity\Node))
#11 /var/www/drupal/web/core/modules/node/src/Form/NodeForm.php(287): Drupal\Core\Entity\EntityBase->save()
#12 /var/www/drupal/web/core/lib/Drupal/Core/Form/FormSubmitter.php(108): Drupal\node\Form\NodeForm->save(Array, Object(Drupal\Core\Form\FormState))
#13 /var/www/drupal/web/core/lib/Drupal/Core/Form/FormSubmitter.php(45): Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object(Drupal\Core\Form\FormState))
#14 /var/www/drupal/web/core/lib/Drupal/Core/Form/FormBuilder.php(615): Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object(Drupal\Core\Form\FormState))
#15 /var/www/drupal/web/core/lib/Drupal/Core/Form/FormBuilder.php(347): Drupal\Core\Form\FormBuilder->processForm('node_article_ed...', Array, Object(Drupal\Core\Form\FormState))
#16 /var/www/drupal/web/core/lib/Drupal/Core/Controller/FormController.php(73): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\node\Form\NodeForm), Object(Drupal\Core\Form\FormState))
...
uri_frazier’s picture

uri_frazier
he/him
Primary language English
Location Portland, Oregon
commented

EDIT: I can save now, but looks like I need to add an issue for the diff module as changes to entity reference field values are not appearing when trying to "Compare selected revisions"

I ran into the same error, and the patch works great. In my case, it was encountered by doing the following:

  1. On the affected content type, revert to a past revision (content was published, reverted to a past published version).
  2. After reverting, try to save the content with or without any actual changes to the node and any of its paragraphs.

The affected node was still misbehaving, (I would save changes, but they would never persist and it would essentially fail silently) so I needed to save changes in a draft version and then publish in order to get revisions, etc. to work correctly again for that node.

Drupal 11.3.3
PHP: 8.3.30
DB: 10.6.22-MariaDB

uri_frazier’s picture

uri_frazier
he/him
Primary language English
Location Portland, Oregon
commented

I'm having trouble with reverting, it currently doesn't do anything when making changes on an entity reference field.
No error, but changes aren't reverted. No error messages in the logs.

uri_frazier’s picture

uri_frazier
he/him
Primary language English
Location Portland, Oregon
commented
Status: Reviewed & tested by the community » Needs work

I can save, but reverting to a previous revision isn't working or causing any errors to be logged.
My apologies if I incorrectly changed the status on this issue. It may just be Paragraphs specific (?) - I will do more testing and update here if needed.

uri_frazier’s picture

uri_frazier
he/him
Primary language English
Location Portland, Oregon
commented
Status: Needs work » Reviewed & tested by the community

Okay, after some further testing (on a blank/test D11.3.3 site) I found that this patch (entity_reference_revisions-fix-default-revision-sync.patch) is working correctly.

I also found that the error doesn't appear with basic content on a fresh D11 site, but here is how to replicate it:

  • Install core module: content_translation, language
  • Add a paragraphs field (to Basic Page content type for example), and make that field translatable. While there is a warning there that says "Paragraphs fields do not support translation...", when using the paragraphs_asymmetric_translation_widgets module, you DO in fact need to enable this.
  • Add a language via admin/config/regional/language - while I haven't pinpointed the reason why, sometimes the bug/error will not occur if you don't have a second language (e.g. besides English) added to the site
  • Error reproduced by reverting to a past revision, then trying to re-save the node (Basic Page) without making any changes.

Again, using Paragraphs on its own did not cause the error, instead it was only when enabling "Users may translate this field" on the paragraphs field, did the error message appear: "The content could not be saved. Contact the site administrator if the problem persists"

Additionally (again) in order to ensure the error appears, a second language had to be added to the site.

While reverting (the revert feature) still doesn't work for the site I'm trying to fix despite having this patch applied, it does work on a basic D11 test site that doesn't have custom code or other complicated modules running (e.g. paragraphs_asymmetric_translation_widgets).

Setting this back to "Reviewed & tested by the community"

joevagyok made their first commit to this issue’s fork.

joevagyok opened merge request !90

joevagyok’s picture

joevagyok commented

I opened an MR with a test coverage in the first commit that fails. The second commit is with the fix where postSave() change was creating extra revisions during normal parent field metadata updates, which broke the orphan removal test's expected revision counts, especially on Drupal 11.3 where wasDefaultRevision() tracking may have become stricter.

Third commit is passing: the preSave() fix at line 322 remains and is the correct, targeted fix for the bug.

gpietrzak’s picture

gpietrzak
Primary language Polish
Location Wrocław
commented

I checked it in few local scenarios, it works good!

anton4uk’s picture

anton4uk commented
Status: Reviewed & tested by the community » Needs review
StatusFileSize
new fix_default_revision_sync-3571637-12.patch2.43 KB

In some cases, when a new revision is created in this way, the "target_revision_id" needs to be updated. A new revision is created, but "target_revision_id" points to the previous one because $is_affected fired before the new revision was created.
I hope I explained it well, because we have such a problem on one of the projects. Revision is created, but nothing is changed. For more context, paragraphs are translatable, but without draft moderation.

It should be checked how it works with Content Moderation.

flyke’s picture

flyke commented

I have a project where, as admin user, I have no problems unpublishing a node (that contains paragraphs).
However, the client contacted me that when he (logged in with different user role, that does have sufficient permissions) tries to unpublish a node, he gets the error The content could not be saved. Contact the site administrator if the problem persists..

In watchdog, that is the error:
Drupal\Core\Entity\EntityStorageException saving node form: An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 815 of /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php)

At time of writing, MR 90 did NOT fix the issue.

Patch #12 did fix the issue, thanks @anton4uk !

Sidenote, MR146 of inline_entity_form issue #3532374 also did not fix the issue.

djdevin’s picture

djdevin
he/him
Primary language English
Location Philadelphia
commented

Similar to @flyke, project uses Workspaces, LB + Inline blocks + Paragraphs + Inline entity form

#12 fixed, #3532374 did not

edit: LOL - a little more to the story, the issue happens when updating a text field to a value that is current. So the workaround was to enter some garbage and save, then go back and edit again.

So it's not seeing a change in the entity, so it does not create a new revision, but sets the non-default flag.

Specifically with Workspaces but maybe this issue pops up in other circumstances.

gugalamaciek made their first commit to this issue’s fork.

benstallings’s picture

benstallings commented
Status: Needs review » Reviewed & tested by the community

After rebase, Claude Code said,

2 files changed, 3 logical changes. All focused on the issue.

---
1. preSave() — Default-revision demotion guard (lines 320–331)

Assessment: Correct. The three-part condition is precise:
- !isNewRevision() — a new revision wasn't already requested (avoids double-setting)
- wasDefaultRevision() — the entity was loaded as the default
- !isDefaultRevision() — it's now being saved as non-default (synced from host)

The $set_new_revision flag ensures target_revision_id is updated on line 336 even when $is_affected is false. This is necessary because forcing a new revision changes the revision ID regardless of translation-affectedness.

The placement is good — it sits inside the if ($needs_save) block, so it only fires when the entity is actually about to be saved. The comments and @see references are helpful.

---
2. postSave() — Same guard for parent-tracking saves (lines 404–415)

Assessment: Correct. Same Drupal 11 enforcement in the postSave() path, where the entity is saved to update parent tracking fields. Note this guard doesn't need the !isNewRevision() check because the original code unconditionally called setNewRevision(FALSE), so we know a new revision was never requested in this path.

Minor nit: Line 414 has 7-space indentation (·······$entity->setNewRevision(FALSE);) instead of the 8 spaces used everywhere else. Should be fixed for Drupal coding standards.

---
3. Test: testDefaultRevisionDemotionWithNewHost()

Assessment: Well-constructed. The test reproduces the exact scenario:
1. Creates a composite + node (both default revisions)
2. Reloads the composite fresh (so wasDefaultRevision() is true)
3. Marks it non-default with needsSave, places it in a new host composite
4. Saves the node as a non-default (draft) revision
5. Asserts no exception, verifies the new non-default revision exists, and confirms the original default revision is preserved

The nested composite setup (adding nested_composite field) accurately models the real-world trigger where a new container entity causes preSave() to skip the !$host->isNew() block.

---
Summary

  ┌───────────────────────────┬─────────────────────────┐
  │          Change           │         Verdict         │
  ├───────────────────────────┼─────────────────────────┤
  │ preSave() demotion guard  │ Good                    │
  ├───────────────────────────┼─────────────────────────┤
  │ postSave() demotion guard │ Good (minor indent nit) │
  ├───────────────────────────┼─────────────────────────┤
  │ Test                      │ Good                    │
  └───────────────────────────┴─────────────────────────┘

This is a clean, focused fix. The only actionable item is the 1-space indentation discrepancy on line 414. Otherwise this looks ready.

sir_squall’s picture

sir_squall commented

I tested the patch #12 and it's working well! Thanks a lot #anton4uk for that !

benstallings’s picture

benstallings commented

^ I rebased and fixed the indentation; that's all.

emixaam’s picture

emixaam commented

Tested the patch #12 / MR 90 successfully with Drupal 11.3.8, Paragraphs 1.20 and Entity Reference Revisions 1.14. We also have the modules Workflows and Content Moderation enabled with some workflows.

Before applying the patch, we had the error Drupal\Core\Entity\EntityStorageException saving node form: An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() while attempting to save some content/pages.

With the patch, saving and restoring previous revisions now work correctly for our content/pages that had the error.

alphex’s picture

alphex commented

This solved an error i was getting while updating RABBIT_HOLE to its latest version (as of time of this comment), which was reporting 

>  [notice] Update started: rabbit_hole_update_8106
>  [error]  Drupal\Core\Entity\EntityStorageException: An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision. in Drupal\Core\Entity\ContentEntityStorageBase->doPreSave() (line 889 of /app/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php).
>  [error]  Drupal\Core\Entity\EntityStorageException: An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 815 of /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
>  [error]  An existing default revision of the 'paragraph' entity type can not be changed to a non-default revision.
>  [error]  Update failed: rabbit_hole_update_8106

during `drush updb`.