Allow indexing a view display in multiple variants via UI

Currently, the display extender settings have the following structure:

index: true
variant: default
priority: '0.5'
changefreq: ''
arguments:
  type: type
  title: title
max_links: 100

I think that to solve this issue, we can use the new structure:

variant1:
  index: true
  priority: '0.5'
  changefreq: ''
  arguments:
    type: type
    title: title
  max_links: 100
variant2:
  index: true
  priority: '0.3'
  changefreq: ''
  arguments:
    type: type
  max_links: 50
...

However, this will require changing the views.display_extender.simple_sitemap_display_extender schema. We also need a new implementation of the hook_update_N to change the structure of settings that are already saved.

I've encountered with such case when worked with multi-domains sitemaps. I have a few views which display domain specified content, for every domain I have a separate sitemap variant. My purpose was to add a few variants to needed view in order to get view link for a different domains sitemaps.

Attached patch only supports multi-variants without ability add separate options per variant.

@init90 thank you for contributing! However, I note that there is a significant problem in your patch - there is no way to set different settings for each sitemap variant. We need the structure described in #4.

>However, I note that there is a significant problem in your patch - there is no way to set different settings for each sitemap variant.

Yes, my patch provides only a quick solution for multi variants support, without options per variant.

I agree that the concept described in comment #4 is more propper.

According to comment #4, I have a question about the UI part.
How it should look? Maybe fieldsets list, where every fieldset is separate sitemap variant?

According to comment #4, I have a question about the UI part.
How it should look? Maybe fieldsets list, where every fieldset is separate sitemap variant?

I think it should look like this:

Separate form for each variant.

>I think it should look like this:

Looks good, thank you.

>Whatever you guys do, bear in mind, there can be 5000 variants, so it would make sense to at least hide them in a field set so they don't destroy the view layout or something.

Hard to imagine the case when needed 5000 sitemaps variants, nonetheless it's a good point and should be counted. Thanks!

Whatever you guys do, bear in mind, there can be 5000 variants, so it would make sense to at least hide them in a field set so they don't destroy the view layout or something.

@gbyte.co, is the current UI adapted to this case? For example, on the node type edit page, in the "Simple XML Sitemap" block, each variant is a "details" element. If there are 5000 variants, it will look bad. In addition, most likely, the form will not be submitted due to the large number of elements (max_input_vars).

I'm not sure that we need to take this case into account, since the current UI is also not adapted for it.

I've run into some issues where this is not working with multiple variants. It seems that we are destroying the view as soon as we get to a variant that the view doesn't index in to. I've removed that destroy code now and that seems to have fixed it for me at least.

Patch with solution. So far, no hook_update_N implementation. Will definitely work with a clean install of the module.

Added hook_update_N implementation.

@gbyte please note that I no longer have commit permissions.

@gbyte I am glad to help :) Thanks, access will be useful. As before, I cannot guarantee that I will always have enough time to work on the module.