Filepond 'restore' point (and possibly other endpoints) currently provides the id in the path, this lib expects it as a query parameter

[browze]

The following code using the current version of Filepond (https://unpkg.com/filepond@^4/dist/filepond.js):

const pond = FilePond.create(inputElement, {
    files: [{
        source: "12345",
        options: {
             type: "limbo"
        }
    }]
});

produces this request when Filepond executes:

<...your-url-config-path>/restore/12345 ...[A]
Whereas this lib appears to currently expect:
<...your-url-config-path>/restore/?id=12345 ...[B]
In other words it tries to access the id as a key on request.GET

Can fork and submit a pull request later perhaps, if you haven't gotten around to fixing, but as really busy right now as a temporary work around I'm just subclassing the restore view and redirecting A to B.

[jcohen02]

Hi @browze, thanks for highlighting this discrepancy between the way that the current version of filepond creates requests when using the limbo option and the URL structure that django-drf-filepond is expecting.

I've also been really busy and have a number of updates to work on with this library but this issue is hopefully something that is quite straightforward to fix so I'll aim to get this sorted out as soon as possible and included in the next release.

I'm hoping to get a new release out soon and it sounds like you have a temporary workaround in place for now.

[jcohen02]

Hi @browze, I've just been looking into this. I may be misunderstanding, so apologies if that's the case, but I actually think the issue you're highlighting here is controlled by the way you specify the endpoints in your server configuration where you set up the filepond options on the client side.

I can't honestly remember the reason for selecting the use of an id parameter in the GET requests for the load and restore endpoints but there was some reasoning for this! 🙂.

In fact, if you look at the relevant section of the filepond server docs, they give an example of the use of a query string parameter named after the relevant method, e.g. ?load=<source>, ?fetch=<url>, etc.

Assuming I'm not misunderstanding things here, I think you can resolve this simply by setting the restore endpoint in your client side filepond configuration to something like restore: './restore/?id='. If this is the case, I'll update the docs to highlight that GET requests to the load and restore endpoints expect an id query string parameter (and fetch expects a target param) and these should be specified as such in the client side configuration with something like:

FilePond.setOptions({
    server: {
        url: _<the base URL of your django-drf-filepond instance, e.g. 'https://mydomain/fp'>_,
        process: '/process/',
        patch: '/patch/',
        revert: '/revert/',
        fetch: '/fetch/?target=',
        load: '/load/?id='
        restore: '/load/?id=',
    },
});

I'll make this clearer in the docs.

[jcohen02]

This is hopefully addressed in #109 but do let me know if it's not - I'll leave this issue open for now.