Note: VDC folks may be able to explain this better, please edit if that is the case.
Use-case
- Add a view that lists nodes and save it with the default settings, e.g. 10 nodes.
- Add the corresponding config file to version control.
- Now decide that you want to show 15 instead of 10 nodes. Go to the view edit that setting and save.
Expected result
The version-control system shows a diff of the config file as:
- items_per_page: '10'
+ items_per_page: '15'Actual result
The version-control system shows a diff of the config file as:
+ options:
+ items_per_page: '15'
+ offset: '0'
+ id: '0'
+ total_pages: ''
+ tags:
+ previous: '‹ previous'
+ next: 'next ›'
+ first: '« first'
+ last: 'last »'
+ expose:
+ items_per_page: '0'
+ items_per_page_label: 'Items per page'
+ items_per_page_options: '5, 10, 20, 40, 60'
+ items_per_page_options_all: '0'
+ items_per_page_options_all_label: '- All -'
+ offset: '0'
+ offset_label: Offset
+ quantity: '9'Problem
Because the handler settings form that controls the number of items per page is only loaded when you click on the appropriate link in the Views edit form, by default that form's submit handler is not called. Therefore the corresponding config keys are not set.
Solution
When saving a view iterate over all plugins and handlers and set each config key to the default value.
Downside
The problem with this approach is that
A. the config files become just that much larger
B. even though the diff becomes clearer when modifying settings with this, when *adding* a field, for example, you would get a huge hunk in the diff that adds a billion default values, which makes the diff less reviewable in this case.
Because we really have to choose one or the other here I think there is no way around Views behaving like all other config in core. Therefore I think the proposed solution, despite the downsides, is the way to go.