Any existing content type to allow static html in a zip or .eml file to be served in an iframe?

ie allows any images, js, css files etc in the zip file or .eml to be served as the content part of the page (but in an iframe so the rest of the theme and navigation is still there). Ideally any relative links to other html documents would also work but thats a bonus.

Upload and unzip it, serve it via nginx?

@jaroel Thanks for your suggestion. We run on a HA environment with multiple servers so we need something that works within the ZODB hopefully and also handles the iframe part automatically.

Just thought there must be something out there already but haven't found one via searching yet.

Similar solutions I've found so far

If the clients budget allows and if no one lets me know about an existing plugin we might build the following

  • custom dexterity object with single upload field for zip or .eml.
  • unzips content into maybe blobs as zope objects? Don't really want use dexterity for this since I don't want users to edit, have this content indexed as seperate content items
  • custom view to have an iframe
  • custom text indexer which grabs any html content and combines it.
  • some js to handle automatic resizing of the iframe
  • not sure yet how to handle security on the subobjects so they obey the primary objects workflow state.

Doesn't matter. Whats wrong with an NFS share to upload to and serve from?

I'd just go with the following.

  • NFS share for upload/serve
  • A view that renders an iframe with an URL
  • An upload form that extracts whatever you upload to the share.
  • Use nginx autoindex to navigate the directory structure (if no index.html).

Sorry I should be clear about my requirements. This is for a client that needs to upload newsletters on a regular basis. The newsletters a generated with all the included css, js etc.
Assuming there is no existing plugin and I have to code my own I don't see a lot of difference between extracting the content in the zodb vs the the filesystem other than that NFS shares, custom nginx config etc complicate my infrastructure/security story.

Maybe you can access the files contained in the archive on-the-fly, without decompressing the whole archive upfront. I know it is pretty straightforward to do this with ZIP files. You could implement a view that works like this: my-zip-archive/@@archive-view/contained-folder/contained_file.html. With this view and if the links in HTML file are all relative, then you can use the view to display it in an iframe.

I think to meet your requirements you'll need to implement the solution yourself. I have had to implement something very similar and did not found an add-on for this.

I end up using atreal.massloader which allows to upload a ZIP file and it gets unpacked into individual File and Image content items inside a folder. I had also to implement a view to Folder items which displays a page with an iframe, pointing to the index.html inside the folder.

GitHub - collective/collective.archiveviewer: Allow to access archive files´ contents into Plone already implements this. I'd just have to extend it to put a iframe view on it. I suspect its going to be hard to make it such that it doesn't use a lot of CPU and RAM however.

@djay unfortunately I didn't know pretaweb.externalapp - I might have used it. However, collective.remoteproxy is configurable TTW and handles links on the same domain/path as if they were within Plone - including to other configured remoteproxy content objects.
That could help with your requirement although for the iframe a custom view would be necessary.

@thet The only reason I mentioned you is not to solve my immediate problem but just to let you know that pretaweb.externalapp solves the exact same problem as you wrote collective.remoteproxy for (and is configurable TTW) but does it in a different way such that it doesn't result in blocking external proxy requests inside plone which can have an adverse performance impact. I'm sure its too late for your purposes but if it this usecase ever comes up again, at least its documented.