Improve EntityReferenceRevisionsItem::generateSampleValue to be recursion-safe and devel_generate compatible

Here is a patch that adds support for generating sample content for ERR fields.

Thx for proposal!

I can't see a fatal error with most recent Devel, Para and ERR, instead i simply get empty paragraphs fields.
Newly supporting devel generate is more a feature than a bug. :-)

After the patch, i have some nice examples, thus committed.
However, i switched numbers:
- label 1..10 words
- ERR items 1..5
I think those are more representative for standard examples. Dunno how generate intends making those better configurable if needed?

This works nicely with Paragraphs, thus closing the related issue.

Is it common to have generate test coverage? If not, close to fixed.

Using 8.1.0 of this module and 8.1.0 of Paragraphs, without this patch no fatal error occurs when using devel_generate, however as expected no Paragraph field content is generated. I then applied the patch in this thread which didn't work either.

Finally I upgraded to the latest dev which obviously contains the patch and still no Paragraph content is generated so I looked into the code and discovered that the check for reference-able entities stops field content being generated, presumably as those entities don't exist during the content creation.

// Bail if there are no referenceable entities.
if (!$selection_manager->getSelectionHandler($field_definition)->getReferenceableEntities()) {
  return;
}

Removing this block allows devel_generate to generate Paragraph content. I've included a patch that demonstrates this.

Is this meant to only support paragraphs? I get errors when trying to reference other entities. The generate comments also seem to imply that ERR only supports completely contained/embedded entities, rather than a more agnostic approach, which isn't true, isn't how I'm using it, and isn't enforced anywhere else in the code as far as I can see.

// ERR field values are never cross referenced so we need to generate new
// target entities. First, find the target entity type.

Attached patch just defers to core entity reference behavior, and mixes in the revision ID, which is pretty bullet proof, but means it only references existing entities, rather than generating new entities.

Patch #8 worked for me using paragraphs.
Paragraph values are created with random values with devel generate.

Thanks!

Perfect, I can also confirm that #8 fixes the devel_generate problems with paragraphs!
RTBC. Would be nice to have this in the next release!

Whoa this drops a lot of code.
I just committed the "Random" fix in the other related issue.

I was confused there as well:

• With such a rewrite, we should have a well defined case and test cover it.
• And why is all this stuff not needed anymore? (Or why was it needed before?)

@fearlsgroove could you perhaps answer @miro_dietiker's question? It would be nice to have this fix committed, it it's OK.

latest patch #8 resulted in this after generating content:
Undefined index: target_id in /app/docroot/modules/contrib/entity_reference_revisions/src/Plugin/Field/FieldType/EntityReferenceRevisionsItem.php on line 454.

For me the patch in #8 doesn't work anymore. I'm not sure why the test doesn't fail above... for me the function "generateSampleValue" exists twice after patching?!

Well #8 needs a reroll I think but despite the current stable version the code from #8 works without any problems (replaced function manually)

Rerolled patch from #8 against latest dev.

!! WARNING!! Use this with care, see #25 !!

In contrast to the current version this works and doesn't kill devel_generate with a WSOD... RTBC +1

I had this with patch #17 upon 1.6:

Notice : Undefined index: target_id dans Drupal\entity_reference_revisions\Plugin\Field\FieldType\EntityReferenceRevisionsItem::generateSampleValue() (ligne 455 de /var/www/html/web/modules/contrib/entity_reference_revisions/src/Plugin/Field/FieldType/EntityReferenceRevisionsItem.php).
Warning : array_flip(): Can only flip STRING and INTEGER values! dans Drupal\Core\Entity\EntityStorageBase->loadMultiple() (ligne 264 de /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php).
Error: Call to a member function id() on null in Drupal\entity_reference_revisions\Plugin\Field\FieldType\EntityReferenceRevisionsItem::generateSampleValue() (line 457 of modules/contrib/entity_reference_revisions/src/Plugin/Field/FieldType/EntityReferenceRevisionsItem.php).

I'm too busy to debug this right now, I just post it in case it helps.

+1 confirming error in #19. Would love to have this right now!

Fixing incorrect status.

Sounds like that happens when the parent generates a new entity instead of selecting an existing one.

Not quite sure about this, especially with Paragraphs/composites, selecting an existing is the wrong thing to do.

Fixing the WSOD should be trivial, drop the initial check, since we never use an existing one that's completely pointless.

Keeping the tests tag, but maybe just generic ones if we don't have one yet. We can't test that there is no WSOD, the only thing we could test is that this works if there are no existing entities.

HUGE PROBLEM! If used with paragraphs, the generated content uses existing paragraphs which are referenced. If you now delete the generated dummy node, all these referenced paragraphs are also deleted!!

We just lost a lot of content by deleting a dummy content this way. So we need to decide in which case content has to ne cloned and may NOT be referenced!

I did update patch to separate cases
- when there's some paragraphs created, parent method return IDs
- when parent creates hew entity (no paragraphs found)

There's real issue in calling parent method still, so probably parent generator is useless here

$ drush -v genc --types=paranod --kill 5 10
 [status] Deleted 1 nodes.

In EntityTypeManager.php line 150:
                                                               
  [Drupal\Component\Plugin\Exception\PluginNotFoundException]  
  The "fraduvafresonuhanora" entity type does not exist.       
                                                               

Exception trace:
 () at /var/www/html/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php:150
 Drupal\Core\Entity\EntityTypeManager->getDefinition() at /var/www/html/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php:272
 Drupal\Core\Entity\EntityTypeManager->getHandler() at /var/www/html/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php:208
 Drupal\Core\Entity\EntityTypeManager->getStorage() at /var/www/html/web/modules/paragraphs/src/Entity/Paragraph.php:126
 Drupal\paragraphs\Entity\Paragraph->getParentEntity() at /var/www/html/web/modules/paragraphs/src/Entity/Paragraph.php:150
 Drupal\paragraphs\Entity\Paragraph->label() at /var/www/html/web/core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/DefaultSelection.php:353
 Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection->getReferenceableEntities() at /var/www/html/web/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php:298
 Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem::generateSampleValue() at /var/www/html/web/modules/entity_reference_revisions/src/Plugin/Field/FieldType/EntityReferenceRevisionsItem.php:452
 Drupal\entity_reference_revisions\Plugin\Field\FieldType\EntityReferenceRevisionsItem::generateSampleValue() at /var/www/html/web/core/lib/Drupal/Core/Field/FieldItemList.php:253
 Drupal\Core\Field\FieldItemList->generateSampleItems() at /var/www/html/web/modules/devel/devel_generate/src/DevelGenerateBase.php:112
 Drupal\devel_generate\DevelGenerateBase::populateFields() at /var/www/html/web/modules/devel/devel_generate/src/Plugin/DevelGenerate/ContentDevelGenerate.php:473
 Drupal\devel_generate\Plugin\DevelGenerate\ContentDevelGenerate->develGenerateContentAddNode() at /var/www/html/web/modules/devel/devel_generate/src/Plugin/DevelGenerate/ContentDevelGenerate.php:318
 Drupal\devel_generate\Plugin\DevelGenerate\ContentDevelGenerate->generateContent() at /var/www/html/web/modules/devel/devel_generate/src/Plugin/DevelGenerate/ContentDevelGenerate.php:296
 Drupal\devel_generate\Plugin\DevelGenerate\ContentDevelGenerate->generateElements() at /var/www/html/web/modules/devel/devel_generate/src/DevelGenerateBase.php:74
 Drupal\devel_generate\DevelGenerateBase->generate() at /var/www/html/web/modules/devel/devel_generate/src/Commands/DevelGenerateCommands.php:189
 Drupal\devel_generate\Commands\DevelGenerateCommands->generate() at /var/www/html/web/modules/devel/devel_generate/src/Commands/DevelGenerateCommands.php:166
 Drupal\devel_generate\Commands\DevelGenerateCommands->content() at n/a:n/a
 call_user_func_array() at /var/www/html/web/vendor/consolidation/annotated-command/src/CommandProcessor.php:257
 Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback() at /var/www/html/web/vendor/consolidation/annotated-command/src/CommandProcessor.php:212
 Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter() at /var/www/html/web/vendor/consolidation/annotated-command/src/CommandProcessor.php:176
 Consolidation\AnnotatedCommand\CommandProcessor->process() at /var/www/html/web/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:302
 Consolidation\AnnotatedCommand\AnnotatedCommand->execute() at /var/www/html/web/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /var/www/html/web/vendor/symfony/console/Application.php:978
 Symfony\Component\Console\Application->doRunCommand() at /var/www/html/web/vendor/symfony/console/Application.php:255
 Symfony\Component\Console\Application->doRun() at /var/www/html/web/vendor/symfony/console/Application.php:148
 Symfony\Component\Console\Application->run() at /var/www/html/web/vendor/drush/drush/src/Runtime/Runtime.php:118
 Drush\Runtime\Runtime->doRun() at /var/www/html/web/vendor/drush/drush/src/Runtime/Runtime.php:49
 Drush\Runtime\Runtime->run() at /var/www/html/web/vendor/drush/drush/drush.php:72
 require() at /var/www/html/web/vendor/drush/drush/drush:4

@andypost: Thanks a lot! Great to see further progress here.

when there's some paragraphs created, parent method return IDs

Did you consider my previous comment? When deleting a dummy content which links to an existing paragraph, that existing paragraph is also deleted, which is NOT correct and dangerous. Or was this a different bug in the previous patch?

@Anybody it is different, I found that I can't call parent method because it trying to find existing paragraphs - which is wrong (that's why it fails)
Paragraphs are not reusable so code can't reuse parent from entity reference item

Hi here.

After a hard review over the actual code and proposal patches, the only problem with the actual code (without applying any patch) is that the first time that you try to generate content, they are generated but without any paragraph. So the error message that the issue report doesn't appear actually.

So if you have at least one content with one paragraph created then the generator runs well.

About the patches:
#26, #17, #8 We can't use at this moment parent::generateSampleValue($field_definition); because this function generate for all contents the same reference to one only paragraph. maybe it is an issue at core code. (Needs review more in deep)

BTW patch #26 works the case when the paragraph has multi values wrongly because the function /entity_reference_revisions/src/Plugin/DataType/EntityReferenceRevisions.php::setValue doesn't support at this time multi-values. So it generates other problems.

I proposal this patch to solve the current problem: "the first time that you try to generate content they are generated but without any paragraph" that is a reroll for patch #7

@vacho: No, we need to do the opposite. We should never reuse paragraphs and always create new ones.

Exactly @Berdir, this is exactly what we said in #25, #27, #28 and VERY important! Otherwise #25 happens which results in data loss!

@Berdir, @Anybody Yes. Currently and with the patch #29(that solves first time creation) we never reuse paragraphs and always create new ones.

Also see the comment by @hudry in a related issue (similar topic for entity_clone): https://www.drupal.org/project/entity_clone/issues/3050027#comment-13232603

This must not be considered "works as designed": Paragraphs (P) are Entity Reference Revisions (ERR), and contrary to normal Entity References like media an ERR must have exactly one parent. If we don't adhere this role, this will lead to inconsistent data at best (every time a shared P parent is edited, a new revision of the P is also created, all other parents would point to an outdated P version), or unrecoverable data loss at worst (when one parent of a shared P is deleted).

Bumping status to critical due the potential data loss in this scenario.

So perhaps this should become a generally supported scenario with services / helpers in ERR? All these scenarios shouldn't have to reinvent the same wheel...

If Paragraphs is an ERR(Entity Reference Revision) that must not have exactly one parent. We need to program this with exceptions. (Such as @andypost proposal in advance)

I need more information to propose some other solution here. (Please!!)

1. Is paragraph the unique ERR that must not have one parent? which another exist?
2. What is an example of ERR that need to have only one parent? one example.

For this time I research and the problem is that the paragraph entity has some problem that other entities not have. The problem appear at core /core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/DefaultSelection.php at getReferenceableEntities method where the entity can't load this call $this->entityRepository->getTranslationFromContext($entity)->label()

Guess related could help

There are these problems:

1. At core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php::generateSampleValue() function

If there are some referenceable entity => return this reference to the object, but in some cases, it is not required. ie paragraph where is needed always no re-use.
So it is a core issue that we need to report.

2. At core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php::createWithSampleValues() function

The data generated not always is correct for fields: parent_id, parent_type, and parent_field_name and this generate a sql error

 SELECT id, parent_id, parent_type, parent_field_name, default_langcode FROM paragraphs_item_field_data;
1|1|node|field_address|1
2|shotukaphuhushaves|doshobothisliguprupis|traclosutekatreswuthotrevad|0
3|johijurenidostathochiwrubreslacrenathunocheprogihipikukiledrotifrejadiprujitritrostuducespegoprotrashudeshifraswutrahishahonebriprimuhuhathibacrog|diclufrochespapophuswasucli|brabrumon|0

As I see for id=1 the data is correct but for 2,3 isn't correct. It needs more debug to determine if the issue is in core or in Paragraph Entity.

Why is this patch not considered the solution? https://www.drupal.org/project/entity_reference_revisions/issues/2986398...

It's how EntityReferenceItem::generateSampleValue() deals with too many referenceable items.

Updated patch to match limit used in EntityReferenceItem.

Patch #38 doesn't solve the issue with empty paragraph field values.

Patch #29 does that.
I used the latest dev versions of ERR, Paragraph, and Devel Generate modules to check it.
For every generated node it creates a new Paragraph. I didn't notice the use of existing paragraphs for dummy content created by Devel generate.

@Oleksiy. Reviewing the comments the fact that patch #38 not works, is because one of these:

1. Issue in core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php::generateSampleValue()

And/Or because this function generate the content without problems for another entities:
2. An issue in Paragraphs Entity with the generator.

BTW the patch #29 works because not use ...::generateSampleValue() (core function) and let generate the content by a custom code for it.

As I understand the manteiners for this want that the ::generateSampleValue() (core function) works over this.

So we need more work here. (Sniff, sniff)

Patch #29 simply removes useless condition that was checking if some referenceable entities exist.
See no reason to have such condition, as we should create new entities here.

Further code in EntityReferenceRevisionsItem::generateSampleValue() generate stub entity and fill its fields with FieldItemList::generateSampleItems() that call for ::generateSampleValue().

So I don't see any issues here.

@sorlov, sorry. I don't explain all in my comment #40.

The function in EntityReferenceRevisionsItem.php::generateSampleValue() is a custom function into the module entity_reference_revision to generate sample contents for Paragraphs and another "References revisions".

But. the function EntityReferenceRevisionsItem.php::generateSampleValue(), not use the core method parent::generateSampleValue($field_definition); (EntityReferenceItem class is the parent and is into core)
so the code into EntityReferenceRevisionsItem.php::generateSampleValue() reinvent the wheel.

I understand that the tried that @andypost (#28) is fixed this issue using parent::generateSampleValue($field_definition); and the comments that opposite to patch #29, (#30, #31, #33) was related to use the core functionality instead to rewrite this code.

So my posture to fix definitively this issue is to find the issue into core function(parent::generateSampleValue($field_definition)) or into the Paragraph entity.

Although the patch #29 fix the issue, the complete method EntityReferenceRevisionsItem.php::generateSampleValue() reinvent the wheel.

I am trying to implement

$values = parent::generateSampleValue($field_definition);

To get from parent class the paragraphs generated:

Scenario 1: There is no previously created paragraph value

$values contain one paragraph entity at $values['entity'] but it is unusable because this has
parent_id = voslijunikobibehegestudiprathestasliwriwadilikupac. Where it should be an integer key.
parent_type = tratuchuthi Where it should be 'node' or something that exists.

Scenario 2: There are previously created paragraphs value

$values contain a target_id array of valid values. It's fine and runs. however, this only can generate nodes with paragraphs that contain already values created, nothing new.

Code tested at src/Plugin/Field/FieldType/EntityReferenceRevisionsItem.php::generateSampleValue()

$values = parent::generateSampleValue($field_definition);
if (isset($values['entity'])) {
    $entity = $values['entity'];
    $entity->save();
}
else if(isset($values['target_id'])) { // Asume only one paragraph created, needs modify for more than one
    $entity = Paragraph::load($values['target_id']);
}

So definitively to get this feature working with parent::generateSampleValue($field_definition) we need to fix some issues into this core method.

Closed as duplicate of this #3050473: EntityReferenceRevisionsItem::generateSampleValue() may run into recursion

I am reporting here that this issue gets another sub-issue: When we have a big amount of content for one of the CT, then we are not able anymore to see the pages of the displays of the CT.

This part of the code makes this issue (class EntityReferenceRevisionsItem)

if (!$selection_manager->getSelectionHandler($field_definition)->getReferenceableEntities()) {
     return;
}

@andypost re-#44 you meant you closed the other issue as duplicate of this, NOT this one as duplicate? Your comment may perhaps be misunderstood.

This issue is still as Major as ever... when using Layout Builder with entity_reference_revisions it leads to endless loops. Furthermore I guess ERR misses the recursion tracker implemented in Core in #2966137: Circular entity references cause infinite loop in EntityReferenceItem::generateSampleValue() for entity references. Shouldn't we add the same here in generateSampleValue() ?

Anyway #38 seems is missing an interdiff and #29 should be the discussion subject I guess? I'll hide #38 to prevent confusion. @ezeedub please add interdiffs and explain your changes to the previous patch.

Ok now that #3011072: EntityReferenceRevisionsItem::generateSampleValue loads target bundles without respecting negate option is RTBC my recursion problems are gone.

Let's please decide
1. if we have to implement similar recursion tracking logic as in core (#2966137)
2. how to proceed here since #29 as it still seems to be unclear what is really needed as #43 shows?

The patch doesn't apply anymore since #3011072: EntityReferenceRevisionsItem::generateSampleValue loads target bundles without respecting negate option was fixed.

I've not looked into what the previous patches attempt to do since the existing code appears to have changed a bit since they were made.
Only issue I had with this and viewing paragraphs in the layout builder was that there's no recursion limit, so I made a minimal change to just limit the depth to 5, which made it usable.

Whoops, typo...

@TwoD the patches before #50 can't apply and they are no longer needed because the module code currently looks likes patch #29 was applied.

Also the new issue:

This issue is still as Major as ever... when using Layout Builder with entity_reference_revisions it leads to endless loops.

It also no longer occurs because several related issues have been resolved.
likes #46, #48, #49 shows.

So I think they are nothing more to do here.

Just coming back to this issue, and I experience it from a few place. Layout builder still generates and saves lots of dummy paragraphs if you preview content. We are also using Menu Token, and this generates dummy paragraphs (via paragraphs references on a Commerce product) when it asks for the contexts.

Would a better approach be to add a setting on the ERR fields to flag disabling sample values, or clean up when the sample value has been created? We have a database with 65000+ dummy paragraphs in :-(

I happy to spend time writing patches, but wanted to have a little discussion around the right approach first.

It's unclear to me if this is required or not, but I agree that bulk-generation recursive paragraphs on layout builder preview is a problem. The patch also uses an invalid path, so lets at least improve that so tests can run, or better do a merge reuest.

Applied changes in #51 to the MR and hid all the previous patches.
#51 worked for me to prevent errors using ERR with acquia_dam media.

I'm currently experiencing recursion issue with layout builder (building content type full view display).
I have a commerce_product with a layout paragraphs field.
When first attempt to show the layout builder, I enter an infinite loop.

I applied the same recursion_tracker strategy as the core entity reference field type one.
Seems to be much better, no more infinite loop.
So @anybody, totally subscribe to #46.

Also tested MR and this solves the issue in LB.

@twod, is there a reason in #51 to have a limit to 5 instead of Entity Reference recursion_tracker strategy ?

I would suggest to refactor this method.
Actually apart from infinite loop, there is another issue that is problematic :
It actually saves the generated data to the DB. This causes problems because it also triggers save for possible nested references.
It should only create object and set "entity" property like it is done in core EntityReferenceItem class.
I refactored the code and tested this in a node with a paragraphs field and display set up with layout builder. Seems to work.
See MR 71.

@mattlc

I tried your MR as a patch and it fixesmost of the issues (creation of infinite number of entities in the database).

That said, when going to the layout builder preview page, there are a lot of warnings like:

Warning: Undefined variable $parent in Drupal\paragraphs\Entity\Paragraph->getParentEntity() (line 214 of modules/contrib/paragraphs/src/Entity/Paragraph.php).
Warning: unserialize(): Error at offset 0 of 3302 bytes in Drupal\paragraphs\Entity\Paragraph->getAllBehaviorSettings() (line 274 of modules/contrib/paragraphs/src/Entity/Paragraph.php).
No matching provider found.

So it looks like paragraph module is still doing something wrong even with those patches.

Claude Code says:

Assessment: Good direction, but has a few issues.

---
Issue 1: target_id and target_revision_id will be NULL

Since createWithSampleValues() creates an in-memory entity without saving it, $entity->id() and $entity->getRevisionId() will both be NULL. The return value is effectively:

['entity' => $entity, 'target_id' => NULL, 'target_revision_id' => NULL]

Core's EntityReferenceItem::generateSampleValue() only returns ['entity' => $entity] in this code path — no ID fields. The NULL IDs are misleading and could cause issues if any caller checks for non-NULL target_id as an indicator of a valid reference. You should match core and just return:

return ['entity' => $entity];

---
Issue 2: Recursion tracker is never cleared

Core's implementation does:

  $recursion_tracker[$key] = TRUE;
  $values['entity'] = $entity_storage->createWithSampleValues(...);
  unset($recursion_tracker[$key]);  // <-- cleared after success
  return $values;

The new code sets $err_recursion_tracker[$key] = TRUE but never unsets it. Since the tracker is static, it persists for the entire PHP process. This means:

- Multi-value fields: If the field has cardinality > 1, generateSampleItems() calls generateSampleValue() multiple times. The second call will hit the tracker and return []. Only one item will ever be generated.
- Multiple entities: If you generate sample values for two different parent entities in the same request, the second parent's ERR field will get [] for any target type/bundle already generated.

Add unset($err_recursion_tracker[$key]) after successful entity creation, matching core's pattern.

---
Issue 3: Bundle resolution duplicates core's getRandomBundle()

The bundle resolution logic (lines 499–514) handles target_bundles, negate, and fallback to all bundles. Core's EntityReferenceItem::getRandomBundle() is a protected static method that does essentially the same thing (though it doesn't handle negate). Since EntityReferenceRevisionsItem extends EntityReferenceItem, you could call static::getRandomBundle() for the non-negate case — but the negate handling is ERR-specific, so keeping the custom logic is defensible. Minor point.

---

Recommendation: Two fixes needed before this is ready:
1. Add unset($err_recursion_tracker[$key]) after successful createWithSampleValues() call
2. Return ['entity' => $entity] only, dropping the NULL target_id/target_revision_id