Github throws "Malformed path tree" error when using relative path

[rcoopernexient]

Describe the bug
If my path value in a folder collection contains a ../ github throws a "Malformed path tree" API error during page creation. This does not happen when using a local backend.
For example, my collection in config.yml:

Looking at the payload getting sent to github shows that the tree path is hugosite/content/en/../en/test/_index.md. I believe the ../ needs to be resolved before the final string is constructed and sent to github.

  - name: "sections-en"
    label: "Sections - EN"
    folder: "hugosite/content/en/"
    create: true
    slug: "_index"
    path: "../{{language}}/{{section}}/{{slug}}"
    media_folder: "../../../static/img/"
    public_folder: "img

And github returns the error: "tree.path contains a malformed path component"

To Reproduce

1. Create a collection with a path value containing a ../
2. Set backend to github
3. Try to create a new item in that collection

Applicable Versions:

• netlify-cms-app 2.11.26
• bootstrap.js:80 netlify-cms-core 2.20.1
• index.js:27 netlify-cms 2.10.29
• Git provider: GitHub
• Browser version chrome 80

[erezrokah]

Actually I think in this case we should sanitise the . into -.
This configuration can serve as a workaround:

- name: "sections-en"
  label: "Sections - EN"
  folder: "hugosite/content"
  create: true
  slug: "_index"
  path: "{{language}}/{{section}}/{{slug}}"
  media_folder: "../../static/img/"
  public_folder: "img

[rcoopernexient]

@erezrokah the problem with that configuration is that it would pick up all languages. I need a separate collection for every language.

I would use the filter, but I'm already using filter on another field and it looks like filter can only work on one field.

[erezrokah]

Thank you for clarifying, hopefully will be pushing #716 forward very soon.

Regarding the filter, I agree that it is very limited and we should improve it.
I found #1000 and #1245 but none regarding multiple fields filtering.

but filtering on multiple fields can be useful, do you mind opening a feature request for that with your use case (and config.yml)?