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.