Provide a way to insert images by uploading to the server instead of Base64 encoding the images about bootstrap-wysiwyg

[qiulang]

The other concern I have about is image file size the editor supports. As I read in many places, base64 image strings is only good for small images.

[steveathon]

@qiulang is this mostly to overcome the need to access the raw stream of an upload vs using the regular file post methods?

There are a lot of advantages over using the base64 string - such as not needing a library to manage the image preview in the browser and allowing for cut-and-paste from other sources like editing apps.

Do we just need to provide some better examples of how to handle the file upload?

[spreadred]

@qiulang as @steveathon states, I believe the idea behind this entire package is to keep things as simple as possible and therefore limit dependencies and therefore allow for its use in the largest range of environments.

That being said, there is nothing preventing you from converting the base64 string your server receives and turning into a stand-alone image stored somewhere on your server and modifying the resultant HTML code to point to that image instead of in-lining it.

I'm not sure what your particular use case is, but (I imagine) this would be fairly trivial to do with PHP. If you could provide us with more details of what you're trying to accomplish, perhaps we could point you in the right direction.

[qiulang]

@steveathon @kaptainkommie, thanks for answering my question. In my particular case it is

to overcome the need to access the raw stream of an upload

and just like you said we actually

converting the base64 string on my server and turning into a stand-alone image stored somewhere on my server and modifying the resultant HTML code to point to that image instead of in-lining it.

I do have a question, as you guys said "there are advantages over using the base64 string". So what is the advantage of using base64, except it is simple ?

[steveathon]

Somewhat true. Base64 images are in their raw state when they sit in the editor - that means that if you upload a 1.6GB gigapixel image then it will indeed sit in browser memory until it has finished submitting to the server. This can be hell on a browser.

It's a trade off that works when you're uploading images, when you edit an existing set of content that already has an image in it, it doesn't load the base64 string to do the work - it only uses the or other media tag. That means you're cutting out that bloat.

So it's a mixed bag yes, but it's an effective way of dealing with it in the editor until it's uploaded.

Some examples we could add would be:

• Dealing with stream in language X (What language are you using btw)
• How to background upload images in a contenteditable=yes div (This is probably only few lines of code that would need some variables added to the setup of the editor itself... perhaps a plugin could work here)
• Preventing image paste in the editor. Perhaps a config option for some compatibility support.

With the last one, you'll need to work out how to upload images and then have code to go fetch images, insert them as tags, etc. Feels like more work in the long run. An example of how to stream the image upload is probably better in the short term.

[steveathon]

Also just noticed in @kaptainkommie's post.

That being said, there is nothing preventing you from converting the base64 string your server receives and turning into a stand-alone image stored somewhere on your server and modifying the resultant HTML code to point to that image instead of in-lining it.

I think this is the best course of action - if you can background upload the images in the editor. Perhaps what is missing from the editor is an event firing when an image is pasted.

[spreadred]

@steveathon Isn't insertFiles() fired when an item is dropped onto the editor?