Replace \Drupal::entityManager() with \Drupal::service('entity_field.manager') or $this->container->get('entity_field.manager')

+++ b/core/modules/datetime/src/Tests/DateTimeFieldTest.php
@@ -398,7 +398,7 @@ function testDatelistWidget() {
-    \Drupal::entityManager()->clearCachedFieldDefinitions();
+    \Drupal::entityTypeManager()->clearCachedFieldDefinitions();

That method is on the EntityFieldManager, not the EntityTypeManager.

Does this patch catch all of the uses in datetime? Are there any injected uses of the EntityManager service directly?

This will need a proper Issue Summary; I stubbed out the template.

Patch doesn't apply, so can't add interdiff. Reroll + fixes. Passes locally. Did some searches, and think this covers all uses of the EntityManager service.

I verified there are no additional uses of the deprecated entity manager in the datetime module once this patch is applied. I think it's good to go.

I think we have issues around scope here... for example,

+++ b/core/modules/datetime/src/Tests/DateTimeFieldTest.php
@@ -712,7 +712,7 @@ function testDefaultValue() {
-    \Drupal::entityManager()->clearCachedFieldDefinitions();
+    \Drupal::service('entity_field.manager')->clearCachedFieldDefinitions();

We could do a find and replace on the entire code base for this.

See https://www.drupal.org/core/scope for guidelines and examples for Drupal core issue scope.

Had quick chat with @alexpott in IRC. We want to increase the scope of this. Few things to consider for the new scope.

There are a boatload of \Drupal::entityManager() calls in core.

We can do search/replace like in the above, but in a lot of cases it may not be the best thing to do. For example, this issue should probably have done

-   \Drupal::entityManager()->clearCachedFieldDefinitions();
+  $this->container->get('entity_field.manager')->clearCachedFieldDefinitions();

to eliminate the use of \Drupal global. However, there are a lot of place where the \Drupal::entityManager() is used where either the container isn't available, or dependencies aren't injected.

PhpStorm is telling me that \Drupal::entityManager() is used 230 times in *Test.php. These should all be kernel or web tests, where the $this->container is available. In addition, it looks like in tests there are only a handful of usage patterns, so search/replace is a viable option to get most usages. So, I am proposing to rescope this to replace \Drupal::entityManager() with calls to the appropriate service via the container provided by the test.

@mpdonadio I think we should focus on \Drupal::entityManager() with \Drupal::service('entity_field.manager'); (or the best equivalent) is a good scope. We should have an issue per new service.

Issue per service sounds like a good plan.

Search/replaced. Let's see if tests pass.

Should we use \Drupal::entityManager() on Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem rather than mocking the entityManager->getBaseFieldDefinitions() calls twice on Drupal\Tests\views\Unit\EntityViewsDataTest?

This is happening due to two different services calling getBaseFieldDefinitions() (entity.manager and entity_field.manager) on EntityViewsData and EntityReferenceItem classes.

Seems like fixing the tests "properly" would require a lot refactoring on Drupal\views\EntityViewsData and on all the classes extending it.

Patch no longer applies.

Forgot about this, this is a duplicate of #3035953: Add @trigger_error() to deprecated EntityManager->EntityFieldManager methods at this point, which is more up to date.