[Bug] url.split is not a function when attempting to load "local" images (React 18)

[wwkimball]

[Bug] url.split is not a function when attempting to load "local" images (React 18)

[wwkimball]

Update: I noticed in your documentation about the files array that you're showing source as a String despite the sample value clearly being an Integer. So, I added .toString() to my own Integer-based source and sure enough, this resolves the error.

That's obscure and fragile, especially since the documentation doesn't explicitly state something like "Note: source must be a String value." If I may request, please either:

1. Cast source to String when you load it so that the onus is not on your end-users to ensure that we do so.
2. Add a specific note like the above suggestion to ensure that readers of your documentation know to ensure source is a String.

Option 1 would be a better service to your end-users.

That said, the FilePond isn't behaving quite right despite the original error now resolved. Despite receiving the data it seems to need, the FilePond is showing only gray boxes with the Stringified source as a title and the file size as a subtitle on each box, each with an X button that seems to do nothing except remove the gray box from the control (it does not trigger a call to the back-end API).

I'll try to research this as a new issue...

[wwkimball]

Update on the follow-up issue: It turns out, Express' sendFile function can't tell that file-extension jpeg is the same as jpg and should therefore be sent with a Content-Type header value of image/jpeg; it was instead sending application/octet-stream.

I had to modify my Node.js server to forcibly rename *.jpeg uploads to *.jpg. Doing so resolved the issue; FilePond now correctly loads and displays previously-uploaded images (with one caveat, below). This is IMHO entirely absurd on Express' part and fortunately, that issue has nothing to do with FilePond.

However, upon fixing that issue, another did arise: Upon (finally) successfully reloading previously uploaded images via FilePond, the FilePond component shows an X button on each image thumbnail. Clicking that button does nothing except remove the image preview from view without removing it from the API server; FilePond makes no effort to contact the back-end API server to signal deletion of the image. I expect clicking the X to trigger a delete event.

I will attempt to research this as a new issue...

[wwkimball]

Update on the issue of the X button failing to send a DELETE to the back-end API server: this behavior is evidently by design per the FilePond documentation. I have to say, I do not understand why.

While uploading files, when I click the X, it sends a DELETE signal. I therefore, reasonably, expect that clicking any X on a FilePond entry would invoke identical behavior. To do otherwise is a frustrating surprise.

For posterity, I resolved this discrepancy by adding the following to my FilePond instance:

, remove: (source, load, error) => {
  const url = `${protectedResources.apiPartOrderPics.endpoint}/${source}`;
  execute("DELETE", url)
  .then(response => {
    if (!response) {
      return;
    }
    if (response.status === 204) {
      console.log("ReceivingEntryCard:  Deleted packing slip photo: ", response);
      setPackingSlipPhotos(packingSlipPhotos.filter((file) => file.source !== source));

      // If the last packing slip photo was deleted, set the error message to required
      if (packingSlipPhotos.length === 1) {
        // 1 (not 0) because React hasn't updated the file list yet
        setPackingSlipPhotosError("required");
      }

      load();
      return;
    }
    console.error("ReceivingEntryCard:  API error deleting data:", response);
    error("API error deleting data");
  }).catch(err => {
    console.error("ReceivingEntryCard:  General error deleting data:", err);
    error("General error deleting data");
  });
}

[rikschennink]

Thanks for the detailed implementation story.

I've just pushed a fix for the "setting source with a number" issue. Past-Rik wrote this library 6 years ago, and I myself ran into it yesterday when testing something and it was quite confusing.

However, upon fixing that issue, another did arise: Upon (finally) successfully reloading previously uploaded images via FilePond, the FilePond component shows an X button on each image thumbnail. Clicking that button does nothing except remove the image preview from view without removing it from the API server; FilePond makes no effort to contact the back-end API server to signal deletion of the image. I expect clicking the X to trigger a delete event.

You'll have to implement the "remove" endpoint, see:
https://pqina.nl/filepond/docs/api/server/#remove

It's not implemented as allowing users to remove files from the server is a potential security risk.

[wwkimball]

Thanks for the detailed implementation story.

Happy to help!

I've just pushed a fix for the "setting source with a number" issue. Past-Rik wrote this library 6 years ago, and I myself ran into it yesterday when testing something and it was quite confusing.

Great! I'll pull down the update today and test it out.

However, upon fixing that issue, another did arise: Upon (finally) successfully reloading previously uploaded images via FilePond, the FilePond component shows an X button on each image thumbnail. Clicking that button does nothing except remove the image preview from view without removing it from the API server; FilePond makes no effort to contact the back-end API server to signal deletion of the image. I expect clicking the X to trigger a delete event.

You'll have to implement the "remove" endpoint, see:

https://pqina.nl/filepond/docs/api/server/#remove

It's not implemented as allowing users to remove files from the server is a potential security risk.

I do not understand this reasoning based on existing contradictory behavior of FilePond:

1. Upon upload, the API must already issue a unique ID back to FilePond. This necessitates permanent artifacts on the server (filesystem and/or database). We API authors must necessarily already take precautions that the destructive operation is rendered secure.
2. During the process/revert cycle, FilePond already emits a DELETE command to the API server whenever the user clicks the X button. This triggers the API to destroy the permanent artifacts (filesystem and/or database) which were created to respond to the initial upload.
3. Merely loading the same files back into FilePond does not change the security implications of what the API server already had to handle to enable revert/DELETE during the upload/process mode.
4. Every destructive operation carries with it the same security risks, no matter whether the user is (likely unknowingly) deleting a temp or permanent asset. It always falls on the API implementer to handle destructive operations with due care.

I don't understand the argument that one press of the X button is more/less "secure" than another. The same ID is transmitted between client and server, either way.

As illustrated above, I have added the additional code to handle pressing the X button after a load. I had no choice but to expend the time to do so. I posit that it isn't any more/less secure than just letting FilePond send the DELETE command, sparing FilePond users the surprise and frustration of finding that the X button does nothing on its own.

This is incidentally academic at this point. I have FilePond behaving exactly as I need by writing the additional DELETE event handler. I only wanted to voice my journey in the hope that it might provide constructive feedback and, ideally, help make FilePond even easier to use for future projects and newcomers.

Above all else, I do want to say, "Thank you, so much for making FilePond!" Despite the loss of a few days to the original and subsequent issues, it is clear to me that your work did save me many countless days/weeks of implementing such a solution myself. For that, I am sincerely thankful to you.

[rikschennink]

Thanks for your input, I'll take it in consideration for FilePond v5

Above all else, I do want to say, "Thank you, so much for making FilePond!" Despite the loss of a few days to the original and subsequent issues, it is clear to me that your work did save me many countless days/weeks of implementing such a solution myself. For that, I am sincerely thankful to you.

I'm glad to hear that. ☺️