The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
The __construct() method of 'FieldItemBase' needs an instance of 'DataDefinitionInterface':
By the documentation:
/**
* Constructs a TypedData object given its definition and context.
*
* @param \Drupal\Core\TypedData\DataDefinitionInterface $definition
* The data definition.
And by the argument list:
/**
* {@inheritdoc}
*/
public function __construct(DataDefinitionInterface $definition, $name = NULL, TypedDataInterface $parent = NULL) {
parent::__construct($definition, $name, $parent);
// Initialize computed properties by default, such that they get cloned
// with the whole item.
foreach ($this->definition->getPropertyDefinitions() as $name => $definition) {
if ($definition->isComputed()) {
$this->properties[$name] = \Drupal::typedDataManager()->getPropertyInstance($this, $name);
}
}
}
But for preparing the properties of computed values it calls a method, 'getPropertyDefinitions()' which aren't defined by the 'DataDefinitionInterface' but defined by 'ComplexDataDefinitionInterface'. Currently it doesn't cause any problem since only ComplexDataDefinitions are used by the Drupal core.
Proposed resolution
If only ComplexDataDefinitions should be used here the documentation and the $definition argument type should be updated.
Otherwise we should find a solution to handle simple DataDefinitions.
('DataDefinitionInterface' also has the 'isComputed()' method which should be called later.)
Issue fork drupal-2226811
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #9
catchThis is still valid, we should change the type hint of the constructor here. BC isn't really a concern because if someone wasn't implementing the interface, we'd get a fatal error here anyway - possibly an extreme edge case where the interface isn't implemented but the method is.
Comment #11
mohit_aghera commentedComment #13
mohit_aghera commentedComment #14
guilhermevp commentedI guess this is simple enough, updated use statement and construct.
Comment #15
effulgentsia commentedComment #17
effulgentsia commentedThanks for the fix. Pushed to 9.3.x.
At first, I was surprised that narrowing the parameter type from the parent method didn't fail tests, since that violates Liskov variance rules, but fortunately, constructors are exempt from that.