[Meta] Replace deprecated usage of entity_create with a direct call to the entity type class

Major because we do not want deprecated code in Core as it could be used as example

Not convinced. This resulted in a *huge* amount of major issues. it would be more than enough to just have this meta as major and even that I think is wrong.

From the priority documentation:

replacing code that works with code that is the current best practice, or

That reads kinda weird IMHO, but I think this about replacing deprecated code ( a clarification there would be nice). This is listed under *normal* task.

It might not look like it, but many of us are really trying to not just get rid of the criticals, but also keep the majors at bay (I guess we gave up on the idea of actually getting them significantly down). Seeing a +30 on https://drupalreleasedate.com/ is demotivating for those, also for all the people that spent hours and hours triaging critical issues at the sprints in LA.

So first off, I'm generally in favour of getting rid of entity_create(). That's a very confusing anti-pattern to use everywhere when so much of Drupal is OO. However, I'm a bit worried about forging ahead on these sub-issues when it feels like the parent issue at #2346261: Deprecate entity_create() in favor of a <EntityType>::create($values) or \Drupal::entityManager()->getStorage($entity_type)->create($values) still hasn't reached a decision.

I would agree that code clean-up issues like this can never be "major." The code still works just fine, even if it's uglier to look at. As Berdir mentions, one of the things under definition of "normal task" is "replacing code that works with code that is the current best practice" and that's exactly what we're doing here. That ensures we reserve "major" priority for issues that match its definition, which includes things like "significant repercussions."

So my preference would be to postpone work (and demote to normal) this meta/child issues until the parent issue is settled. Per the core decision-making documentation, this much code refactoring to me qualifies as "significant impact" to the entity / fields subsystem, and so we'd want to make sure we have sign-off from the entity/field API maintainers before proceeding.

@DuaelFr,
Are we going to postpone the sub issues as well as the meta has been postponed ?
Is there any logic behind that are not postponing the sub issues ?

Thanks @DuaelFr and @trwad for all your work on these issues so far. I agree that the invdividual sub-issues should be postponed for now.

Additionally, we should not make this kind of change with one patch per module. It's better to restrict changes to a specific scope instead. See, for example, the work in #2322195: Replace all instances of user_load(), user_load_multiple(), entity_load('user') and entity_load_multiple('user') with static method calls and also these notes on meta scoping. So when we unpostpone them (whenever that is), we should merge them into one patch that only replaces one thing with another thing, without other code changes.

You're *totally* not being an annoyance, don't worry! The priorities are not always straight-forward. And I just want to make sure all the various stakeholders are comfortable with it before going all out. :)

The advantage to postponing the sub-issues is people don't potentially waste effort and we don't accidentally commit one of them without the parent issue being resolved like we did with #2491009: Replace deprecated usage of entity_create with a direct call to the entity type class in Field UI module (which, FWIW, looked absolutely fine to me). But I also acknowledge it's a *ton* of busywork, which would be nice to avoid. An email just went out to the committers tonight alerting them of the need to resolve the parent issue prior to committing further patches, so we should be fine as far as that goes.

Oops. Cross-post! However, 1 patch for the whole whack of them sounds fine to me if it's truly the same pattern repeated over and over across the whole system. Much easier to review/commit that way.

What might make the most sense would be to do one patch per entity type, as was done for the load method. We can probably put together starter patches from the by module issues that were already filed. So about 6-7 large patches rather than dozens of 5K ones. So the existing issues could be marked as duplicates of those larger patches (and applied together in many cases to create them). However, let's wait for #2346261: Deprecate entity_create() in favor of a <EntityType>::create($values) or \Drupal::entityManager()->getStorage($entity_type)->create($values) before starting that.

Also note that, in general, removing usage of code that's deprecated for 9.0 isn't a prioritized change for the beta phase -- just code that was deprecated for 8.0.0 before the beta. However, in the case of this it's horribly inconsistent with the rest of the entity API, so I am in favor of completing the code removals if #2346261: Deprecate entity_create() in favor of a <EntityType>::create($values) or \Drupal::entityManager()->getStorage($entity_type)->create($values) goes in.

I'm postponing the previously RTBC issues, at least. It'd be appreciated if the others could be postponed as well so that Novice contributors don't invest effort in them when they won't be accepted currently. Thanks!

As per the above #22, AFAIU,we also need to open another follow up issue that will replace deprecated usage of entity_create('comment',..... with Comment Entity Class create static function i.e. Comment::create() Are we going to proceed with it like this ? Are we approaching the right way ?
For any guidance, thanks in advance. :)

Wow, I should have read this first before my comment in #2503379-19: Replace deprecated usage of entity_create('filter_format') with a direct call to FilterFormat::create(). Actually, that's a good lesson for me.

@DuaelFr Nice work on getting rid of these deprecated usages. I'd like to triage this issue and consider whether it is suitable for the beta phase:

• It is not an "unfrozen" change.
• Is it a prioritized change? I think it is not. The function is marked as deprecated and it will be removed before Drupal 9, not Drupal 8.0. Usages in core can be removed later.
• Is it disruptive? It "will require changes across many subsystems and patches in order to make core consistent". With this patch applied there are more than 300 files using entity_create() in core. Many other issues may have conflicts with this one.

I updated the beta evaluation accordingly. Ultimately, the scale of this change in terms of the amount of files affected suggests to me that it should be postponed to 8.1.x. If it were only a handful of files in an isolated system, things would be different. The beta phase rules are not only intended to increase stability, they are also for focusing the attention of contributors and committers on issues that put Drupal 8 in a releaseable state.

I changed its beta eval to:

Beta phase evaluation

Dang. Thanks so much for pushing on this, DuaelFr. Definitely looking forward to seeing you back working on this in 8.1.x. :D

Reopening, as we are also working at branch 8.1.x now

Marking some items with no occurrences

Just wanted to say: yay for consistency!

@Wim Leers regarding consistency, we had some discussion about how to create the entities for this meta, but we could not reach a consensus. Some core developers are in favor of using Dependency Injector in tests, others prefer to not use it in favor of DX. See #2644752: [policy] Decide how to create/load entities in procedural code and test classes

There doesn't seem to be a child issue for entity_create('entity_test'). Also, maintainers want to consolidate the remaining entity_test issues: #2641544-9: Replace deprecated usage of entity_create('entity_test_rev') with a direct call to EntityTestRev::create()

So I combined those two things here: #2669400: Replace deprecated usages of entity_create('type') with a direct call to <EntityType>::create() which serves as a catch-all for the remaining usages of entity_create() with a string constant.

Updating with links to issues.

Just added #2669926: Replace deprecated usage of entity_create('taxonomy*') with a direct call to Vocabulary::create()

The last child issue is ready #2641518: Replace deprecated usage of entity_create('config_test') with a direct call to ConfigTest::create()

but there's still 12-15 mentions

$ git grep " entity_create("
core/includes/entity.inc:308:function entity_create($entity_type, array $values = []) {
core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php:90:   * @see entity_create()
core/modules/block_content/src/Tests/Views/BlockContentTestBase.php:61:   *   used in entity_create().
core/modules/block_content/tests/src/Functional/Views/BlockContentTestBase.php:56:   *   used in entity_create().
core/modules/content_translation/tests/src/Functional/ContentTranslationSyncImageTest.php:128:    $entity = entity_create($this->entityTypeId, $values);
core/modules/field/src/Entity/FieldConfig.php:87:   * @see entity_create()
core/modules/field/src/Entity/FieldStorageConfig.php:241:   * @see entity_create()
core/modules/field/src/Tests/reEnableModuleFieldTest.php:98:    $field_storage2 = entity_create('field_storage_config', [
core/modules/field/tests/src/Functional/EntityReference/EntityReferenceFieldTranslatedReferenceViewTest.php:287:    $node = entity_create($this->testEntityTypeName, [
core/modules/field/tests/src/Functional/EntityReference/EntityReferenceFieldTranslatedReferenceViewTest.php:311:    $node = entity_create($this->testEntityTypeName, [
core/modules/field/tests/src/Functional/EntityReference/EntityReferenceFieldTranslatedReferenceViewTest.php:330:    $node = entity_create($this->testEntityTypeName, [
core/modules/field/tests/src/Kernel/EntityReference/EntityReferenceFormatterTest.php:248:    $referencing_entity_1 = entity_create($this->entityType, ['name' => $this->randomMachineName()]);
core/modules/field/tests/src/Kernel/EntityReference/EntityReferenceFormatterTest.php:271:    $referencing_entity_2 = entity_create($this->entityType, ['name' => $this->randomMachineName()]);
core/modules/field/tests/src/Kernel/FieldAttachOtherTest.php:250:    $entity = entity_create($entity_type, ['id' => 1, 'revision_id' => 1, 'type' => $this->fieldTestData->field->getTargetBundle()]);
core/modules/field/tests/src/Kernel/FieldValidationTest.php:37:    $this->entity = entity_create($this->entityType, [
core/modules/field/tests/src/Kernel/TranslationTest.php:181:      $entity = entity_create($entity_type_id, $values);
core/modules/hal/src/Normalizer/ContentEntityNormalizer.php:100:   *   Unused, entity_create() is used to instantiate entity objects.
core/modules/language/src/Entity/ContentLanguageSettings.php:76:   * @see entity_create()
core/modules/node/tests/src/Traits/NodeCreationTrait.php:44:   *   entity_create(). Override the defaults by specifying the key and value
core/modules/user/tests/src/Traits/UserCreationTrait.php:92:   *   (optional) The weight for the role. Defaults NULL so that entity_create()
core/modules/user/tests/src/Traits/UserCreationTrait.php:119:   *   (optional) The weight for the role. Defaults NULL so that entity_create()
core/scripts/generate-d7-content.sh:143:    $term = entity_create('taxonomy_term', array(
core/tests/Drupal/KernelTests/Core/Entity/EntityApiTest.php:110:    $entity = entity_create($entity_type, ['name' => 'test', 'user_id' => $user1->id()]);
core/tests/Drupal/KernelTests/Core/Entity/EntityApiTest.php:113:    $entity = entity_create($entity_type, ['name' => 'test2', 'user_id' => $user1->id()]);
core/tests/Drupal/KernelTests/Core/Entity/EntityReferenceFieldTest.php:111:    $referenced_entity = entity_create($this->referencedEntityType, ['type' => 'non_referenceable']);
core/tests/Drupal/KernelTests/Core/Entity/EntityRevisionTranslationTest.php:170:      $entity = entity_create($entity_type, [

Yep, I think we need two more child issues, one that replaces stray documentation references to entity_create(), and another that replaces calls that use a generic entity type (which can easily be converted to use the entity type manager).

I've created new child issue for replacing all remain occurrences and edited summary.

I've created new child issue for replacing stray documentation references to entity_create()

I think it's fixed because the last issue left #2928930: Properly deprecate entity_create() and remove all occurrences and I closed as duplicate #2932317: Replace stray documentation references to entity_create() of it