New config schema data type: weight

I have been looking a little bit more on the topic, and i found a configuration attribute system.site.weight_select_max. This is set to 100 by default on site install ( see core/modules/system/config/install/system.site.yml ).

One option to make this data type validatable, would be having a callback to check the value of system.site.weight_select_max, and sets Range constraints for min: -VALUE, max: VALUE.

This does not seem to be respected by core.extensions.yml, which sets a value of 1000 for the install profile used.

I see three possible ways to deal with this:

• Change system.site.weight_select_max to have a value of 1000, then the core.extensions would be valid
• Change the site install behaviour, to add the install profile with a weight value of 100
• Keep the core.extension weights as type integer, and leave it as an exception.

Was fixed in 📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed

Shouldn't the range constraints of PHP_MIN_INT and PHP_MAX_INT be defined in the integer type ?

We might then try to validate the configuration using the configuration value "system.site.weight_select_max", but i am not sure if this is possible... aside from having an adequate constraint plugin, it might require to add system.site to as a dependency to all of the configuration objects that uses type: weight

Thanks for looking at this.

The current issue title suggests this is a duplicate of 📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed as @borisson_ said.

#4: That'd be a BC break, because 64-bit PHP has different ranges. If we change type: integer retroactively, we might end up breaking existing config.
That being said: it'd be great to add validation constraints to type: integer! Updated the issue title accordingly.

Then it's not a duplicate!

But the issue summary is still asking for duplicate work that's already been done, as @borisson_ pointed out.

Can you update the issue summary per the proposal you outlined in #4? 🙏

it might require to add system.site to as a dependency to all of the configuration objects that uses type: weight

Huh? 🤔

I found something interesting experimenting around:

I added a value to a configuration value of type weight ( in this example user.role.authenticated.weight ), bigger thant the PHP_INT_MAX value for 64 bit ( 922337203685477580722 ). The PHP_INT_MAX for 64 bit is 9223372036854775807.
Imported the configuration via drush cim ( it did not show any error ).
Export the configuration via drush cex.

Then i saw that the integer value that was exported, was set to the PHP_INT_MAX for 64 bits ( 9223372036854775807 ).

So, isn't the configuration validation suposed to throw an error when importing invalid configuration ?
Also, if this is confirmed, the imported value should not be modified after the import, so if the value is bigger that the PHP_INT_MAX value for that machine, the configuration should not be valid. In that case, i guess the validation should be implemented in a callback so the specific PHP_INT_MAX/MIN values for that php can be validated.

PD: I tried this in Drupal 11.0.5, i will try to replicate this using the drupal dev branch.

Should this be re-scoped based on above or new ticket opened.

It should be rescoped based on #5, yes.

I have managed to create a constraint, that is based on the Range one, and defines the min and max values using the php constants PHP_INT_MIN and PHP_INT_MIN. I've validated that the constraint is applied to the configuration value ( using automated_cron.settings interval attribute ), but i don't seem to manage to trigger the validate method for the constraint on configuration import.

Awesome!

Few things, codestyle is failing right now, would be nice to get test runs :)

Also; perhaps what we do with the message in Drupal\Core\Validation\Plugin\Validation\Constraint\Range is relevant.

In regard to testing, you can use config_test module perhaps? I used that in ✨ Make the `field_config_base` structure fully validatable Active to test if config triggers an error and seems like an easy way to add a test.

<?php

declare(strict_types=1);

namespace Drupal\KernelTests\Core\Validation;

use Drupal\KernelTests\KernelTestBase;
use PHPUnit\Framework\Attributes\Group;

/**
 * Tests the UriHost validator.
 */
#[Group('Validation')]
class StringPartsConstraintValidatorTest extends KernelTestBase {

  /**
   * {@inheritdoc}
   */
  protected static $modules = ['config_test'];

  /**
   * {@inheritdoc}
   */
  protected function setUp(): void {
    parent::setUp();

    $this->installConfig('config_test');
  }

  /**
   * @see \Drupal\Core\Validation\Plugin\Validation\Constraint\UriHostConstraint
   */
  public function testUriHost(): void {
    $typed_config_manager = \Drupal::service('config.typed');
    /** @var \Drupal\Core\Config\Schema\TypedConfigInterface $typed_config */
    $typed_config = $typed_config_manager->get('config_test.validation');

    // Test valid names.
    $typed_config->get('string_parts')->setValue('localhost.llama');
    $this->assertCount(0, $typed_config->validate());

    // Test invalid names.
    $typed_config->get('string_parts')->setValue('drupal.kitten');
    $this->assertCount(1, $typed_config->validate());

  }

}

Hi @bbrala. Thanks for the test code and the suggestions !

The main issue is that i have not found a way to validate this manually, apparently the constraint is applied to the configuration ( at least according to config_inspector ), but when i modify the configuration yml to an invalid value and try to import it, it does not throw any validation error, so i guess there is something i am still missing to make it work.

Later i plan on fixing the code style issues and writting tests.

I dont fully remember how it works for config import right now. The test would set the value and validate in config save, which should trigger. What could be happening also is when your config has something higher than max int it get clipped to max? But that is speculating.

So i went back to the 11.x development branch and did a site install with standard profile. Then i exported the configuration and changed the automated_cron.settings interval attribute ( which has a zero or positive constraint ) to a negative value. When i import the configuration it does not throw any error, but when checking the object using the config_inspector module it does show a validation error. Not sure if this is te expected behaviour or something else is failing.

📌 Validate configuration schema before importing configuration Needs work

Might just be it is just not yet done on config import, but only at save.

When the value is bigger or smaller than the PHP_INT_MAX/MIN values, it was getting modified in the Drupal\Core\TypedData\Plugin\DataType\IntegerData::getCastedValue to the max/min value of php in that architecture, so i tried a different approach and added a check that throws an exception when the value is not within the valid value range for the system.

I've done it to the integer and also to the float values, and wrote tests for it.

The pipeline is failing right now, but the tests that are failing seem to be unrelated to the changes made in the branch.

Change appears to be breaking all functional and kernel tests. We do occasionally get randoms but not that many.