EntityReferenceItem::generateSampleValue() should create a sample entity if a referenceable entity is not found

I think this makes sense. Also good catch on the recursion problem, I wouldn't have thought of that!

I think we should fetch the handler and check the target_bundles setting, if it exists, to fetch a valid bundle.

This looks super sensible and jives with things I had to do with user timezone when we introduced the sample entity generation utilities to core.

RTBC.

Eclipse

@tim.plunkett walked me through this patch this afternoon. It's a soft-blocker to the Layout Builder, since under the right circumstances you can trigger the bug that's being fixed here via the auto-generated preview stuff.

The basic logic here is handling the fallthrough case where there isn't existing referenceable content to randomize, which would normally return NULL, causing issues up the chain. Here we add code to generate a new entity from scratch if we can't find one to reference (e.g. on a blank, brand new site).

This one bug fix uncovered lots of tasty other morsels elsewhere in the code, which the patch proceeds to clean up.

The one eyebrow-raising thing for me was the addition of +class StatusItem extends BooleanItem { in User module. Tim explained that this was added because we most likely do not want purely random 1s or 0s, but instead to create non-blocked users, which makes sense to me. This is also consistent with the approach @EclipseGc mentions in #10 with how time zones were handled.

There's an issue at #2936864: Discuss adding a 'status' field type that could be used in place of 'boolean' that discusses if/whether we want to move this "up" a level to that of other primary field types, but there are some UI considerations there, and if we do decide to do that, we'll likely have to mirror the approach with time zones at that time as well.

So TL;DR, this fixes a bug, fixes various test coverage that was working around the bug, and helps make user-generation more sane going forward. Sweet! :)

Committed and pushed to 8.6.x, cherry-picked to 8.5.x. Thanks!

Looks like this broke HEAD on PHP 5.x:
https://www.drupal.org/pift-ci-job/860681
https://www.drupal.org/pift-ci-job/860721

Drupal\Tests\field\Kernel\EntityReference\EntityReferenceItemTest::testContentEntityReferenceItem
PHPUnit_Framework_Exception: PHP Fatal error:  Call to undefined function \Drupal\Core\Field\Plugin\Field\FieldType\LanguageItem::getAllowedLanguageCodes() in /var/www/html/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/LanguageItem.php on line 128
Fatal error: Call to undefined function \Drupal\Core\Field\Plugin\Field\FieldType\LanguageItem::getAllowedLanguageCodes() in /var/www/html/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/LanguageItem.php on line 128

Ok great, thanks for the quick turnaround. Got that one in too.

Committed and pushed to 8.5.x/8.6.x.

Contrary to the commit message this was only committed to 8.5 (straight). Found while reviewing my own commit mistakes ;)

Hm, when I tried to push my commits, this commit came up. (After I freshly pulled this branch right before). Not sure what happened there, but Angie did put this in 8.6 too.

Specifically, if generating a comment entity, it must create a parent entity or there will be fatal errors in CommentAccessControlHandler, CommentDefaultFormatter, etc.

This reminds me of #2430669: Cannot create comments from REST - field access is too strict and #2631774: Impossible to update Comment entity with REST (HTTP PATCH): bundle field not allowed to be updated, but EntityNormalizer::denormalize() requires it :)