Isn't the problem just that records with '[]' are faulty and should be deleted?
Nope. The legacy records with '[]' work fine with new module version and views created earlier. If you simply delete them, you will lose the order set by draggable views. The problems only start if you open an old view for editing and save it. That's when a duplicate set of records is created with args set to actual args but the old records with '[]' are not removed creating the confusion.That's when it's a good time to remove legacy records for this specific view.
This should actually be just an update hook to resave the items to the new structure instead of adding code that is not needed anymore afterwards?
@tim-diels: The problem here is that when looping through all records in an update hook out of view context, you have no way of knowing what the view args were when the record was saved.
Shouldn't the description on the module page be corrected accordingly? I see some people confused over the requirement present in the module description but not in the module code anymore.
@dqd, thank you for your resolution - it works fine. In my case it seemed easier to export whole configuration first, grep for affected files, fix them and then import only affected files one by one.
@brenk28, the patch did not work for me (core 9.5.11) - the default value still not saved. Eventually I bit the bullet and switched to Entity Prepopulate module which does not have this (and other) problems.
@kostyashupenko, the core developers clearly don't agree that this is an issue. And with a contrib workaround available - https://www.drupal.org/project/views_random_seed → - who cares?
@dww,
I'm reluctant to add Yet More Permissions(tm) to solve this. Seems more like a widgetselection plugin setting to me (e.g. a "[x] Include unpublished entities the user has access to view" checkbox or something).
If we absolutely can't just change the existing [unexpected and undesired] behavior, then I think a widget setting is a very good idea. Because it will allow to override the default behavior on an individual field level, not on a site level. Who know, maybe someone will need different behavior in different parts of the same site?