Added EntityArgument and EntityReferenceArgument Views argument plugins

There are two new Views argument plugins (which provide the "Contextual filter" functionality in the Views UI):

1. Drupal\views\Plugin\views\argument\EntityArgument (ID: entity_id)
2. Drupal\views\Plugin\views\argument\EntityReferenceArgument (ID: entity_target_id)

EntityArgument

All argument plugins provided by Drupal core that deal with an entity (node, taxonomy_term, etc) now extend the EntityArgument base class so that they all provide the same functionality:

• core/modules/file/src/Plugin/views/argument/Fid.php
• core/modules/node/src/Plugin/views/argument/Nid.php
• core/modules/taxonomy/src/Plugin/views/argument/Taxonomy.php
• core/modules/taxonomy/src/Plugin/views/argument/VocabularyVid.php
• core/modules/user/src/Plugin/views/argument/Uid.php

Each of these plugins had their own constructors (most of which took some variation of a Drupal\Core\Entity\EntityStorageInterface as the 4th parameter. They had their own property to store this storage "service". The replacement plugins support all of the old constructor parameters but throw deprecation notices if the legacy arguments are passed:

Passing either \Drupal\Core\Entity\EntityStorageInterface or \Drupal\Core\Entity\EntityTypeManagerInterface to Drupal\views\Plugin\views\argument\EntityArgument::__construct() as argument 4 is deprecated in drupal:10.3.0 and will be removed before drupal:11.0.0. Pass a Drupal\Core\Entity\EntityRepositoryInterface instead. See https://www.drupal.org/node/3441945

If there's no 5th parameter, another deprecation is thrown:

Not passing the \Drupal\Core\Entity\EntityTypeManagerInterface to Drupal\views\Plugin\views\argument\EntityArgument::__construct() as argument 5 is deprecated in drupal:10.3.0 and will be required before drupal:11.0.0. See https://www.drupal.org/node/3441945

The correct way to create any entity-based argument plugin is to pass:

    array $configuration,
    $plugin_id,
    $plugin_definition,
    EntityRepositoryInterface $entityRepository,
    EntityTypeManagerInterface $entityTypeManager,

If a class that extends one of these Core entity-specific plugins tries to access the storage property, another deprecation is thrown. For example, something extending Drupal\taxonomy\Plugin\views\argument\Taxonomy that tried to access $this->termStorage would work, but would throw this deprecation:

The property termStorage (taxonomy_term storage service) is deprecated in Drupal\taxonomy_test\Plugin\views\argument\TaxonomyViewsArgumentTest and will be removed before Drupal 11.0.0. See https://www.drupal.org/node/3441945

If you need the taxonomy_term storage, you should use $this->entityTypeManager->getStorage('taxonomy_term') instead.

EntityReferenceArgument

Views arguments that involve an entity reference now use the EntityReferenceArgument plugin, which ensures that the title replacement tokens work when using the argument to change the title of a Views display.

The views_post_update_views_data_argument_plugin_id() method goes through existing Views on the site that are configured to use a numeric argument plugin that points to an entity_target_id property and updates them to use the new EntityReferenceArgument plugin and set the target_entity_type_id option correctly.

There should be no other changes needed for sites that upgrade. Any site that extends any of the argument plugins mentioned above should continue to work. However, be advised that the class hierarchy is now different.

Note on backwards compatibility

Due to a bug in Views that is only being fixed in 11.2.0 core (see #3458099: Views handler loading should respect configuration), the plugin IDs in exported views.view.*.yml files are actually ignored. So it is completely safe for modules that provide default Views to update the plugin definitions and still remain compatible and function properly with versions of Core before 10.3.0. The updated plugin IDs will be ignored in earlier versions of core. Starting in 10.3.0 core, the new plugins will be used since they are determined by the Views Data API, regardless of the IDs in exported Views configuration files. Only starting in 11.2.0 core will the plugin IDs in the exported Views be honored. So it is recommended to update all the exported Views configuration files immediately, even for modules that are still compatible with older versions of core, since there's no harm and only benefit from being ready to move to 11.2.0 and above.

However, once you make this change, if you have tests that run against 10.2.x and earlier versions of core, you'll need to set $strictConfigSchema = FALSE for those tests. Otherwise, the test runs will fail with exceptions about the config schema not being valid. These failures are "safe" in terms of the behavior of the views. They only indicate that the view is using configuration that isn't strictly accurate relative to the defined schema (since in 10.2.x and earlier, there's no config schema defined for the new plugins). But due to the aforementioned bug #3458099, the "invalid" config schema is actually ignored during runtime. The "problem" only appears during automated testing.