Serve Mirador through an iFrame
Closed this issue · 3 comments
On one of our projects, we want to show the Mirador viewer inline with the node fields.
However, when I stick the block in this place, copying the approach of the field formatter, the viewport comes out of its parent
It turns out that the Mirador app also lives inside its own
element so it's probably conflicting styling that's causing the problem.Looking at both Stanford's (https://exhibits.stanford.edu/jarndyce-test/catalog/qs858rw6303?search=gotty) and Harvard's (https://wiki.harvard.edu/confluence/display/LibraryStaffDoc/Mirador+iFrame+Test+Page), Mirador is embedded in an iFrame.
This seems to be the standard practice so I think we should follow it.
To do this we would need:
- A controller that serves nothing but the rendered Mirador app,
- Change the Mirador block to render an iFrame containing the above. A pointer to the manifest and any relevant query parameters representing search terms and / or page would need to be passed in.
Thoughts from @Islandora/committers especially @adam-vessey @ajstanley @rosiel very much welcome.
👋
I don't think an iframe is a requirement for Mirador; we have an embedded test with positioned elements that works fine: https://mirador-dev.netlify.app/__tests__/integration/mirador/embedding.html
Seems to be working fine here, with the block embedded (making use of #22, but unsure if anything there might somehow fix whatever issue you're encountering?)?
That said, not opposed to having another alternative in addition to the present block/field implementations to do iframe things if we really want it, but unsure where it would ideally live. Vague recollections of the past, but: Generating plain unthemed pages of HTML in the Drupal context can get kind of weird... I feel like I could probably dig some up that's been done in the past, at least in D7 stuff.
There might be some funky Z-ordering stuff between Mirador's "workspace navigation" sidebar/panel and the admin toolbar dealio from Drupal, but that should be easily enough addressed with a bit of CSS overriding, one way or another.
This turned out to be a quirk of our particular theme.
FWIW the fix was to add a position: relative to the div that holds the Mirador wrapper block.