I think this needs to be allow TranslatableMarkup
. For example in \Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver::getDerivativeDefinitions
we get labels from \Drupal\Core\Entity\EntityTypeRepository::getEntityTypeLabels
which ultimately gets labels from \Drupal\Core\Entity\EntityTypeInterface::getLabel
which returns string|\Drupal\Core\StringTranslation\TranslatableMarkup
. We then pass those labels to \Drupal\Core\Plugin\Context\ContextDefinition::setLabel
which implements this method.
There are probably many other instances of this that we won't know until the concrete classes declare the same parameter types.
Sites that see no benefit from container dumping are likely not using http requests for testing (i.e. drupalGet()).
While we advocate for minimising http requests we still have many http requests in practice, both GET and POST. In my testing I initially found significant performance improvements running a test locally with a data provider, but overall in CI there was no improvement. I suspect there is something else in play here.
It would be good to also declare union types if they are scalar. The only reason I limited this to scalar values for now is that it couldn't handle typed arrays or callables without introducing syntax errors. With a bit of twiddling we could probably progress this further.
Closes #3436327
Michael Strelan (89bfdaec) at 27 Mar 04:33
Apply rector
Closes #3436327
I'd be inclined to make this available on the enum with an asOptions
or toOptions
function, in case it needs to be reused on some other form.
We can probably just call ->value
once:
if ($config->get('translation.overwrite_not_customized') == FALSE) {
$default = TranslationOverrideType::None;
}
elseif ($config->get('translation.overwrite_customized') == TRUE) {
$default = TranslationOverrideType::All;
}
else {
$default = TranslationOverrideType::NonCustomized;
}
$form['overwrite'] = [
'#type' => 'radios',
'#title' => $this->t('Import behavior'),
'#default_value' => $default->value,
I think probably we're not setting this property, we're setting the value in the info array created from this class. If that's true then it could stay read only. In fact I think most of these attribute classes could be read only classes once we're on PHP 8.2+
POC for enum as alternative for #3432889
Michael Strelan (0adab134) at 25 Mar 22:42
Enum poc
Michael Strelan (725e188d) at 25 Mar 22:21
BC for 10.2
I feel like this lookup should be an access check on the form, it feels awkward throwing a 404 from the title callback.