Issue #3616749: Drupal 12 compatibility: the RouteProvider constructor arguments and the shape of submitted domain field values

Fixes two breakages that core changes on the development branch introduced this week. Both are visible in phpunit (next major).

The RouteProvider constructor. DomainSourceRouterProviderTest built DomainSourceRouteProvider positionally and passed 'router' as argument seven. Drupal 11.4 inserted $fast_cache ahead of $table (#3503843) and kept a BC branch that recognised a string there; #3614493 removed it, so the string reached a typed CacheBackendInterface parameter:

TypeError: Drupal\Core\Routing\RouteProvider::__construct(): Argument #7 ($fastCache) must be of type Drupal\Core\Cache\CacheBackendInterface, string given

The mocked fast cache now takes the seventh argument, the table name the eighth and the language manager the ninth. Supplying a real backend also takes the constructor off its deprecated path, so the container the test primed with cache.routes and the ContainerBuilder import are gone. Runtime is unaffected: domain_source.route_provider is declared parent: router.route_provider.

The shape of submitted options widget values. #2171395 moved the options widget transposition out of validateElement() into massageFormValues(), which core calls when it builds the entity. $form_state values therefore stay in widget shape through validation and submit handlers, where they used to arrive as [delta => ['target_id' => id]].

DomainElementManager::submitEntityForm() appended the disallowed domains as ['target_id' => id] onto those values, producing a mixed array; core then wrapped a whole array as a target_id and the POST fatalled with InvalidArgumentException: Value is not a valid entity (HTTP 500). DomainSourceFormHooks::formValidate() compared the source domain against the access selections while handling only two shapes, so a valid selection was rejected with "The source domain must be selected as a publishing option", and the node was never created.

DomainElementManager::getSubmittedFieldValues() now asks the widget: it takes the widget off the form display in the form state and calls massageFormValues(), which is the method #2171395 moved this logic into. Nothing about the widget's shapes is repeated here, so the autocomplete widget is handled as correctly as the options ones, and a further core change to the shape needs no change here. On 11.4 OptionsWidgetBase has no massageFormValues(), so WidgetBase returns the already transposed values unchanged; on the development branch the widget transposes them. Both handlers go through it, the validate handler loses its two-shape branching and its @phpstan-ignore comment, and DomainElementManagerInterface gains the method.

The validate handler also no longer names DomainAccessManagerInterface before checking that domain_access is installed. domain_source does not depend on domain_access, so resolving that class constant first fatalled wherever domain_access is absent.

Verification, on core 11.4.4 (PHP 8.4.15, PHPUnit 11.5.56):

• DomainSourceRouterProviderTest: OK, 2 tests.
• The whole domain_source functional directory, 14 classes, plus the four affected domain and domain_access classes: DomainAdminElementTest, DomainReferencesTest, DomainAccessElementTest, DomainAccessLanguageSaveTest, DomainAccessDefaultValueTest. All green.
• phpcs with the Drupal standard: clean over the repository, 440 files.

The Drupal 12 side is only reachable in CI, so the next-major lane is the check there.

Not for 3.x or 3.0.x: they support Drupal 10.2 and 11, where the current code is correct.