Issue with UniversalViewer/IIF server and linked Omeka S objects

[giocomai]

[significantly redacted question, after some additional checks]

I’ve recently introduced UniversalViewer to show media in an Omeka S installation. Many of the items include links to other Omeka S items, either added directly or through the relevant feature of the 'custom-vocab` module. In UniversalViewer, in the media information panel, these elements are shown as clickable, but the links are actually to the item being currently displayed (so clicking just reloads the current page).

In some cases, however, (all of the same field) the link goes to the correct item page, but on another site of the same Omeka S installation, which is due to generate some confusion.

The issue is not within UniversalViewer, but can be seen already looking at the manifest, so I suppose it’s an issue with IIIF Server.

I’m running the stable version 3.5.16, but links do not work also on updated test server with the new 3.6 beta. On the updated beta, however, the link is always to the current page, and I do not seem to have the more unusual issue with active links to the right item on a different site.

Any suggestion on how to deal with it? Having the correct links is of course best, but no links at all would be better than the current state.

[giocomai]

After some further troubleshooting, I seem to have reached the point where I see separate issues:

1. the first is empty links in the manifest (and thus in UniversalViewer), as described in this GitHub issue: this can be solved as described there for version 3.5.16 of IiifServer (things have moved slightly in the current development version, so the fix does not apply any more so directly);

If I fix this as suggested there, I still have the two following issues:

1. the links in the manifest are to one of the sites of the Omeka S installation, that is neither the current site not the main site (so, not the one the base domain defaults to). Again, this is with versione 3.5.16 of IiifServer
2. omeka S items linked through the custom-vocab module still have empty links, so I wonder if there’s something to be checked on that side of things (even if the links work alright out of UniversalViewer).

As I see there’s active development going on in the IiifServer repository, I’ll probably wait a bit before trying to troubleshoot this further. I of course remain very much available for further testing if useful.

[Daniel_KM]

Yes, I’m fixing many issues to finalize integration of iiif 3.0, that is released since the beginning of June.

[giocomai]

Thank you so much @Daniel_KM, excellent work, and good to know you’re working on the latest version!

In the meantime, until the updates come out and just in case somebody stumbles upon similar issues, I’ll leave here a brief outline of how I got a temporary fix for this… the fix is not fancy, but gets me much closer to what I wanted.

With Iiif server 3.5.16, it basically boils down to editing:

modules/IiifServer/src/View/Helper/IiifManifest.php

And change the if block just under $valueValues = array_filter(array_map(function ($v) use ($publicResourceUrl) {

to the following:

                if (( $v->type() === 'resource' || $v->type() === 'resource:item' || $v->type() === 'customvocab:3' ) && $r = $v->valueResource()) {
                    return '<a class="resource-link" href="https://example.com/s/main_omeka_site/item/' . $r->id() . '/">'
                        . '<span class="resource-name">' . $r->displayTitle() . '</span>'
                        . '</a>';
                }

With customvocab:3' being the specific custom-vocabulary based on Omeka items that otherwise wouldn’t get the link.

This allows me hardcode my main Omeka S site (rather than the other Omeka site from the same installation that appeared there for whatever reason), and fix the issue with custom-vocab.

In my ideal case, rather than hardcode the main Omeka S site, the link would just go to “…/:id”, so that it would remain on the current site, but for if I put “…/” rather than the domain, I see it as I wish in the manifest (i.e. a relative link), but not in UniversalViewer (again, empty link there). [I understand that a relative link would be technically wrong in the manifest, but still, assuming the IiifServer is there only for Omeka and has no expected external use, then this would work]

Finally, by default links in metadata fields of UniversalViewer are opened in a new tab, while I think it should remain in the same tab, similarly to what other links from metatada in Omeka S usually do.

To fix this, I edited modules/UniversalViewer/asset/vendor/uv/lib/MetadataComponent.js, replacing “_blank” with “_self” there.