Enforce order of display of components in config export

Created on 4 October 2014, about 10 years ago
Updated 21 September 2024, 2 months ago

Problem/Motivation

The content element describes how and the order in which fields are displayed. This array is sorted by key and a weight is stored. This is a problem because moving fields in field UI will change weights and if the export of two such changes are merged then fields otherwise unchanged will conflict.

Proposed resolution

Do not store the weights. Rather, sort before saving, remove them and add them back on runtime. This makes for a very simple update, too.

This reverts some of #2388867: Notifying user of config changes when config has never been synched makes no sense β†’ / e6cd1fa5b7 however this approach also results in a stable config file so the problems fixed there won't reoccur.

Remaining tasks

Write tests, review, commit, party :)

User interface changes

none

API changes

none

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
ConfigurationΒ  β†’

Last updated 7 days ago

Created by

πŸ‡ΊπŸ‡ΈUnited States robertdbailey

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States euk

    An old ticked, but it is still relevant, and just recently caused me an issue. I spent a good chunk of time today figuring out what in the world has happened to a merge of a few filter.format.* config files. Turns out weights were merged somewhat incorrectly. Not sure what happened there, but while comparing those config files for ordering I found that it is really hard to see how the ordering has changed with just a diff tool. You really have to spawn a site, import configs and compare ordering of filters visually through the UI. With the weight values and without visual augmentation - go figure what is the order.

    I am not sure why are we so hung up on using weights?

    Assuming a machine name is used for keys and the config maps are sorted by config keys - why not implement a binary tree with the reference to left and right (top and bottom) children by their machine name. This seems to solve the ordering and doesn't require storing a numeric position which apparently changes constantly and is the root of all troubles.
    - There is always a root at the top - has left, first child, pointer empty,
    - Leaf items will always have their right, next child, pointer empty,
    - The rest is self explanatory

    Benefits:
    - Each item is clearly marked where in the tree it is located.
    - Splitting or inserting an item anywhere in the tree will only alter the adjacent items, not the whole tree
    - Reordering items in the UI and saving the configs will not alter the structure, if the final ordering is kept the same

    At least for flat structures like filter formats, fields without field groups etc - this should be really simple.

  • I agree. Sorting by machine name is superior. When you have weights, the weights always change, which changes them all and complicates the diffs.

Production build 0.71.5 2024