Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 293902

Configuration schema & required values: add test coverage for `nullable: true` validation support

$
0
0

Problem/Motivation

Quoting @bircher, maintainer of https://www.drupal.org/project/config_split, https://www.drupal.org/project/config_filter, etc., after I asked him What concrete things have gone wrong due to bugs in configuration, especially if they were caused by overriding/splitting/… — any of the advanced Configuration Management things?

what can go wrong, well sorting mostly... oh and to know if a key is required or not. So sometimes when a value is null or the array empty we can omit the key and sometimes not

👉 This issue aims to address the "sometimes when a value is null or the array empty" part. See #3364108: Configuration schema & required keys for the other part.

The following things in Drupal core's config schema are using nullable: true:

  1. entity_reference_selection.default:target_bundles (which is type: sequence) since #1978714: Entity reference doesn't update its field settings when referenced entity bundles are deleted in 2015
  2. editor.editor.*:image_upload.max_dimensions.width and editor.editor.*:image_upload.max_dimensions.height (both of which are type: integer) since #2644838: Add test coverage for the editor's max dimension setting, and fix its message when one dimension is unrestricted in 2016
  3. views.display.page:use_admin_theme (which is type: boolean) since #2719797: New option for Views page displays to use the admin theme in 2023.

It's that first one that introduced nullable: true support in the first place. It also added this to \Drupal\Core\Config\Schema\SchemaCheckTrait::checkValue():

      // Array elements can also opt-in for allowing a NULL value.
      elseif ($element instanceof ArrayElement && $element->isNullable() && $value === NULL) {
        $success = TRUE;
      }

\Drupal\Core\Config\Schema\SchemaCheckTrait::checkValue() already allowed NULL on all primitive types (integer, string, etc.).

However, despite the presence of

    // Add the NotNull constraint for required data.
    if ($definition->isRequired()) {
      $constraints['NotNull'] = [];
    }

in \Drupal\Core\TypedData\TypedDataManager::getDefaultConstraints(), no validation constraint violations are generated when calling

$typed_config->createFromNameAndData($config_name, $config_data)
  ->validate()

This would enable modules like https://www.drupal.org/project/config_split, https://www.drupal.org/project/config_filter et cetera to work more reliably.

Steps to reproduce

See included test coverage.

Proposed resolution

  1. Whenever nullable: true is present, make \Drupal\Core\Config\TypedConfigManager::buildDataDefinition() mark the built data definition as optional
  2. Add test coverage to prove that when nullable: true is present, setting a value of NULL is considered valid, for all data types. And if it's not set, a value of NULL should trigger a validation error.
  3. Initially only do this for config_test.* configuration, to first get the infrastructure in place. This is only one of many child issues of #3361423: Make config schema checking something that can be ignored when testing against older core branches.

This has zero effect on the rest of Drupal core, nor on contrib.

Remaining tasks

Review.

User interface changes

None.

API changes

None. The actual API changes would happen in #3361423: Make config schema checking something that can be ignored when testing against older core branches.

Data model changes

None.

Release notes snippet

N/A


Viewing all articles
Browse latest Browse all 293902

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>