[FEAT] Allow for queries/filters on collections when generating the sitemap

[Kyle772]

What does it do?

This implements conditions into the collections queries.

Below is a SS of the UI change.

Why is it needed?

The general idea here is to make the sitemaps more flexible. In my case, I wanted to filter out anything that was removed from the website when an entry was marked as deleted (but not unpublished so we can retain data where necessary; ie invoicing).

How to test it?

Nothing major was added so you should be able to run this as you normally would

Related issue(s)/PR(s)

Let us know if this is related to any issue/pull request

I think this only impacts the below issue but there may be some others.

#99

[Kyle772]

A quick note about i18n

[cipick]

this is amazing. just want to thank @Kyle772 for this feature, i had a hard time to extend the plugin to do the same thing <3

[boazpoolman]

I figured this feature deserves it's own section.
So I've split up the modal in tabs, where the "Filters" tab contains this feature.

[boazpoolman]

I've updated the settings schema a bit.

The PR was initially propsed with a settings object that might look like this:

{
  "contentTypes": {
    "api::page.page": {
      "languages": { "und": {
        "pattern": "/pages/[id]",
        "condition1": "slug",
        "condition1Operator": "$not",
        "condition1Value": "test"
      }
    }
  }
}

I've updated the PR so that the filters will be saved separately from the other pattern settings. Which could lead to a settings object that might look like this:

{
  "contentTypes": {
    "api::page.page": {
      "languages": { "und": { "pattern": "/pages/[id]" },
      "filters": {
        "0": {
          "field": "slug",
          "operator": "$not",
          "value": "test"
        }
      }
    }
  }
}

[boazpoolman]

The handleRemoveCondition function always removes the last filter. It would be neat if we can specify the filter we want to remove. Giving the end user more control on the filters interface.

[boazpoolman]

I think this condition can be optimized.

The only thing that should/shouldn't show for this ternary is the list of conditions. Though this ternary is used to render the entire component leaving duplicate code below (e.g. the add/remove buttons).

If we use the ternary just for the conditions list this would be resolved.

[boazpoolman]

Hi @Kyle772

Have you been able to take a look at the feedback I've posted on the PR?
I'd love to get this feature merged.

[Kyle772]

Hi @Kyle772

Have you been able to take a look at the feedback I've posted on the PR? I'd love to get this feature merged.

Wow I'm so sorry I don't ever check my github inbox lol. I'll try to address these changes sometime over the next couple of weeks. Sort of slammed at the moment but would love for this to get merged as I use my own fork on my sites