tobifjellner (Tor-Bjorn “Tobi” Fjellner)

När den typen av fel inträffar brukar WordPress försöka att skicka en speciell länk till webbplatsens administratörsadress (en e-postadress som registreras separat från olika användares adresser).

Tyvärr händer det ofta att länken inte kommer fram, och då behöver man falla tillbaka på ”klassisk felsökning” enligt metoderna som beskrivs i https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/

Du kan länka till sidor och inlägg genom att söka fram dem i gränssnittet för menyn.

Om du lägger in länkar manuellt behöver de antingen vara kompletta, med https://webbserver/sida, eller börja med ett snedstreck och den delen av sidans adress som kommer efter det första snedstrecket.

Om du har en sida med adressen https://webbserverns.adress/musik/ kan du lägga adressen som ”/musik/”.

Om du vill att en länk inte ska leda någonstans (eller egentligen: leda till sidan du redan är på), lägger du in länken som ”#”.

Går det inte att ha separata PHP-versioner i en multisite-miljö?

En multisite-installation är en och samma WordPress-installation för hela nätverket, så samma uppsättning filer används för alla webbplatser i nätverket. Om vissa webbplatser i nätverket fortfarande fungerar medan andra fallerar kan det bero på att de använder olika teman och/eller har olika uppsättningar tillägg aktiverade.

så fort jag väljer en nyare version än 7.4 blir samtliga sajter oåtkomliga

Alltså finns det något tillägg eller tema som inte är kompatibelt med PHP 8.

Du kan hitta ledtrådar om vad som är inkompatibelt genom att tillfälligt aktivera PHP felsökning med loggning till fil:

Lägg in följande rader i wp-config.php (före raden med texten ”That’s all, stop editing…”)

// Enable WP_DEBUG mode with logging to /wp-content/debug.log 
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );

Byt sedan till en modern PHP-version och (försök) öppna några sidor.

Kritiska fel kommer att loggas till och där bör det gå att se vilka kommandon som kördes när felet inträffade.

Det är helt enkelt adressen i systemet där PHP 7.4 bor.

Kolla i början av utmatningen om du hittar några länkar till olika .ini-filer.

Jag tror att jag hittat en liten ledtråd.

https://docs.cpanel.net/ea4/php/about-php/ säger ”EasyApache 4 supports PHP version 7.4 and PHP 8.1 through 8.5.”

Så OM du begär en äldre version kommer antagligen den äldsta som stöds att hämtas.

Kan du prova att skapa en fil ”mintestfil.php” med följande innehåll:

<?php
phpinfo();

och lägga den i katalogen där WordPress finns?

När du kör den bör du kunna se vilken eller vilka konfigurationsfiler som körts, mm.

Titta på filer som heter saker i stil med ini, conf etc. i den publika rotkatalogen, men också i eventuella privata kataloger ovanför den publika roten.

Tekniskt är en WordPress ”multisite” en enda webbplats, som styr alla inkommande förfrågningar till samma huvudinstallation.

Om en utvecklare eller webmaster styrt om webbplatsen till en äldre PHP-version kan anledningen vara att hen inte ville gå in och lösa kompatibilitetsproblem där något tillägg eller tema anropar borttagna eller förändrade PHP-funktioner.

Om multi-webbplatsen kan tåla att vara nere någon timme kan du prova att byta PHP-version och kolla vad som händer. Jag skulle aktivera loggning av PHP-fel först för att hitta ledtrådar till var det blir fel. (Se https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/ )

Om nätverket helst bör hållas igång kanske du kan prova att klona det till en staging-miljö.

Börja i vilket fall som helst med att ta ordentlig backup på allting.

Och stäng av felsökningen när den inte längre behövs. Du vill inte att angripare ska kunna sniffa fram fel-loggar som direkt pekar på eventuell föråldrad kod.