Add orderby key to all sequences in core

So this is why I am still getting false-positive configuration diffs in my production deploys? I would have thought that #2361539: Config export key order is not predictable for sequences, add orderby property to config schema → would have addressed this but this issue indicates to me there are some edge cases still remaining?

The weird part to me is that on export in my local development environment, I can export and then do a drush cim and there are no changes. But deploy that same code to production and I get the same set of consistent config entities that appear changed but actually aren't.

www-data@app-7947bcd569-rnz4j:~/html$ drush cim
+------------+---------------------------------------------------------------------+-----------+
| Collection | Config                                                              | Operation |
+------------+---------------------------------------------------------------------+-----------+
|            | commerce_product.commerce_product_variation_type.default            | Update    |
|            | commerce_shipping.commerce_shipment_type.default                    | Update    |
|            | core.entity_form_display.commerce_product_variation.default.default | Update    |
|            | core.entity_view_display.commerce_product_variation.default.cart    | Update    |
|            | core.entity_view_display.commerce_shipment.default.checkout         | Update    |
|            | core.entity_view_display.commerce_shipment.default.user             | Update    |
|            | search_api_solr.solr_field_type.text_en_6_0_0                       | Update    |
|            | search_api_solr.solr_field_type.text_en_7_0_0                       | Update    |
|            | search_api_solr.solr_field_type.text_und_6_0_0                      | Update    |
|            | search_api_solr.solr_field_type.text_und_7_0_0                      | Update    |
|            | views.view.commerce_cart_block                                      | Update    |
|            | views.view.commerce_cart_form                                       | Update    |
|            | views.view.commerce_carts                                           | Update    |
|            | views.view.commerce_products                                        | Update    |
|            | views.view.order_shipments                                          | Update    |
+------------+---------------------------------------------------------------------+-----------+

It's more noisy than anything but it would also be nice to have my CD logs only reflect actual changes. Or am I missing something here?

Hunch: different PHP versions sort certain arrays differently? What PHP version are you using in prod vs local?

Hi Wim, thanks for chiming in. This is containerized so everything "should" be the same and I just did a pull of my image locally to confirm and yes, same PHP versions locally and on production. I also thought perhaps the host environment was like, changing some sort of localization settings but I don't see any LC* environment variables... though I'm way out of my area of expertise there.

I was looking into this for a few annoying instances in our sites, and am not finding PHP differences. I'm thinking perhaps database differences? SELECTs with no ORDER BY...

We most often hit this issue on text format filters and static menu overrides. Today I'm seeing it on an entity_view_display layout builder settings.

I think this is going to need to be a plan because we really ought to add test coverage of everything.

I propose to add a new method to ConfigEntityValidationTestBase (and perhaps also \Drupal\Tests\jsonapi\Functional\ConfigEntityResourceTestBase to test it in an end-to-end/integration test). That way we don't have to start from scratch.

Most (but not all) type: sequence occurs in config entities anyway. For simple config, I think 🌱 [meta] Add constraints to all simple configuration Active is relevant.

I think that we should make sure that we have an database index for every query we add orderby().

@daffie Hah, I get that that triggered you but … it's completely unrelated 😅 This is about \Drupal\Core\Config\Schema\SequenceDataDefinition::getOrderBy(), which is used only in \Drupal\Core\Config\StorableConfigBase::castValue(). It never relates to database queries.

@Wim Leers: Ok, than it is fine. Just want to make sure that Drupal does not get slower. :)

Could we start adding predictability, at least, to config entity dependencies? See ✨ Index configurations are changing from export to export. Closed: duplicate

On a large site with multiple developers I see the order of block visibility plugins switching around quite a lot. What do we need to do to move this forward?

I think the easiest would be to add some option to Wim Leers' config inspector → to surface sequences that have no orderby setting.

Then the medium hard part is to find out which are the easy ones that could just have one of the currently available options of "key" or "value".
Then the hard part is to identify new "orderby" options (like key-then-value which core.extension:module is using) or strnatcasecmp for filter formats (see #10 📌 Add orderby key to all sequences in core Active )
Maybe another one could by "property:weight" for sequence items that are sorted by weight.
Maybe we should also add "none" for sequences where the sort order in-itself is important data, which would allow us to tell other systems to leave it alone.
And after identifying more sort options we need to convert the sorting on save to a sorting by config schema

And finally we celebrate!

Note that adding a callback as a sorting option was dismissed because it would make the config schema more dependent on having a running drupal instance.

Thanks, opened 📌 Identify sequences that have no orderby setting Active

Wouldn't it be preferable to deprecate the absence of orderby? 🤔 (Perhaps only for config schemas defined in Drupal core initially?)

I don't see what doing this in the Config Inspector module would do to help move this forward in a way that it won't regress again.