Het spook in de machine en het dilemma: to fix or not to fix

December 2025: de kalender zei dat ik moest upgraden. Versie 8.1 van php liep ten einde. Als beheerder van een shared hosting account met meerdere projecten voelde de upgrade naar v8.3 of v8.4 als een plicht, een kwestie van digitale hygiëne. Mijn Omeka-S IIIF installatie, mijn pilot voor het ontsluiten van wrijfsels van stempels gebruikt op zestiende eeuwse boekbanden, draaide goed op php v8.1. De basis Omeka-S was weliswaar niet de laatste versie, maar gebruikte wel de nieuwste IIIF-modules en vooral de Mirador viewer deed zijn werk uitstekend. Tot de upgrade naar php v8.3 (de php versie die mijn Omeka-S v4.1.1 volgens de specificaties ook nog aan kon). Na de upgrade draaide Omeka-S ogenschijnlijk nog steeds, maar de afbeeldingen waren verdwenen. Mirador toonde lege canvassen. Ik zag geen overduidelijke foutmeldingen. Dus geen crash, maar een 'silent failure', de ergste soort, omdat die zich voordoet als een geslaagde operatie.

Mijn eerste gedachte: een compatibiliteitsissue met php v8.3. Dus switchte ik terug naar v8.1. De beelden kwamen terug. Case closed? Niet helemaal. Het gevoel bleef knagen, dus begon ik een onderzoek en zette allereerst debugging ‘aan’ in Omeka-S. Hierdoor werd de oorzaak van het falen van Mirador meteen duidelijk: de php-functies “proc_open()” en “exec()” waren blijkbaar nodig en die stonden uitgeschakeld. Logisch, dat is een standaard beveiligingsmaatregel op shared hosting accounts. Maar … dat was dan toch ook al het geval binnen php v8.1 ...

Ik besloot mijn onderzoek uit te breiden met tests op een tweede shared hosting account van een andere provider en ik installeerde op beide accounts een nieuwe, lege Omeka-S v4.1.1 en probeerde vervolgens de laatste versies van de IIIF-modules te installeren. De "disabled proc_open() and exec()"-foutmelding kwam vrijwel meteen, al bij het installeren van de eerste module: Common (v3.4.74). Dit gebeurde op de php versies 8.1, 8.2, 8.3, en zelfs binnen een Omeka-S v4.2 installatie op php v8.4.

Ik draaide de module Common terug naar v3.4.73. Geen foutmelding meer. De module IIIF Server v3.6.26 installeerde daarna zonder problemen, maar bij de module Image Server v3.6.20 verscheen weer diezelfde "disabled proc_open() and exec()"-foutmelding, hoewel - na het verversen van de modules pagina - de module wel geïnstalleerd leek. Een schijninstallatie dus en de downgrade-truc hielp niet: alle oudere versies van de module Image Server vertoonden hetzelfde gedrag.

Het werd nog vreemder. Mirador Viewer v3.4.11 weigerde te installeren tenzij de module Common de allernieuwste (v3.4.74) was. Dus zonder al te veel vertrouwen verving ik Common v3.4.73 weer door v3.4.74 ... en het lukte, zonder foutmelding. Vervolgens installeerde Mirador zich probleemloos. En alsof het een grap was, kon ik daarna ook Image Server naar v3.6.20 upgraden, weer zonder foutmelding.
Ik had nu een complete, 'succesvol' geüpgrade installatie. Tot de test: het aanmaken van een nieuw item met een afbeelding. Mirador toonde een leeg canvas. Universal Viewer ook. De afbeeldingen waren opnieuw verdwenen, precies zoals in mijn oorspronkelijke productie omgeving.

De conclusie was verontrustend en wees op een dieperliggend issue: de combinatie van de laatste releases van de Common- en Image Server-modules introduceert een latent probleem dat specifiek shared hosting accounts treft. Het lijkt erop dat de nieuwe code tijdens installatie al probeert 'verboden' php shell-functies aan te roepen, maar dat dit tijdens een upgrade van een bestaande installatie soms wordt omzeild. Het resultaat is echter hetzelfde: geen afbeeldingen weergave.

De implicatie is groot. Dit is geen simpele php-versie-incompatibiliteit. Het is m.i. een fundamentele mismatch tussen de architecturale aannames van de nieuwste IIIF-modules (die uitgaan van shell-toegang) en de realiteit van beveiligde, multi-tenant shared hosting. Het treft niet alleen nieuwe installaties, maar ook bestaande sites die proberen te migreren naar nieuwere php-versies. Het dreigt de combinatie Omeka-S en IIIF op shared hosting – een optie voor het publiceren van kleinschalig digitaal erfgoed – (ongetwijfeld onbedoeld) de nek om te draaien.

Wat nu? Terugdraaien naar de oude, stabiele versie was de juiste eerste reactie, maar voor de lange termijn is dit niet houdbaar en zijn er deze drie opties:

• Sommige shared hosting providers (zoals de mijne) bieden via de php selector in hun configuratie panel de optie om specifiek voor jouw account de 'disable_functions'-restrictie te omzeilen en bijvoorbeeld "proc_open()" en "exec()" toch in te schakelen. Dit vergroot natuurlijk de kwetsbaarheid van je Omeka-S installatie, maar een actief patch- en upgrade-beleid, een sterke authenticatie en goede controle over eventueel toegestane uploads kan dit beheersbaar houden.
• Onder het motto: "if it ain't broken, don't fix it", kun je je algemene shared hosting account naar een nieuwere php-versie (bijvoorbeeld php v8.3 of v8.4) brengen voor je andere applicaties, maar forceer je je Omeka-S directory of subdomein terug naar de oude php versie (in het onderhavige geval: php v8.1) door deze code regels op te nemen aan het begin van je Omeka-S .htaccess bestand:
  
  Het voordeel van deze optie: je houdt de perfecte, werkende staat van je Omeka-S-IIIF installatie in een geïsoleerde legacy-omgeving, terwijl de rest van je account profiteert van nieuwere php-versies.
  Het nadeel: je loopt op termijn vast op een niet-ondersteunde php-versie. Dit is dus een uitstel, geen oplossing. Maar het geeft je tijd om een eventueel grotere migratie (optie 3) te plannen.
• De enige structurele oplossing is helaas een migratie naar een VPS (Virtual Private Server) of managed hosting, vooral voor een Omeka-S installatie met geavanceerde modules zoals die voor de IIIF functionaliteit. Je gaat dan naar een robuustere omgeving waarvan de prestaties en betrouwbaarheid vaak van aanzienlijk hoger niveau zijn, maar daar hangt ook een hoger prijskaartje aan en het brengt een grotere verantwoordelijkheid met zich mee, voor o.a. beveiliging, updates/upgrades, backups, etc.

Mijn keuze viel voor nu op optie 2 (de php-versie lock), dus voor het principe: "if it ain't broken ..." en dat is geen luiheid, maar kiezen voor een pad dat risico's beheerst. De applicatie leeft nu 'bevroren' in een andere runtime-realiteit en dit 'koopt' tijd.

De les is helder. Voor beheerders: test upgrades niet alleen op functionaliteit, maar op de volledige data-pipeline, en wees beducht op het stille falen. Voor ontwikkelaars: erken de diversiteit aan deployment-omgevingen. Code die shell-toegang vereist, sluit een groot, legitiem deel van je gebruikersbasis uit. En voor de gemeenschap: dit is een signaal. Iemand moet zich in deze code graven en het spook in de machine vinden, want anders verdwijnt een belangrijke, eenvoudige en goedkope (open source) optie om digitaal erfgoed te ontsluiten.