Mirador Viewer not showing images anymore after php version upgrade

Omeka S Modules
1

Hi all

I have an Omeka-S instance with IIIF modules running on shared hosting. The Omeka-S version is 4.1.1 and the IIIF modules (IIIF server, Image server and Mirador Viewer) are all the latest versions (respectively: v3.6.26, v3.6.20 and v3.4.11).

That hosting environment currently runs php version 8.1, which is EOL at 31/12/2025. So I switched to php version 8.3, because - if I am not mistaken - Omeka-S v4.1.1 is supposed to run on php versions 8.1 till 8.3.
After the switch everything works fine, however in Mirador Viewer, no images are shown anymore, but no error messages whatsoever are given either. This is not the case when I switch from Mirador Viewer to Universal Viewer again, but I specifically switched from using Universal Viewer to Mirador viewer recently because the latter can show several images next to each other, something which Universal Viewer still can’t.

My question: is this only Mirador related and - if so - what can I do to fix this, or is this known and solved in Omeka-S v4.2, so I have to upgrade?

Thank you in advance,
Wim

2

If you’re using the Mirador Viewer module I don’t think Omeka S 4.1 vs 4.2 will matter really… we do ship Mirador and have a viewer that uses it but that’s different than the module you’re talking about.

I’d be surprised that the PHP version itself would make much of a difference here, but it is possible.

Can you share a link to a page showing the problem? The browser’s console might log something useful, or the HTML of the page might reveal what’s happening.

3

Hi John,

I have switched the site to php v8.3 again, so no images show up anymore in the Mirador Viewer. You can check this on all items over here: https://wrijfsels.cannedit.org/s/librije-zutphen/item.

I hope you can help.
Wim

4

There’s an error happening when trying to load the tiles. If you do either the “display” or “log” options on this manual page you should get an actual error message that should indicate what the problem is.

I suspect given where the failure is that this is happening in either the IIIF Server or Image Server modules.

5

I have now enabled the display of error details as you suggested and it says (on your “load the tiles” url): “Service with name “Omeka\Cli” could not be created. Reason: Neither “proc_open()” nor “exec()” are available.” I am afraid I can’t enable these php functions on my shared hosting account. So if there’s no remedy for this I have to switch back to php v8.1.

6

If there’s no option then that may be the case… I’m not sure if Image Server can work under those conditions, you’d have to ask the developer to be sure.

But, possibly this is something you can configure in your hosting? The only reason I say this is that there really isn’t any reason that these functions should be blocked in 8.3 but not 8.1. That’s likely just a difference in the configuration between the two rather than something inherent in those versions.

7

I have switched the php version back to v8.1 and now everything works fine again.

I agree with you that it’s a strange situation, but after further investigation, involving two different shared hosting accounts (so from two different hosting providers), both having disabled “proc_open()” and “exec()” functions in all their php versions from v8.1 to v8.4 (like probably most shared hosting providers), it got even weirder.

After installing a new Omeka-S v4.1.1 instance in any of the php versions v8.1 to v8.3 and then trying to install the latest versions of the IIIF modules: Common (v3.4.74), IIIF server (v3.6.26), Image server (v3.6.20) and Mirador Viewer (v3.4.11), I immediately ran into the “disabled proc_open and exec()”-error[*] from the start, so immediately after trying to install Common v.3.4.74 from scratch. This happens in php versions 8.1, 8.2, and 8.3 (and the same in a new Omeka-S v4.2 instance running on php v8.4).
But when I downgrade to Common v3.4.73, I don’t get this error. After that, installing IIIF server v3.6.26 works immediately, but when I try to install Image server v3.6.20, I get the same “disabled proc_open and exec()”-error, although after refreshing the page it looks like the module did install. The downgrading trick unfortunately doesn’t work for Image server: I tried all older versions for Omeka-S v4.x with the same result.
Finally, when trying to install Mirador Viewer v3.4.11, I get the message that this version only works with the latest version of Common, so v3.4.74. Then the weird part starts: I can upgrade Common v3.4.73 to v3.4.74 without a problem, after which I can of course also install Mirador Viewer v3.4.11. And then, having Image Server still on an older version, I can also upgrade Image server to v3.6.20 without a problem.
So far, so good you would think. However a test with a new item including an image shows that Mirador doesn’t show the image, exactly like I encountered in my own site. Switching from Mirador to Universal Viewer shows the same. So my guess is that the combination of the latest releases of the modules Common and Image server causes a problem for shared hosting accounts and somehow this doesn’t affect sites which were still on php v8.1 and initially ran older versions of these modules. I hope someone can get to the bottom of this, because otherwise it would really kill the combo Omeka-S - IIIF on shared hosting accounts.

In the meantime: for anyone having a situation like mine, so who wants to upgrade the php version of a shared hosting account (in order to run other applications properly) and still wants to keep an Omeka-S - IIIF site on php v8.1, add these lines at the top of your .htaccess file:

# ========== ADD THIS SECTION FOR PHP 8.1 ==========
<FilesMatch "\.(php4|php5|php3|php2|php|phtml)$">
    SetHandler application/x-lsphp81
</FilesMatch>
# ========== END PHP VERSION SECTION ===============

This will keep the directory or the subdomain for your Omeka-S - IIIF site running on php v8.1, despite any other overall php version set for the account.

[*] = Omeka\Service\Exception\RuntimeException: Neither “proc_open()” nor “exec()” are available.

Best wishes,
Wim