Images inserted with plone4 broken on plone5?

@seanupton recently put a lot of effort into 1.x (

this made us give 1.x in plone4.3 another spin.

for sites with existing content (especially for images inserted into richtextfields) some migration has to be done:
the markup for images in richtext fields changed from Tiny3 (Products.TinyMCE) to tinymce4 ( 1.x)

  • image inserted with Products.TinyMCE look like this:

    <img class="image-inline" src="resolveuid/f5ec83e6905247b99b258eaff3d140ee/@@images/image/preview" />

  • tinymce4 image dialog (shipped with expect's this:

    <img class="image-inline" src="resolveuid/f5ec83e6905247b99b258eaff3d140ee/@@images/image/preview" data-linktype="image" data-scale="preview" data-val="f5ec83e6905247b99b258eaff3d140ee" />

i wonder if people migrating from plone4 to plone5 do not have the same problems.
we did not find any migration routine that looks like it's handling this case in

is this something that needs to be added to plone5 migrations, or did we overlook something and there is code handling this already?

@mauritsvanrees , @thet, @esteele, @vangheem i'm pinning you guys personally because i think you'll know best if this is something handled by the migration, if it should be handled, or if you decided not to care about this in the upgrade. thanks for any answers/pointers

The new tinymce integration should be able to parse urls like resolveuid/f5ec83e6905247b99b258eaff3d140ee/@@images/image/preview and use them correctly still in the editor

If not, there is a regression.

And what do you mean by broken? When you view the page, they do not show? If this is the case, then it is a plone.outputfilters problem and not a problem with tinymce. Those URLs should get transformed.

I can only yet speak for my work on the 1.x branch of in Plone 4. The images are not broken here for display, however:

(1) Images previously linked without UID in Products.TinyMCE (by relative path, not resolveuid) are treated as external by TinyMCE 4.3 in Mockup master.

(2) I suspect -- even when Products.TinyMCE wrote out content with resolveuid in src URLs -- that what is uneditable is (a) scales; (b) alignment. I need @frisi to confirm this, as I don't have examples.

I have not had a chance to look into this more in depth because I'm trying to fix an unrelated mockup bug in related items widget first (clicking any breadcrumbs now throws exception in both Plone 5 and Plone 4, it is harmless but a bug nonetheless). Once I can clear this off my plate, I will investigate editing images a bit more.

@frisi: can you mess around with some manual DOM manipulations to figure out which attribute on the tag is the crux here?


thanks for your reply @vangheem and thanks for your clarification @seanupton

as sean pointed out existing images (inserted into texts using tinymce3) are not broken for display - everything works fine

i digged deeper into this today and found out that editing is only a problem for archetypes content:

i created dexerity and at content with textfields containing text with an image (or took content crated with Products.TinyMCE before installing
and started to edit the documents using tinmce4 ( 1.x)


document.text.raw contains the url that should be parseable and editing the image through tinymce works (image is selected, scale and alignment is set correctly)

<img class="image-left" src="resolveuid/ea4684d678ab4ae78a1038bdd17df526/@@images/image/thumb" />

however for archetypes, this is not true:

the interesting thing here is, that in the database we store the image the same way as for dexterity.

this is what context.getRawText returns:

<img class="image-left" src="resolveuid/ea4684d678ab4ae78a1038bdd17df526/@@images/image/thumb" />

but when i edit the document and use tinymce's source button, i can see that tiny uses the text after outputfilters have transformed it (archetypes getText())

<img alt="Image Title" class="image-left" src="image-test.jpg/@@images/f8f4827e-5407-4d3a-a171-445c3609f136.jpeg" title="Image Title" />

of course - there is no way for tiny to parse out the image's uid and/or scale here.

how can we prevent tiny from using the transformed output here so that it works the same way as it works for dexterity content types and the RichTextValue?

any pointers appreciated @vangheem, @seanupton

just added a ticket to and a Pull Request that solves the AT issue is on the way