Cockpit: [Next] path prefix for image fields

[gryphonmyers]

Currently, the image field makes its 'path' value available on the REST API, which is relative to docroot. It would be useful to be able to specify a path prefix, whether on the image field or installation-wide, which would be prepended to the path. Use case: turning paths into public URLs, changing relative base path without having to change the folder the resources are actually stored in. It might be the most versatile if rather than appending the path it appended the file name.

Example - say images are stored on the server at /my-nfs-share/media/images/ and you upload mypic.jpg into that folder, but you want the REST API to publish a public URL of https://cdn.mysite.com/images/mypic.jpg. I could see both path prefix and public prefix being useful concurrently.

[aheinze]

Your described case should be easily solvable with a cdn pull zone.

[aheinze]

I would also like to integrate a service like filepicker.io ... But this would again create a dependency to a vendor what is something I try to avoid

[gryphonmyers]

Filepicker integration would be really cool. AWS S3 integration would also be extremely useful! If you're hesitant to bring a third party dependency into the fold of the core product, you could always build it as a plugin.

I'm going to look into CDN pull zones to see if they fully satisfy my particular (real) use case, then I'll let you know if I have any counter arguments :)

[JesperWe]

Another use case (similar, I'm just mentioning so it is not forgotten) for a prefix is when you are using the plain Cockpit storage for images, but with Cockpit running on a different host than the server that serves the client code. Right now I am solving this on the client, but that means parsing all html from html/wysiwyg fields and modifying the src attribute. Would be nice to have the html already processed from the api.

[gryphonmyers]

If I'm understanding you correctly, using a pull zone would only work if you were resolving the relative path from a particular origin that was set up to work with the CDN. This does not 100% satisfy the need for a publicly resolvable link, because as @JesperWe says, trying to resolve the link from any other host will not work. If you're using the REST API to distribute data to other websites (which it works great for, and is partially why this is such a great CMS), the usefulness of the image field in its current form is somewhat limited.

[pozylon]

I just encountered a situation where a prefix would save me hours.

In a wysiwyg field, paths get stored relative and I have a microservice architecture (using cockpit as headless cms). So when the consuming service is the UI and gets the data, it needs to search/replace all the relative paths with prefixed ones in every field in order to render the page and the corresponding files correctly.

Actually the same situation as @JesperWe mentioned.