Under panseret: webserver, PHP og database

Modul 1: Hvordan WordPress fungerer · Lesetid: 8 minutter

Læringsmål: Etter denne leksjonen kan du forklare steg for steg hvordan et sideforespørsel i WordPress blir til en HTML-side, og hvor en cache forkorter den veien.

Nøkkelbegreper: webserver (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, query, index.php, maldokument-hierarki (template-hierarki), dynamisk vs statisk, TTFB

En statisk og en dynamisk side

På et statisk nettsted ligger hver side som en ferdig fil på serveren. Webserveren henter filen og sender den. Det er raskt og enkelt, men hver endring betyr en ny fil.

WordPress er dynamisk: siden finnes først i det øyeblikket noen ber om den. Det finnes ingen fil contact.html. Det finnes en tekstbit i databasen, et tema med maldokumenter og en mengde PHP-kode som setter de to sammen. Det gir fleksibilitet (du endrer teksten i nettleseren din), men det koster regnearbeid ved hvert besøk. Forstår du det regnearbeidet, forstår du også senere hvorfor et nettsted er tregt, hvorfor caching utgjør så stor forskjell, og hvorfor en PHP-oppgradering kan ødelegge noe.

Reisen til et sideforespørsel

Si at en besøkende åpner https://example.com/contact/. Da skjer følgende:

1. DNS: nettleseren slår opp IP-adressen til example.com (se DNS-kurset). Den oppretter en sikret forbindelse til den adressen.
2. Webserver: på serveren kjører en webserver, for eksempel LiteSpeed, Apache eller nginx. Den mottar forespørselen. Finnes det en virkelig fil eller mappe med det navnet (et bilde, et stilark), sender den det rett tilbake. Hvis ikke, gjelder regelen fra .htaccess (hos LiteSpeed og Apache) eller fra nginx-konfigurasjonen: «send alt som ikke finnes, til index.php».
3. PHP: index.php er en PHP-fil. Webserveren lar PHP, programmeringsspråket WordPress er skrevet i, kjøre den. PHP laster først wp-config.php (innstillingene, med databaseopplysningene), deretter resten av WordPress, deretter alle aktive utvidelser og det aktive temaet.
4. Database: WordPress sjekker hvilket innhold som hører til /contact/, og stiller spørsmål til databasen (MariaDB eller MySQL): hvilken side har slug'en contact, hva er innstillingene for nettstedet, hvilken meny hører til? Et slikt spørsmål kalles en query. En enkel side krever fort titalls queryer; med utvidelser kan det bli hundrevis.
5. Tema: WordPress velger hvilket maldokument i temaet som formaterer siden. Dette skjer etter maldokument-hierarkiet (template-hierarkiet): for en side med slug'en contact leter WordPress først etter et maldokument page-contact, deretter page-<id> (sidens nummer), deretter page, deretter singular og til slutt index. Det første som finnes, vinner.
6. HTML tilbake: resultatet er en HTML-side som PHP gir til webserveren, og webserveren gir til nettleseren.
7. Nettleseren leser HTML-en og henter deretter stilark, skript, skrifttyper og bilder. Disse er vanlige filer, så de kommer rett fra webserveren (eller fra en cache).

Mellom steg 2 og steg 6 ligger tiden serveren trenger for å lage siden. Det ser du igjen som TTFB (time to first byte): tiden mellom forespørselen og den første byten i svaret. På et godt innrettet nettsted ligger den godt under et sekund. I modul 6 måler du dette selv.

Hvorfor hver utvidelse teller

I steg 3 lastes alle aktive utvidelser, ved hver forespørsel. Også når den utvidelsen ikke gjør noe på denne siden. En utvidelse for et fotogalleri lastes altså også når noen åpner kontaktsiden din. Hver utvidelse kan utføre ekstra queryer, laste ekstra kode og legge ekstra skript til siden.

Det forklarer to ting du møter oftere i dette kurset:

• Færre utvidelser er som regel raskere. Ikke fordi antallet i seg selv teller, men fordi hver utvidelse kan gjøre arbeid ved hver forespørsel.
• Én ødelagt utvidelse kan legge ned hele nettstedet. Går noe galt i steg 3 (for eksempel en utvidelse som ikke fungerer med den nye PHP-versjonen), kommer PHP aldri til steg 6. Den besøkende får en hvit side eller meldingen «Det har oppstått en kritisk feil på dette nettstedet» (leksjon 5.4).

Hvor PHP og databasen kommer fra

PHP og databasen kjører på serveren til webhotellet ditt. Du velger som regel selv PHP-versjonen i kontrollpanelet (hos DirectAdmin heter det Select PHP version, se leksjon 8.4). Databasen oppretter du ved installasjonen; installasjonsprogrammet gjør det ofte for deg (leksjon 2.2).

Noen ting å huske:

• PHP-versjon: hver nye PHP-versjon er raskere og sikrere, men gammel kode kan snuble over den. wordpress.org anbefaler for øyeblikket PHP 8.3 eller høyere (per november 2026).
• Database: wordpress.org anbefaler MariaDB 10.11 eller høyere, eller MySQL 8.0 eller høyere. MariaDB er en forgrening av MySQL; for WordPress gjør det ingen forskjell.
• Databasen ligger som regel på samme server (DB_HOST er da localhost). Ved større webhotell-løsninger kan den ligge på en egen server.

Cache: å forkorte veien

Hvis hundre besøkende ber om den samme kontaktsiden, lager WordPress den hundre ganger på nytt uten cache. Hver gang de samme queryene, det samme maldokumentet, den samme HTML-en. En sidecache lagrer HTML-en etter første gang. Den neste besøkende får den lagrede versjonen: steg 3 til og med 6 faller bort.

Zonder cache:  browser > webserver > PHP > WordPress + plugins > database > thema > HTML
Met cache:     browser > webserver > opgeslagen HTML

Det er derfor caching gir den største hastighetsgevinsten (leksjon 6.2). Det forklarer også en vanlig forvirring: «jeg har endret teksten, men jeg ser den gamle versjonen.» Da får du en lagret versjon; etter at cachen er tømt, ser du den nye.

Ikke alt kan komme fra en cache. En innlogget administrator, en handlekurv eller en kassaside er forskjellig for hver besøkende. En god cache-utvidelse hopper over disse.

Headere: det serveren forteller deg

Hvert svar fra en webserver begynner med headere, før HTML-en. De ser du ikke på siden, men du ser dem i utviklerverktøyene i nettleseren din (F12, fanen Nettverk, klikk på den første forespørselen). Et eksempel:

HTTP/2 200
server: LiteSpeed
content-type: text/html; charset=UTF-8
link: <https://example.com/wp-json/>; rel="https://api.w.org/"
x-litespeed-cache: hit

• server sier hvilken webserver som svarer.
• link med wp-json avslører at det er WordPress.
• x-litespeed-cache: hit betyr at denne siden kom fra LiteSpeed-cachen. Andre cacher bruker andre navn, som x-cache: HIT eller cf-cache-status: HIT hos Cloudflare.

Du trenger ikke kunne disse linjene utenat. Men den som kan lese dem, kan finne mange problemer selv.

Oppsummering

• WordPress lager hver side i det øyeblikket forespørselen kommer: webserver, PHP, utvidelser, database, tema, HTML.
• Ved hver forespørsel lastes alle aktive utvidelser; én ødelagt utvidelse kan stoppe hele nettstedet.
• Maldokument-hierarkiet avgjør hvilket maldokument i temaet som formaterer en side.
• En sidecache hopper over regnearbeidet ved å gi lagret HTML. Innloggede brukere og handlekurver hører ikke hjemme i den cachen.
• Headerne i et svar forteller hvilken webserver som svarer, og om siden kom fra en cache.

Quiz

Oppgave

Oppgave A1.2: Les headerne til nettstedet ditt. Åpne ditt eget nettsted (eller wordpress.org) med utviklerverktøyene i nettleseren din (F12, fanen Nettverk, oppdater siden, klikk på den første forespørselen). Skriv inn hvilken webserver som står i headeren server (eller «ingen» hvis den ikke finnes), og om det finnes en header som sier at siden kom fra en cache (hvilket navn og hvilken verdi). Programmet henter den samme siden og sammenligner.

Les mer

Disse artiklene beskriver stegene i kontrollpanelene til WebOké; i andre kontrollpaneler fungerer de på lignende måte.

• DirectAdmin-veiledning 1.9: Begreper forklart: domene, subdomain, pointer, DNS, mailbox og database
• DirectAdmin-veiledning 14.1: Velge PHP-versjon (Select PHP version)
• Gratis DNS-kurs 1.4: Reisen til en DNS-forespørsel
• Maldokument-hierarki (template hierarchy) (developer.wordpress.org, engelsk): https://developer.wordpress.org/themes/basics/template-hierarchy/