Found this here…
…but for today i think i am overloaded.
To be continued… 
@russian-dima my earlier point was related to you testing rp.get() But like I mentioned before, you need to use fs . writeFileSync instead.
@russian-dima like I mentioned earlier, you need the fs NodeJS library for your use case.
@russian-dima wait. Are you trying to facilitate a manual upload now through an iFrame, or do you have a base64 image that you need to decode and upload into your media library? Those are two different use cases which require a different solution. If we are just talking about an image upload, you are better of using the built-in Wix image upload capability.
If i am honest, i want to know/learn both ways. My aim is to do it the coding way and not the manual way over the wix-editor, where you manualy generate a upload-button click on it and do the upload.
Also the decoding of the base64 is very interesting for me, because it gives me some new ideas.
But i think i would prefer, first to uderstand this one…
https://www.wix.com/velo/reference/wix-media-backend/mediamanager-obj/getuploadurl
Tried it out yesterday (intensively), but without any luck.
Still a lot of questions a open.
My main-aim is to upload a file to media-manager the coding way (especialy images).
What i still do not understand:
-Where to put this part of code? Backend?
I can find a hint, that this code has to be used in an external Node.js-app.
What does it mean?
/********************************
29 * External Node.js application *
30 ********************************/
import * as request from 'request-promise';
33
34async function uploadImageViaUploadUrl(uploadUrl, uploadToken, contentStream, fileName, contentType) {
35 const body = {
36 upload_token: uploadToken,
37 file: {
38 value: contentStream, // a Node.js Buffer with the file content
39 options: {
40 filename: fileName,
41 contentType: contentType
42 }
43 }
44 };
45
46 const response = await request.post({url: uploadUrl, formData: body, json: true});
47 return `wix:image://v1/${response[0].file_name}/${response[0].original_file_name}#originWidth=${response[0].width}&originHeight=${response[0].height}`;
48}
I tried to run that code at the backend, without any luck and got some ERRORs —> request.post is not a function
Also found out that this here is described in the VELO-API, but…
import * as request from 'request-promise';
seems not to be correct.
And this one works …
import * as request from 'request-promise-node';
I was able to generate the UPLOAD-URL, which i showed already in my last post (but do not know if did everything the right way and if the generated UPLOAD-URL is valid/correct).
Of my understandings i have to fill out the following values…
(uploadUrl, uploadToken, contentStream, fileName, contentType)
That mens first to get my UPL-URL+Token (token is empty) and insert them to the uploadImageViaUploadUrl-function.
Together with the oder needed values, right?
Another question is: Do i have to change something in the getUploadUrl-function?
import { mediaManager } from 'wix-media-backend';
6
7export function getUploadUrl() {
8 return mediaManager.getUploadUrl(
9 "/myUploadFolder/subfolder",
10 {
11 "mediaOptions": {
12 "mimeType": "image/jpeg",
13 "mediaType": "image"
14 },
15 "metadataOptions": {
16 "isPrivate": false,
17 "isVisitorUpload": false,
18 "context": {
19 "someKey1": "someValue1",
20 "someKey2": "someValue2"
21 }
22 }
23 }
24 );
25}
All i have changed was the MIME-type from jpg to png and got a long upload-url shown in one of my very last posts.
And this values i tried to insert into the uploadImageViaUploadUrl-function
So now the question: Is my way of doing, totaly wrong?
What i am still missing, or still doing wrong?
How to explain the ERROR ?
@russian-dima I gave it a go as well.
I believe Velo somehow encapsulates
fs.writeFileSync('img.png', buffer);
in mediaManager.upload(). Also new Buffer () is depreciated by NodeJS. So what I tried is the following:
//front-end code
import {storeImg} from 'backend/test_upload';
var dataUrl = "data:image/png;base64,iVBORw0KGgo ...";
base64 = dataUrl.split(",")[0]
storeImg(base64);
//back-end code
import { mediaManager } from 'wix-media-backend';
export function storeImg(b64_img) {
var buffer = Buffer.from(b64_img, 'base64');
mediaManager.upload(
"/",
buffer,
"test_img.png",
{
"mediaOptions": {
"mimeType": "image/png",
"mediaType": "image"
},
"metadataOptions": {
"isPrivate": false,
"isVisitorUpload": false,
"context": {
"someKey1": "someValue1",
"someKey2": "someValue2"
}
}
}
);
}
Unfortunately, I don’t see anything happen in the Media Manager/Site Files. It somehow created two empty folders although I indicated “/” as location… Regardless, this - in my opinion - should be the way to achieve it…
I could dig up some examples on how to achieve an image upload through an iFrame to then convert it into a base64 string, but I’d suggest to head over to Stackoverflow instead.
Ok thanks for this info, could help my inderstandings. As i already wrote in my very first posts, i was also able to write data to the Datamanager (but it saved it as TEXT) and it also created a NEW Folder (this is also described in the Velo-API, that if you use folder-names, which do not exists yet in your datamanager, NEW one will be created).
I will take a closer look at your code, when i am back later.
Normaly we should be able to solve it✌
By the way, what do you think about the idea to store images as zipped base-64-text(files) in your own DB, instead of using the Datamanager?
That could be a cool technique to generate a real, multi-upload, wouldn’t it?
This is why i wanted to know about base-64 and all it’s sub-stuff.
I actually already do that on my site. There are some limitations though, as the base64 text strings you generate from images are sometimes too large to fit in one database field.
Yeah that’s why I shared it. It doesn’t work, but at least you know what I was thinking about earlier.
@vervoortyves I think i have even a better idea 
, if that works, than you won’t have this data-limit-problem anymore. (if it works!)
But first i want to solve these two issues, disscussed here in this post.
@vervoortyves
Thank you yvervoort i —> GOT IT !!! Huraaaaaaaayyyyyyy!
The pic is in the manager !
Greetings from **yvervoort** , **dima** & **Chris Derrell**
Also a big thanks goes to —> @Chris Derrell !!!
We made it ! 
I already thought it is not possible
@russian-dima You gonna leave us wondering like that? What were your final successful steps? (For future learners)
@chris-derrell yvervoort gave me the final hint/tip how to solve it. It was all about the right upload-format, which i was asking right from the beginning of my post. The BEST-ANSWER was very close to be the endsolution. Only problem was? → Exactly → the right upload-format.
To solve this i took a HTML-Component which includes an FILE-SELECTOR. The FILE-SELECTOR generates the base64-code which has a prefix. And this is the important point. The question was —> what to put into the BUFFER (which format).
For those, who want to solve this mystery → inspect the base-64 code and think about my tip—> prefix!
And with some testings (different formats), at the end i could generate the right binary-code and bring it to work.
But one question is still open.
Would this be possible without using a HTML-Component including a FILE-SELECTOR?
…to be continued, when my M-Uploader is completely ready 
1-st. Version of my M- Pic -Uploader is ready right now (yes it is at moment just an image-uploader —> FILE-UPlOADER is in DEVELOPEMENT). 
Sorry, it is still not perfect, but it demonstrates how to M-upload into the own DATA-MANAGER the direct way, without any usage of 3-rd-party-services (like DROPBOX)…
Here it comes…
In the video you can not see the File-Selection-Process due to security risks.
But here a pic, how it looks like, when picking-up files (in this case → images)…
This was (in the video) hidden M-FILE-SELECTION…
All the rest you can see in the video.
As you can see, the right —> UPLOAD-folder was created in my Data-Manager…
Now i am excited, do we have all the pics inside our new created SUB-FOLDER → TEST, right now ??? Let’s take a look!
Conclusion? —> Did we make a DIRECT-MULTI-UPLOAD ?
Ohhh sorry! I forgot to open the last folder 
Let’s do it!
Oh my god! It works!
Now you know, what for stands the —> “M” !
Back to @yvervoort statement…
…If we are just talking about an image upload, you are better of using the built-in Wix image upload capability.
What is the built-in-wix-image-upload capability? → The ONE-FILE-UPLOAD-BUTTON ?
If so —> NO THANKS! It’s not the right solution, for a good UPLOADER.
I just remember, right now. Why there is still a multi-upload in developement, although, there are already possible abilities exposed in the VELO-API ?
Ohhh, just to complete this post…
My first attempt to find a workaround for a M-Uploader…
https://www.media-junkie.com/multi-upload
and here just a related post…
https://www.wix.com/velo/forum/coding-with-velo/does-reset-on-uploadbuttons-work-properly
Hi @russian-dima , good to see that it all worked out. If my answer was ‘close to’ best answer, please let me know why my solution resulted in an empty folder so that I can adjust my answer so that it will help others in the future. Also how do you get around the field limitations? Curious about your solution there as well.
@vervoortyves I already did —> base64 cut off prefix😉 (how is devided the base64-code?)
If still unclear → pls post me an e-mail (thx).