In a Plone 6.1.3 classic site, I have imported HTML from another system (an older Odoo) into a custom content type's text field. Many of the imported content items contain base64 encoded images saved directly in the HTML, e.g.,
I'd like to create an Image from the base64 encoded data and save it in the (containerish) content item, then update the HTML to replace that img tag with a link to the image so it renders inline but probably not full size.
A curious thing about this HTML: in the default view of the content item, it does not render the images, but when I edit the content item, TinyMCE eventually comes up and shows the image rendered inline in the rich text.
It's kind of a shame that the default view doesn't show those inline images... (says lazy me) even though of course it's probably quite inefficient to leave them in there as is.
Another curiosity: TinyMCE's view source shows HTML looking like this:
Oh dear base64 encoded images in the main content.
that also happened when you copy /paste content with images from Word into a Tinymce widget.
Iirc @mauritsvanrees wrote a proof of concept some years ago (or longer) which extracts those images into separate Image content items on save. Classic UI. Let me search.
A Ploney mind is a joy forever. I started fiddliing with it 2002-2003 .
I sometimes joke with Maurits in conversations that with the 17+ years of working together on projects at Zest, I very often still remember why or where he solved something, and he then remembers the what and how.
collective.base64imagepatch
The current package collective.base64imagepatch is an add on for the CMS Plone. It injects eventhandlers for Contenttype creation and modification to assure that no inline base64 encoded image is stored in an RichTextField.
Said that, it is quite strange you get the image using the blobid, check in the browser if there are any real http call. Being the hash always the same, maybe you've already uploaded the image and some mechanism is using that uploaded image via its hash instead of the one you see in the browser content.
What means inefficient? When you try to read the image in the source yourself instead of watching, I agree
As long as the editor can manage to fold such stuff it is not that much more inefficient than to compare binary with base64 encoded. Except you save the request!
Another aspect is that the Plone filtering has two levels:
Remove nasty content from the saved source during save. You save and it is gone.
Filter out the tags when rendering for display. Still there in the editor.
And another final thing is transform:
Transform a recognized pattern during rendering (like replacing resolveuuid links with an absolute url, but keep it in the source
Transform before save and save the transformed result.
If the images are still preserved, you may tweak the filtering options for display.
If you create a portal transform pipe that extracts the image on save, writes it into the database and replaces the instance in the source with the image link.
What seems absolutely reasonable drops questions when you are in classic and may cannot use the page as container for the converted image by default.
Another concern ist that if you can place dataurls (usually base64 encoded) in the saved content and process them, you may be subject to serious crime.
I personally enjoyed when Zotero.org started to write singlepage html files with all resources base64 encoded inside one file. This reduces the burden to conserve content for archive purposes. But I never thought of the way back.
In frame oriented layout software you can save images inside the document and externally linked. Most allow conversion from one approach to the other. With Word and other office programs this is pain. With PDF you need special skills and tools.
With this example you can see again, how improper Long Term Content Lifecycle Management breaks the internet and damages our digital heritage.
Thanks for bringing this up.
Ah: And do not forget the conversion and handling of image metadata in this process!
I can see the base64 data in the source as the TinyMCE code processes the (very long) html and only eventually does TinyMCE become ready to accept user input and changes what I see to the “blob”. The raw text value also still contains the base64 data.
@fredvd this was exactly what I needed. At first I tried just using it as is, and there were just a couple of small issues to tweak, given it had been 4 years since the last update.
Python 3 bytes vs Python 2 strings, utf-8
handling the raw attribute missing on RichTextField
but then I realized it did not work exactly the way I need to, since in my case I want the extracted images to be created inside each (containerish) item, so I ended up taking almost all the code but simplifying it (in my case, I don't need to try to add the image in the container of the item nor in the parent of the container of the item).
Then I found an issue with one particular HTML value that was 68,353,055 bytes long. For some reason, BeautifulSoup was not extracting the img tags correctly from it, so I replaced the tag extraction code with a regular expression findall().
Not sure how useful it would be to contribute these changes back (other than Python 3 bytes utf-8 tweaks) since the rest is specific to my use case.
.