-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use M3 instead of OSD for external IIIF items #1415
Conversation
I'm in the process of updating my External IIIF Analysis spreadsheet and can say with confidence that this is an improvement over the current experience in OSD, especially for manifests w/ several hundred canvases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😬 We are still getting a CORBs error for uploaded items in stage:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://exhibits-stage.stanford.edu/external-iiif-and-upload-images-test-august-2019/catalog/107-6912/manifest. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got some clarification from @cbeer and talked with @caaster about documenting this quirk. Uploaded items will not be visible in viwer until the exhibit is published.
We do see the thumbnails in the Curation > Items
list. External IIIF items do not show a thumbnail in the Curation > Items
list, which is consistent with previous behavior.
Could we feature flag this so that it can stay in stage (so that Cathy can work on service team documentation) without constantly rebasing this branch?
Further QA from colleagues in PSM has revealed a few more errors. There's been some work on tickets in several repos, so I just wanted to tie them all together here. Issue: Thumbnails were not appearing in gallery view for uploaded items. ✅Resolution: Spotlight was creating IIIF manifests for uploaded items w/ strings in the width / height fields. We've changed these to integers in upstream Spotlight (projectblacklight/spotlight#2206) and cut a new release. Pending:
Issue: "Share" URLs ✅sul-embed truncated "Share" URLs for manifests with Pending:
Issue: Titles for external IIIF objects were not human readable ✅This was mostly resolved by #1416. Objects that had this problem will be fixed by reindexing the exhibit. The test exhibit failed reindexing because I tried to add this BSB manifest with multilingual metadata. Pending actions:
Issue: Metadata fields from IIIF objects sometimes display HTML ✅I wouldn't consider this a blocker to rolling out a better a viewer experience (i.e. we had this problem while using OSD too). But it's a tricky issue - do we strip out HTML from these fields? Whitelist a subset? Allow HTML in a few fields? Pending:
|
@cbeer Now that we have proper titles displaying on the show page, we should probably hide the item's title in embedded M3. |
Sure; here's a prereq to doing that in this PR: sul-dlss/sul-embed#1075 |
As of Spotlight v2.10.0, issues with multilingual manifests and HTML appearing in metadata have been resolved. I've documented the issue with uploaded items not displaying in M3 until the exhibit is published in #1439. Given the potential support burden, @caaster and I agreed to split uploads to a separate release to unblock this work. We've come a long way since our last round of QA and have resolved a lot of testers' concerns. We (me and @mejackreed) have sent an inquiry to Keio University Libraries re: serving up manifests via HTTPS. Next meeting with @caaster will focus on support documentation and perhaps adding a beta label and some help text to the "IIIF Url" tab. |
0e7e87e
to
99cb4d6
Compare
Fixes #1216
Fixes #1413
Fixes #1336 (or, rather, makes it obsolete)
Perhaps related to #476 too?