- Udgivet
- Opdateret
Historien om PHP – og hvorfor sproget er værd at fejre
PHP’s historie handler ikke om et sprog, der fra begyndelsen fulgte en elegant og færdig plan. Det begyndte med et praktisk behov, voksede ud af ét personligt projekt og bredte sig, fordi andre udviklere kunne bruge det til at bygge noget nyttigt på nettet.
Den ujævne begyndelse er en del af grunden til, at PHP er værd at fejre. Sproget gjorde backendudvikling mere tilgængelig, blev grundlag for både publiceringssystemer og forretningskritiske applikationer og moderniserede sig flere gange uden at kræve, at alle eksisterende projekter begyndte forfra.
PHP’s 30-års jubilæum i 2025 var en god anledning til at se tilbage. Den mere holdbare historie er, hvordan en samling personlige webværktøjer blev infrastruktur for en stor del af nettet – og hvad udviklere kan lære af den udvikling.
1994–1995: Et personligt behov bliver til åben kode
Rasmus Lerdorf skabte de første PHP-værktøjer i 1994 som CGI-programmer skrevet i C. Opgaven var personlig: at registrere besøg på hans online-CV. Efterhånden fik værktøjerne formularhåndtering og adgang til databaser, så de kunne bruges til enkle dynamiske sider og ikke kun til besøgsstatistik.
I juni 1995 gjorde Lerdorf kildekoden offentligt tilgængelig. Den officielle historie om PHP beskriver, hvordan det gav andre udviklere mulighed for at bruge værktøjerne, rette fejl og forbedre dem. Projektet skiftede mellem navne som Personal Home Page Tools, Forms Interpreter og PHP/FI, mens det udviklede sig fra en samling hjælpeværktøjer til noget, der lignede et egentligt programmeringssprog.
Den vigtigste idé var allerede synlig: Webudvikling skulle være direkte. En udvikler kunne modtage input, hente og gemme data og generere HTML uden først at bygge en stor softwareplatform.
PHP 3 gør et personligt projekt til et fælles sprog
Den afgørende forandring begyndte, da Andi Gutmans og Zeev Suraski i 1997 gik i gang med at omskrive parseren. De havde brug for et stærkere værktøj til en e-handelsapplikation og indledte et samarbejde med Lerdorf om et nyt sprog med udgangspunkt i det eksisterende fællesskab omkring PHP/FI.
PHP 3 udkom i 1998. Navnet stod ikke længere for “Personal Home Page”, men blev det rekursive akronym “PHP: Hypertext Preprocessor”. Endnu vigtigere var sproget bygget til at kunne udvides. Udviklere kunne tilføje understøttelse af databaser, protokoller og API’er i stedet for at vente på, at en lille kernegruppe dækkede alle behov.
Dermed flyttede projektets tyngdepunkt sig. PHP blev ikke længere hovedsageligt defineret af sin oprindelige udvikler eller sit første formål. Det var blevet et open source-sprog, som blev formet af de problemer, brugerne ville løse.
Zend Engine giver PHP plads til at vokse
Efter PHP 3 omskrev Gutmans og Suraski igen kernen for at forbedre ydeevnen og gøre opbygningen mere modulær. Den nye motor fik navnet Zend Engine, dannet af Zeev og Andi. PHP 4 udkom i maj 2000 og tog motoren i brug sammen med HTTP-sessioner, buffering af output, understøttelse af flere webservere og bedre håndtering af brugerinput.
I denne periode fandt PHP den driftsmodel, der gjorde sproget usædvanligt tilgængeligt. Hostingunderstøttelsen var bred, modellen med én forespørgsel og ét svar passede til nettet, og en nyttig applikation kunne begynde som få sider i stedet for et stort system. Små projekter kunne starte enkelt og vokse, når behovet blev reelt.
Den lette start var en styrke, men skabte også en del af PHP’s senere ry. Et sprog, der gør den første fungerende version nem, gør ikke automatisk det tiende års vedligeholdelse nem. PHP gjorde det muligt at begynde uden meget struktur; udviklere og projekter skulle stadig tilføre den struktur, efterhånden som arbejdet blev vigtigere.
PHP 5 og de større applikationer
PHP 5 udkom i juli 2004 med Zend Engine 2 og en langt stærkere objektmodel. Klasser, interfaces, exceptions, synlighed og senere tilføjelser i PHP 5-serien gjorde sproget mere velegnet til applikationer med lang levetid og flere bidragydere.
Økosystemet modnedes samtidig. Frameworks som Symfony og Laravel gav en genkendelig struktur til routes, dependency injection, databaseadgang, køer og validering. Composer gjorde det normalt at deklarere projektets afhængigheder, installere dem ensartet, generere autoloading og gemme de præcise versioner i en låsefil. Den officielle dokumentation beskriver stadig grundideen enkelt: Afhængigheder deklareres for det enkelte projekt, og Composer håndterer installation og opdatering.
Publiceringssystemerne viste en anden form for rækkevidde. WordPress begyndte i 2003 og voksede til en platform, hvor mennesker kunne udgive indhold, udvide en hjemmeside med plugins og få udviklet specialfunktioner uden at opfinde et helt redaktionelt system. Drupal, Joomla, MediaWiki og utallige specialudviklede applikationer gjorde PHP’s rolle endnu bredere.
Min egen erfaring med PHP voksede i den verden: bookingmotorer, administrationsværktøjer, ejendomsplatforme, indholdssider og integrationer, som skulle blive ved med at fungere, mens virksomhederne omkring dem ændrede sig. Sproget var sjældent det interessante i sig selv. Værdien lå i, hvor direkte koden kunne forbinde formularer, data, redaktionelt arbejde, betalinger, tilgængelighed og daglig drift.
PHP 6: Et lærerigt forsøg, der blev opgivet
En fejring bør ikke fjerne de mislykkede kapitler. PHP 6 skulle bygge omfattende Unicode-understøttelse ind i sproget og motoren. Arbejdet begyndte i 2005, men blev opgivet i 2010, da implementeringen viste sig for vanskelig. Nyttigt arbejde overlevede: Funktioner fra PHP 6-planerne, herunder namespaces og traits, nåede senere versioner af PHP 5.
Da det næste store versionsnummer skulle vælges, gik projektet videre til PHP 7 i stedet for at genbruge PHP 6. Det vedtagne forslag om navnet beskriver den praktiske grund: PHP 6 betegnede allerede et kendt, men aldrig udgivet projekt, og genbrug af navnet ville skabe forkerte forventninger.
Det forløb er mere interessant end en fejlfri tidslinje. Open source-projekter lærer nogle gange ved at opgive en fremgangsmåde, bevare det der virkede og være ærlige om bruddet.
PHP 7 ændrer synet på ydeevne
PHP 7.0 udkom i december 2015 med Zend Engine 3. Udgivelsesmeddelelsen fremhævede markant lavere hukommelsesforbrug og op til dobbelt så høj ydelse som PHP 5.6 samt deklaration af skalar- og returtyper, bedre fejlhåndtering og null-coalescing-operatoren (??).
Arbejdet med ydeevne betød noget, fordi det forbedrede eksisterende applikationer såvel som nye. En kontrolleret opgradering af PHP kunne give en etableret hjemmeside plads til mere trafik på samme infrastruktur. Det skete ikke automatisk – kompatibilitet, udvidelser, afhængigheder og applikationens adfærd skulle stadig testes – men PHP 7 udfordrede forestillingen om, at sprogets tekniske udvikling var gået i stå.
Samtidig begyndte en tydelig bevægelse mod stærkere typer og mere forudsigelige fejl uden at gøre PHP til et andet sprog. Den velkendte model for webforespørgsler blev bevaret, mens udviklerne fik bedre muligheder for at udtrykke hensigten med koden.
PHP 8 moderniserer sproget uden at fjerne dets karakter
PHP 8.0 fulgte i 2020 med navngivne argumenter, attributter, unionstyper, deklaration af egenskaber direkte i konstruktøren, match, nullsafe-operatoren og yderligere forbedringer af typesystemet og fejlhåndteringen. Den officielle oversigt over PHP 8.0 viser et sprog, der reducerer gentagelser i koden og samtidig gør flere fejl synlige for både kørselsmiljøet og udviklingsværktøjerne.
De senere PHP 8-versioner fortsatte i den retning. PHP 8.4 tilføjede hooks til egenskaber og forskellig synlighed for læsning og skrivning. PHP 8.5 tilføjede pipe-operatoren og en særskilt URI-udvidelse. Funktionerne er beskrevet på de officielle sider for PHP 8.4 og PHP 8.5.
De enkelte funktioner holder på et tidspunkt op med at føles nye. Derfor bør en historisk artikel ikke bygges op omkring den version, der tilfældigvis er den aktuelle. Den varige forandring ligger i udviklingsprocessen: Forslag diskuteres offentligt, motoren forbedres fortsat, og sproget kan få mere sikre og udtryksfulde konstruktioner uden at holde op med at ligne PHP.
PHP ændrede mere end selve sproget
PHP var med til at gøre det normalt, at en hjemmeside kunne være software og ikke kun en samling statiske dokumenter. Formularer kunne gemme data. Sider kunne tilpasses. Redaktører kunne udgive indhold uden at ændre HTML. Mindre organisationer kunne drive kataloger, fællesskaber, bookingsystemer og administrationsværktøjer på almindelig hosting.
Sproget skabte også en usædvanligt bred indgang til programmering. En ny udvikler kunne gøre én side dynamisk, se resultatet med det samme og gradvist lære om databaser, HTTP, sessioner, sikkerhed, objekter, tests og arkitektur. Noget af den tidlige kode var dårlig, men den lave adgangsbarriere skabte også karrierer, virksomheder, open source-projekter og en stor mængde praktisk viden.
Composer, fælles standarder, modne frameworks, statisk analyse, automatiserede tests og moderne udrulning ændrede, hvordan professionel PHP-kode ser ud. Tilgængeligheden forsvandt ikke; mulighederne blev langt større.
Kritikken er også en del af historien
PHP har reelle svagheder. Standardbiblioteket bærer præg af uens navngivning og parameterrækkefølge fra forskellige perioder. Ældre versioner tillod mønstre, der gjorde fejl og sikkerhedsproblemer lettere at skabe. Bagudkompatibilitet bevarer værdifulde applikationer, men kan også bevare besværlig adfærd. Mange års forældede vejledninger påvirker stadig både sprogets ry og den kode, der bliver skrevet.
Den lette adgang betød også, at meget ustruktureret PHP nåede i produktion. Den historie kan ikke alene forklares med, at udviklerne brugte sproget forkert. Standardvalg, dokumentation, hostingkultur og selve sprogets design var alle med til at forme resultatet.
Men gammel PHP og moderne PHP er ikke det samme udviklingsmiljø. En vedligeholdt applikation med understøttede versioner, Composer, eksplicitte typer, frameworkkonventioner, tests, statisk analyse, kodegennemgang og kontrolleret udrulning bør vurderes på sin faktiske tekniske kvalitet – ikke på en usikker vejledning fra tyve år siden.
Derfor bruger jeg stadig PHP
Jeg bruger ikke PHP, fordi alle projekter bør bruge det, og jeg ville ikke bevare et gammelt PHP-system alene af nostalgi. Jeg værdsætter sproget, fordi det fortsat er praktisk.
- Afstanden fra en HTTP-forespørgsel til forståelig applikationskode kan være kort.
- Der findes bred erfaring med både hosting og drift.
- Økosystemet dækker publicering, handel, API’er, køer, tests og baggrundsopgaver.
- Eksisterende forretningslogik kan ofte forbedres gradvist i stedet for at blive kasseret i en risikabel omskrivning.
- En udvikler kan begynde med en lille funktion og tilføre mere struktur, efterhånden som applikationen får brug for det.
Den samme pragmatisme bør styre vedligeholdelsen. En ældre applikation kan have brug for en understøttet PHP-version, opdaterede afhængigheder, tests, tydeligere grænser eller udskiftning af ét skrøbeligt modul. Den skal ikke automatisk bygges helt om. Min guide til at vedligeholde og modernisere et eksisterende PHP-system gennemgår den beslutning i praksis.
PHP er én mulighed blandt flere. Til en indholdsfokuseret hjemmeside kan jeg vælge Astro. Til en etableret redaktionel arbejdsgang kan WordPress passe. Til en struktureret applikation kan Laravel eller et andet PHP-framework være fornuftigt. Det nyttige spørgsmål er ikke, om PHP vandt en debat mellem programmeringssprog, men om teknologien passer til systemet, udviklerne, driften, risiciene og den forventede levetid.
Et sprog der er værd at fejre, ikke sætte på museum
PHP fortjener at blive fejret uden at blive fremstillet som fejlfrit. Sproget gjorde dynamisk webudvikling tilgængelig for langt flere mennesker, understøttede projekter fra personlige sider til langvarige forretningssystemer og overlevede, fordi fællesskabet ændrede det, når nettet stillede nye krav.
Historien rummer en improviseret begyndelse, enorm udbredelse, svage standardvalg, ambitiøse forsøg der mislykkedes, tekniske gennembrud, professionelle værktøjer og tålmodig vedligeholdelse. Det er en mere nyttig arv end en perfekt oprindelseshistorie.
Tredive år er ikke en grund til at fastfryse PHP som nostalgisk teknologi. Det viser, at praktisk software kan udvikle sig, føre gamle systemer videre og stadig give plads til bedre måder at arbejde på.