Bundle attribute with compiler pass
Closes #3301682
Merge request reports
Activity
- Resolved by Michael Strelan
- Resolved by Michael Strelan
20 * 21 * @var array<class-string, array{'entityTypeId': string, 'bundle': string|null, 'label': \Drupal\Core\StringTranslation\TranslatableMarkup|null}> 22 */ 23 protected array $bundleClasses = []; 24 25 /** 26 * {@inheritdoc} 27 */ 28 public function process(ContainerBuilder $container): void { 29 // @todo should we limit this to modules/profiles? 30 $namespaces = $container->getParameter('container.namespaces'); 31 foreach ($namespaces as $namespace => $directory) { 32 if (!file_exists($directory . '/Entity')) { 33 continue; 34 } 35 $this->collectBundleClasses($directory . '/Entity', $namespace, $directory); - Comment on lines +32 to +35
The
Entity
namespace is already used for entity type (plugin) discovery, and one thing that has come up is that non-plugin files in plugin directories has affects discovery performance negatively, because all the files need to be iterated, and reflected, and stored in file cache even if they are not relevant. Making bundles discoverable in the same namespace kind of doubles the issue, because entity type discovery will have to deal with the bundle files, and bundle discovery will have to deal with the entity files. Maybe the namespace could beBundle
orEntityBundle
?Meta issue for plugin discovery: https://www.drupal.org/project/drupal/issues/3490484
Right, the idea in https://www.drupal.org/project/drupal/issues/3490484 is to move non-plugin classes out of the plugin directories.
107 109 $this->bundleInfo[$type][$type]['label'] = $entity_type->getLabel(); 108 110 } 109 111 } 112 113 // Bundle classes. 114 foreach ($this->bundleClasses as $class => $info) { At first I was only going to set the class if the bundle already existed in
$this->bundleInfo
, but when stepping through\Drupal\KernelTests\Core\Entity\BundleClassTest::testEntitySubclass
I found the bundles created in the test method didn't appear. Not sure what to make of that. FWIW this would be the same as if someone implementedhook_entity_bundle_info_alter
and set some bogus values.FWIW this would be the same as if someone implemented
hook_entity_bundle_info_alter
and set some bogus values.Yeah, that's why I was wondering if there's already validation (or ignoring bad values) some point after the bundle info is returned from the method.
Edited by godotislate