Suggesting an improvement for the ImageProcessor API service.
It would be nice to be able to input the image_path as a URL and not only a local path. Indeed, when following up on an image upload, it would be nice to be able to do this :
But it doesn’t work, because the full URL is added as a path
How would you recommend accessing only the local path as a result of a file upload ?
An internal ticket BKNDLSS-30005 is created to add this possibility. We’ll notify you here as soon as it is done.
But please keep the existing option available as well. Thanks.
Was merely suggesting this as an additional possibility, not a replacement.
Hi @Nicolas_REMY ,
I am stuck at a similar place as you.
If you did manage to just get a local path from the file URL, can you please share how?
Appreciate your help!
Hi @Achilles_Pereira ,
Sorry but I can’t help : I thought I would wait until the new version is implemented. I didn’t feel like spending time on developing something which would not be used down the line.
I suppose it could be done with a regex, but it would probably require quite a bit of debugging to get it right.
Thank you @Nicolas_REMY for the quick reply!
Is there a rough estimate?
That would help me decide to wait or figure an alternative.
I would be grateful if you could suggest a quick workaround for me to do this in the interim.
@Nicolas_REMY Just FYI.
In the interim, I have figured that I can add /opt/backendless/repo/<App_ID>/files/ prior to my filestore path.
Is there a risk to this approach? (in terms of this path getting changed in the future)
If I got this discussion right, you have a fully qualified URL of an image (like
https://....../files/web/images/.../myfile.jpg) and you want to extract the path
web/images/.../myfile.jpg from it.
This can be done like this one:
This extracts the string from the variable
url which succeeds the first occurrence of
Hope this helps …
Thank you @Klaas_Klever for taking time to reply.
I am not looking to extract path from full URL.
I have a file already stored on backendless filestore with full URL.
I am using a 3rd party image processing installed service which requires local path of file.
e.g. if my file abc.jpg is stored in root directory in the filestore /abc.jpg
the API is requiring the full local path which is /opt/backendless/repo/APP_ID/files/abc.jpg
(I figured the above thru log files while debugging)
It works now.
But, this solution relies that Backendless do not make any change to this path structure in the future.
So, wanted to get a view if there is any risk to use this that I am not able to see.
In the status of the ticket, I see that it is currently in the testing phase. So, if everything goes well, then in the coming weeks, this update will be in PROD servers.
Best Regards, Nikita.
Thank you for the update @Nikita_Fedorishchev
Hello @Klaas_Klever @Jorg_Beyer @Achilles_Pereira @Nicolas_REMY
Sorry for the long wait. We have released a new version of the service with a fix for the problem you wrote about. Please uninstall the old service and install it again. Let us know if it works for you.
@Inna_Shkolnaya Could you please let us know what we should expect if we uninstall and then reinstall the service?
Uninstall: will all calls to the different API services disappear and the code is broken?
Reinstall: Are the API calls using the same parameters? Is there an option that I can use the old behavior (I am already in beta testing with some users)? So, that my dependent logic can remain the same?
Thank you in advance for explaining.
This is so that the service code can be updated and the ability to handle images by URL can be made available. All methods have the same names as before. So if you used this service in some business logic, it will still work after reinstalling the service.
as expected, your fix is not backward compatible as requested by me (see thread above). As a consequence my code is broken and does not work as intended. This is the error message I receive:
Could you please let me know what
image_path the service is expecting that I can fix it.
We apologise that this change does not work for you as expected. Could you please provide your APP ID as well as the function or method where this stopped working.
It is the URL format that changed. Please just describe the expected format. There is no need for any further inspection. Thank you.