WordPress og en gammel PHP-applikasjon: 9 steg i riktig rekkefølge

PHP 8.2 mister sikkerhetsstøtte 31. desember 2026. WordPress anbefaler allerede PHP 8.3 eller nyere, og 8.3 gikk selv ut av aktiv støtte ved utgangen av 2025. PHP 8.1 og alt eldre er helt ute. Webhotellene kommer til å flytte versjonen videre enten siden din er klar eller ikke.

På en ren WordPress-side er den oppgraderingen som regel udramatisk. På en side der WordPress står ved siden av en eldre egenutviklet PHP-applikasjon, er den den vanligste enkeltårsaken til at en side som virket, slutter å virke.

Slike oppsett finnes overalt. En bedrift bygger et eget system for ordre, booking eller kundeportal, legger WordPress oppå noen år senere for markedssidene og bloggen, og etter hvert deler de to webhotellkonto, domene, viderekoblingsregler og ofte databaseserver. Det går fint i årevis. Så ryker noe, og symptomet dukker opp i det ene systemet mens årsaken sitter et sted begge to er innom.

Kort versjon: feilen vises i det ene systemet, årsaken ligger som regel i laget begge står på. PHP-versjonen, ruting-reglene, databasen eller rettighetene. Dette er rekkefølgen vi jobber i når vi får en slik side i fanget. De sju første stegene endrer ingenting. Det er med vilje.

Derfor knekker hybride oppsett annerledes

En vanlig WordPress-side har en forutsigbar form: kjerne, tema, plugins, database, opplastinger, serverkonfigurasjon. Går noe galt, er listen over mistenkte kort.

Et hybrid oppsett legger til en applikasjon nummer to, med sin egen ruting, sine egne databasespørringer, sine egne antakelser om PHP-versjonen og sine egne filstier. Ingen av dem vet at den andre finnes. Begge styres av den samme .htaccess-filen, kjører på den samme PHP-handleren og deler den samme minnegrensen.

Derfor blir feilene rare. En WordPress-side gir 404 på grunn av en rewrite-regel skrevet for den gamle applikasjonen i 2016. En PHP-oppgradering fjerner en WordPress-advarsel og knekker et egenskrevet kasseskript. En plugin får skylden for en feil som egentlig er en filrettighet som ble liggende igjen etter en flytting.

Feilen vi ser oftest, er at symptomets plassering blir behandlet som problemets plassering. Det er den som regel ikke.

1. Kartlegg hvilket system som eier hva

Før du rører noe: slå fast hvilken applikasjon som er ansvarlig for hvilken del av siden. Spørsmålene det er verdt å svare på:

• Kommer forsiden fra den gamle applikasjonen eller fra WordPress?
• Ligger WordPress i webroten eller i en undermappe?
• Deler de to en database, eller bare en databaseserver?
• Hvem håndterer innlogging, kundekontoer og skjemainnsendinger?
• Hvilket system genererer hovedmenyen, og hvilket serverer 404-siden?

Overraskelsene kommer som regel parvis. En side som ser ut som WordPress viser seg å være en gammel mal som laster wp-load.php for å hente inn innhold. En side som ser gammel ut viser seg å være en WordPress-sidemal ingen har dokumentert. Før du vet hvilken som er hvilken, finnes ikke kategorien «trygg endring» på denne siden.

Skriv det ned et sted den neste personen finner det. På de fleste hybride oppsett vi arver, finnes ingen slik oversikt, og å rekonstruere den er en reell andel av den første fakturaen.

2. Sjekk PHP-versjonen, også overstyringer per mappe

Moderne WordPress vil ha en PHP-gren som fortsatt støttes. Gammel kode overlever ofte ikke en. De bakoverinkompatible endringene i PHP 8.0 er der mesteparten av skaden skjer: strengere typebehandling i regneoperasjoner og strengoperasjoner, fjernede funksjoner, og advarsler som er oppgradert til fatale feil. Kode som haltet videre på PHP 7 med notiser skrudd av, stopper helt.

Det folk overser, er at et hybrid oppsett ofte ikke kjører på én PHP-versjon.

Apache lar deg sette PHP-handleren per mappe, og det er nøyaktig det noen gjør når den gamle applikasjonen ikke vil kjøre på versjonen WordPress trenger. Resultatet er en side med PHP 8.4 i roten og PHP 7.4 i en undermappe, og ingenting noe sted som sier fra. Det er en legitim kortsiktig løsning og en reell felle senere. Det finnes et godt dokumentert tilfelle i støtteforumet til WordPress der en side rapporterte PHP 7.4 mens serveren kjørte 8.3, fordi en glemt .htaccess inne i wp-admin låste en gammel handler. Tre personer så på saken før noen fant fil nummer to.

Sjekk altså versjonen, og sjekk den så på nytt fra innsiden av hver mappe som betyr noe. Noter samtidig minnegrensen, maks kjøretid, grensene for opplasting og POST-data, innstillingene for feilrapportering, og hvilke utvidelser som faktisk er lastet.

Å nedgradere PHP for å få feilen til å forsvinne er fristende og som regel feil. Det kjøper deg noen måneder og legger en uoppdatert kjøretid til en side som allerede har gammel kode på seg. Det bedre spørsmålet er om den inkompatible koden skal repareres, erstattes, eller isoleres bak sin egen handler med en frist knyttet til seg.

3. Les loggene før du rører noe

En blank side forteller deg ingenting. En generisk 500 forteller deg litt mindre enn det. Loggene er der beviset faktisk ligger, og på et hybrid oppsett finnes det som regel flere sett: PHP-feilloggen, feilloggen til webserveren, webhotellets egen feilrapportering, og WordPress sin debug-logg hvis den er skrudd på.

Trenger du å skru på feilsøking i WordPress, skriv den til fil i stedet for til skjerm. På en side i produksjon lekker WP_DEBUG_DISPLAY satt til true både filstier og stack traces til hvem som helst som er innom.

Det loggene avgjør raskt: hvilken fil som kastet feilen, om feilene startet i samme øyeblikk som en PHP-oppgradering, om en viderekobling går i loop, om siden treffer minnetaket, og om det er databasetilkoblingen som svikter. Uten dem endrer du ting og ser hva som skjer, som er den tregeste metoden som finnes og den som oftest legger feil nummer to oppå den første.

4. Rydd opp i .htaccess og viderekoblinger

På Apache-hosting styrer .htaccess permalenker, tvungen HTTPS, www-håndtering, tilgangsbegrensninger, cache-hoder og ofte PHP-handleren i tillegg. På et hybrid oppsett styrer den også rutingen til den gamle applikasjonen.

Der ligger konflikten. WordPress skriver om alt som ikke er en ekte fil eller mappe til index.php. PHP-applikasjoner med en sentral inngangsfil gjør nøyaktig det samme mot sitt eget inngangspunkt. Begge reglene er riktige hver for seg. Sammen vinner den som står først, og den andre applikasjonens URL-er forsvinner.

Les filen i roten, og deretter hver eneste .htaccess i en undermappe, for det er i de ingen husker at overraskelsene ligger. Se etter dupliserte viderekoblinger, regler lagt inn av plugins, regler som peker på filer som ble slettet for flere år siden, og kjeder der en forespørsel blir sendt videre tre ganger før den lander.

Ta backup av filen før du redigerer den. En eneste syntaksfeil tar ned hele siden, begge applikasjoner samtidig. Vi har skrevet om en viderekoblings- og SSL-feil på et oppsett med flere domener som tok en hel dag å spore, nettopp fordi konfigurasjonen lå spredt over Apache, NGINX og Cloudflare uten ett sted å lese den samlet.

5. Vurder WordPress for seg

Uavhengig av den gamle siden: ta stilling til selve WordPress-installasjonen. Kjerneversjon, aktive og inaktive plugins, struktur på tema og undertema, egen kode i functions.php, must-use-plugins, cron-jobber, innstillingene for side- og hjemme-URL, og listen over administratorer.

Det som er annerledes på et hybrid oppsett, er oppdateringspolitikken. På en frittstående side er det rimelig å oppdatere plugins i bulk med backup og en testkopi i bakhånd. Her kan en oppdatering skrive om delte viderekoblingsregler, endre databasespørringer den gamle applikasjonen også leser, eller endre skjemahåndtering den andre applikasjonen er avhengig av. Oppdater i små puljer, og test begge applikasjoner etter hver pulje, ikke bare den du rørte.

6. Se på hva som er endret nylig

Endringsdatoer snevrer inn søket raskt. Nylig endrede PHP-filer, tema- og pluginfiler, .htaccess, wp-config.php, konfigurasjonsfiler for den gamle applikasjonen, og alt uventet som ligger i en systemmappe.

Ikke alle nylige endringer er mistenkelige. Automatiske oppdateringer, cache-lag og backup-plugins skriver filer under helt normal drift. Det du leter etter, er en endring som faller sammen med da problemet startet: en halvferdig oppdatering, en manuell redigering, en mislykket utrulling, en overskrevet konfigurasjon, eller en flytting som nullstilte stier og rettigheter.

Finner du en fil du ikke kan gjøre rede for, hold igjen på å dømme den ut fra hvordan den ser ut. Vi har skrevet om en fil som hadde alle synlige kjennetegn på en bakdør og var helt legitim, og metoden som avgjorde den saken gjelder for alt du finner her: knytt filen til en installasjonshendelse før du bestemmer deg for hva den er.

7. Sjekk fil- og mapperettigheter

Rettigheter som er for stramme, hindrer serveren i å lese filer den trenger. Rettigheter som er for åpne, er et sikkerhetsproblem i seg selv. Begge deler dukker opp etter flyttinger og gjenopprettinger, som hybride oppsett går gjennom oftere enn de fleste.

Verdt å gjennomgå: rettigheter på mapper og filer, eierskap, om opplastings- og cachemapper faktisk er skrivbare, om loggfiler er lesbare for prosessen som trenger dem, og om konfigurasjonsfiler er skjermet fra offentlig tilgang. WordPress publiserer et utgangspunkt, men de riktige verdiene avhenger av hvordan webhotellet ditt kjører PHP.

Ikke løs dette med én rekursiv kommando over hele kontoen. Det er den raskeste måten å enten eksponere en konfigurasjonsfil eller ta fra den gamle applikasjonen muligheten til å skrive til sine egne mapper.

8. Ta backup av begge databasene, og test at den lar seg gjenopprette

Alt over er lesing. Dette er det første steget som rører noe, og det er det som gjør resten mulig å overleve.

Backupen må dekke nettstedsfiler, WordPress-databasen og databasen til den gamle applikasjonen, i tillegg til konfigurasjonsfiler, .htaccess, opplastet media og cron-oppføringer. Hybride oppsett er nettopp der de halve backupene oppstår, fordi den som satte opp backupverktøyet pekte det mot WordPress og aldri fikk vite om database nummer to.

En backup du ikke har gjenopprettet, er ikke en backup. Bekreft at arkivet ble ferdig, at databaseeksporten er gyldig og ikke avkortet, at det finnes nok lagringsplass til en gjenoppretting, og at du vet omtrent hvor lang tid en tilbakerulling tar. For alt som er forretningskritisk: jobb på en testkopi i stedet, slik at kompatibilitetsfikser blir testet et sted som ikke er produksjon.

Ett norsk poeng til: ligger ordrer, fakturaer eller kvitteringer i den gamle applikasjonen, kan de være oppbevaringspliktig regnskapsmateriale. Oppbevaringsplikten forsvinner ikke fordi systemet er gammelt eller fordi ingen bruker det lenger. Sjekk hva som faktisk gjelder for din virksomhet før noe slettes eller migreres bort, ikke etterpå.

9. Gå gjennom sikkerheten i begge systemene

Gamle applikasjoner lever lenger enn rammeverkene og bibliotekene de ble bygget på. Det som gjerne ligger der: kodeveier som ikke lenger vedlikeholdes, svak passordhashing, utdaterte databasebiblioteker, adminsider uten reell beskyttelse, manglende CSRF-tokens, filopplasting uten begrensninger, eksponering for SQL-injeksjon, backup-arkiver som er offentlig lesbare, og forlatte WordPress-plugins ingen har oppdatert på flere år.

Poenget er at det ikke holder å sikre WordPress. Et PHP-skript ingen vedlikeholder på samme webhotellkonto er en vei inn, og når noen først er inne, er WordPress på samme konto. Sikkerhetsveiledningen til WordPress-prosjektet dekker den ene halvdelen av problemet. Den egenutviklede applikasjonen trenger sin egen gjennomgang.

Da vi ryddet opp i en kompromittert VPS med ti nettsteder og uten root-tilgang, var inngangspunktet ikke den siden som så verst ut. Det er det sjelden. Er du usikker på hva som ligger eksponert, er det det en sikkerhetsgjennomgang er til for.

Integrasjonene som ryker først

På norske hybride oppsett er det sjelden forsiden som knekker først etter en PHP-oppgradering. Det er integrasjonene, og de knekker stille.

Typiske kandidater: egenskrevne betalingsintegrasjoner mot Vipps eller eldre Nets- og DIBS-endepunkter, fraktintegrasjoner mot Bring, nattlige eksportjobber til regnskapssystemet, og oppslag mot offentlige registre. Dette er kode som ofte ble skrevet én gang for mange år siden, aldri rørt siden, og som kjører i bakgrunnen uten at noen ser på den.

To ting skjer samtidig med dem. PHP-oppgraderingen knekker koden, og leverandøren har i mellomtiden byttet ut endepunktet eller autentiseringsmetoden koden bruker. Da er det ikke lenger en kompatibilitetsfiks, det er en ny integrasjon.

Det praktiske rådet er enkelt: etter en PHP-oppgradering holder det ikke å klikke seg rundt på siden i en nettleser. Sjekk at cron-jobbene faktisk kjørte, at siste ordre kom fram til regnskapssystemet, og at betaling og frakt fungerer ende til slutt i en testbestilling. En ødelagt bakgrunnsjobb oppdages ellers først ved månedsavslutning, og da er den to uker gammel.

Reparere, vedlikeholde eller modernisere

Ikke alle gamle sider trenger å bygges på nytt, og å bygge om en som ikke trengte det er en dyr måte å gjeninnføre løste problemer på.

Reparasjon passer når feilen er isolert, applikasjonen ellers er stabil, fiksen er trygg å gjøre, og siden har en definert gjenværende levetid.

Løpende vedlikehold passer når systemet fortsatt gjør reelt arbeid, oppdateringer må kompatibilitetstestes før de går live, og noen må følge med på backup og overvåking. Det er posisjonen de fleste hybride oppsett faktisk er i, og det er det vedlikeholdsavtaler er til for. På et hybrid oppsett må avtalen dekke PHP-siden også, ikke bare WordPress-siden, ellers er halve systemet fortsatt uten eier.

Modernisering blir det ærlige svaret når kritiske biblioteker ikke lenger vedlikeholdes, når små endringer stadig knekker ting som ikke hadde med saken å gjøre, når oppgraderinger av hosting eller PHP ikke lar seg fullføre i det hele tatt, eller når den samlede reparasjonskostnaden har passert kostnaden ved å erstatte tingen.

Modernisering trenger ikke bety å bytte ut alt på én gang. WordPress-innholdet kan bli stående der det er mens den egenutviklede applikasjonen bygges om modul for modul. Målet er færre bevegelige deler du faktisk klarer å resonnere om, som er det samme prinsippet som ligger bak å erstatte fire overlappende caching-lag med to verktøy.

Rekkefølgen betyr mer enn sjekklisten

Steg 1 til 7 er undersøkelse. Ingenting endres. Steg 8 er backupen. Først etter det begynner du å endre noe, én endring om gangen, med test av begge applikasjoner etter hver endring og notater på hva du gjorde.

Dette er tregere enn å slå av plugins til feilen forsvinner. Det er også forskjellen på å fikse én feil og å lage tre.

Det som er verdt å ta med seg: på et hybrid oppsett dukker feilen opp i den ene applikasjonen, mens årsaken som regel sitter i laget begge to deler. PHP-versjonen, rewrite-reglene, databasen, rettighetene. Start der.

---

Kjører du WordPress ved siden av en eldre PHP-applikasjon? Vi jobber med slike oppsett: kompatibilitetsproblemer i PHP, konflikter i viderekoblinger og hosting, sikkerhetsgjennomgang av begge systemene, og et ærlig svar på om reparasjon, vedlikehold eller en trinnvis ombygging er riktig valg. En gjennomgang av siden er som regel et fornuftig sted å begynne. Fortell oss hva som skjer, så tar vi en titt.