Issue setting up Iiif Search module

I’m attempting to get Iiif Search working on an Omeka S site. I’ve installed Universal Viewer, Iiif Server, Image Server, and Extract OCR. I’m having some trouble getting Extract OCR to write to the correct directory, but that’s a routing error I think we can sort out.

My simpler issue is that in the Iiif Search documentation, it says " * In IIIF Server’s settings → IIIF Search url add iiif-search url : http://yourdomain/omeka-s/iiif-search/" and there’s no IIIF search setting at all in the config page for the Iiif Server module. I am using the latest version of each of these modules.

Has there been a chance in this module config that is not reflected in the documentation?


1 Like

Ho you’re right, i’m in the process of installing it as well, and i don’t see this option anywhere


Look here


At line 271

// Special route for the dynamic collections, search or browse pages.
                    // This route is not standard.
                    'set' => [
                        'type' => \Laminas\Router\Http\Segment::class,
                        'options' => [
                            'route' => '[/:version]/set[/:id]',
                            // Ids are in the query: "?id[]=1&id[]=2", but may be "?id=1,2"
                            // or in route: "/set/1,2".
                            'constraints' => [
                                'version' => '2|3',
                                // 'id' => '(?:\d+\,?)*',
                                'id' => '[^\/]*',
                            'defaults' => [
                                'version' => $version,
                                'action' => 'list',

I have no idea from there tho. And since my installation isn’t that far, i can’t try it

Please do copy your config if you manage to get it working

Additionnaly, Have you been able to run ExtractOcr correctly ?

I can’t manually upload an xml because the system won’t let me, saying it’s an unsupported type,
I see that a value attache to my pdf media is modified by the content (but the raw content, no xml tags with it) but whe i run the API call, it returns that there is no xml associated

No, we don’t have ExtractOct working yet. We’re getting a routing error when pdf2html attempts to convert the pdf to xml, and our Systems Librarian is exploring the issue.

I assumed the edit to the Iiif Search module was to be made in the admin UI. Your note to look at the config.php file is a good one, though I’m not sure how/where I’d add the code specified in the documentation to the config php file, since the text to add in the documentation doesn’t seem to match anything in the config in terms of content or format. Have you managed to figure out how to add it at line 271?


The params may have been changed, but the feature is still available. The search is a service to add inside a manifest, so there is an event and if iiif search is installed and if the item can be searched, the module IiifSearch adds the service to the maniffest.
You need to have last version of IiifSearch and IiifServer, or a version compatible between them. Note that there is a bug in versin that is fixed but i just see that there is no version, so it may be the issue.
I’ll publish the alto version in a few days, so version 3.3.3.

Thanks for chiming in, Daniel. Yes, I’m using version of the iiif Search module, so I’ll be on the lookout for 3.3.3.

To confirm, it’s expected that I’m no longer seeing a search url option in the iiif Server module settings? So if I install 3.3.3 when it’s available, it ought to just work?

Thanks again,


I published a new version of IIIF Search that manages Alto natively. Use my repository, it is not yet included upstream. The module IIIF Server has been updated to support alto too, so the viewer can add an extra layer with the text.

Simply attach the alto files to the item. For now, the filename should be the same than the image one (except extension). A future version will use preferably a linked value between the medias. See readme.

Here with Mirador, but i works with Universal Viewer too.


Thanks, Daniel! We’ll give this a try.

Hi @Daniel_KM – I’ve installed the updated versions of both module (iiif search 3.3.3 and iiif server, and since we’re having issues with the ExtractOCR module, I tried to create an alto test file with Tesseract and load it alongside the pdf. I double checked that it’s an alto v3 file, and the universal viewer seems to recognize it and displays the search box, but when I attempt a search for a known string in the document (one that I verified is in the xml file), the search never resolves, the progress indicator just spins endlessly. Any ideas what might be happening here?

@Daniel_KM, thank you!

@astrohm – When you use this url structure to test whether search is working, what happens? (edited the url)

When I test with this url, I see that search is working. However, unlike you, I don’t have a search box in Universal Viewer. @Daniel_KM any idea why search box isn’t displaying even though search seems to be working?

That url test had me a little confused, actually. I’m having trouble getting anything but a “controller not found” 404 error, but I assume that has something to do with our URL conventions on this VM. When you use that URL, are you putting an extant item id into it?

Apologies, the url I included still had a subdomain in it. I edited the url to what it should be. What happens for you now?

I’m still getting a 404 error on your URL, and on my own.

I’ve made some progress here, but I’m still stuck. I installed Mirador, which was a little more helpful and verbose, and when I attempt a search, I get an error that says "SyntaxError: Unexpected token ‘<’, "<!DOCTYPE “… is not valid JSON”

I can see the annotations in the Mirador viewer, so I know that the alto xml file is being read, though I’m not getting any movement of the document in the viewer when I click on an annotation.

I think I’ve narrowed my issue down to the URL the iiif Search module is attempting to use. If I look at a manifest, all of the other URLs included in the manifest seem to resolve, but rootURL/iiif-search/itemNumber doesn’t resolve.

I had thought this was maybe a URL rewrite issue, but the other URLs are resolving, so I’m not sure. Any ideas?

Thanks in advance!

Did you use iiif v2 or v3?

For the issue on the doctype, it seems that mirador is confused between xml and json.

This feature is complex, there are many alto variants, various mixed media, iiif options, etc. and the simplest way to check it is to see it in real life. So you can send me the whole manifest and the api item json, here or via a private message. If it is an issue in the module, i’ll fix it.

I’ve attempted to use both iiif v2 and v3. Right now, I’m using v2, though I’m open to using v3 if it works.

The manifest of our test item is here:

The JSON LD is here:

Let me know if you see anything that looks amiss on our end - thanks!


Thanks for chiming in, Daniel. Yes, I’m using version of the iiif Search module, so I’ll be on the lookout for 3.3.3.

@beetecaste, version 3.3.3 of the module is available now (GitHub - symac/Omeka-S-module-IiifSearch: IIIF Search is a module for Omeka S that add IIIF Search Api for ocr content.). I’m still having some issues getting everything to work, but maybe you’ll have luck with it!

Okay, Thanks and regards.

Did you have any luck sorting out why rootURL/iiif-search/itemNumber doesn’t resolve?

I’m experiencing this and also thought it was a rewrite issue, but because the other URLs are resolving, I’m also not sure that’s the problem.

All URLs in the manifest begin with https except for the one the IIIF search module is trying to use. I’m not sure if it’s possible to correct this within the module or if this is a server-level issue.