Aside: We get this question a lot, and I'm trying to work up content for the wiki docs.
Background
In some browsers users can drag/drop an image into the WYSIWYG editor, which embeds the image data into the HTML as an IMG element with a Data URI. Elgg processes user-provided HTML through a security filter called Htmlawed before saving and displaying it to other users. Older versions of Htmlawed (in old Elgg versions) allowed Data URIs to be used, so Elgg used to display those images in the saved page.
However, due to the risk that unsafe content could be embedded via Data URI, Htmlawed removed support for them, and so these features stopped working in later Elgg versions, too.
What can be done?
With a whitelist of acceptable image Content-Types, Elgg could safely accept Data URIs, but there are caveats:
We could also dynamically convert an embedded image to a file as if the author uploaded it separately. This functionality would come with its own set of caveats and policies that need to be determined (what title and access level to use?).
For these reasons I think it's unlikely that Elgg will support WYSIWYG embedded images out of the box, but we can assist plugin authors to provide this functionality.
info@elgg.org
Security issues should be reported to security@elgg.org!
©2014 the Elgg Foundation
Elgg is a registered trademark of Thematic Networks.
Cover image by Raül Utrera is used under Creative Commons license.
Icons by Flaticon and FontAwesome.
- DhrupDeScoop@Dhrup2000

DhrupDeScoop - 0 likes
You must log in to post replies.my 'personal' opinion - judging from the rather not-so-overflowing demands (other topics posts) for that data uri scheme (data:image)... too much trouble to satisfy too few users' 'wanteds' features. the benefits vs disadvantages @ data uri seem kinda balanced.. except -- the (big) http request loads truncation vs the security fanagling headache!
i cannot find *any cms/platform that caters for this data uri embed/convert ;-) technicallly - can be done; reality.. is it worth the effort ? like those css stds compatibilty issues @ie 4,5,6,7,8..?! i' actually (foolishly) spent some time thinking of (not-so-quirky) design issues to parse out image:data data portion to create Files' object, embed properly, yadda.. yadda.. [ just needs to extract, undo base64 or octets; create file; code proper img src= ]. but then stopped to think -- *maybe - if 10-5% of the (elgg) downloaders (70K?) asked for such a feature, but not quite for a mere <= handful of wishes ;-Ptoo much code and too many side-issues.
the http request bandwidth savings might still give this some attraction for other uses -- sprites, buttons, builtin imgs, internal images ?! many small files? could might do 1/4 magic for page-load speeds...hmmm ;oO