11 okt. 2025·8 min
Rasmus Lerdorf och PHP: Från personligt verktyg till webbstandard
Berättelsen om Rasmus Lerdorf och PHP—hur en liten uppsättning webbskript blev en utbredd plattform, och varför PHP fortfarande driver många sajter idag.
Berättelsen om Rasmus Lerdorf och PHP—hur en liten uppsättning webbskript blev en utbredd plattform, och varför PHP fortfarande driver många sajter idag.
PHP startade inte som en storslagen plattform eller ett noggrant utformat språk. Det började därför att Rasmus Lerdorf ville lösa ett konkret problem: underhålla en personlig webbplats utan att göra samma manuella arbete om och om igen.
Den detaljen är viktig eftersom den förklarar mycket av varför PHP känns som det gör—även idag.
Lerdorf var en utvecklare som byggde för det tidiga webben, när sidor mest var statiska och att uppdatera något utöver ren HTML snabbt blev tråkigt. Han ville ha enkla skript som kunde spåra besökare, återanvända vanliga siddelar och generera innehåll dynamiskt.
Med andra ord: han ville ha verktyg som hjälpte honom att leverera ändringar snabbare.
"Personliga verktyg" var inte ett varumärke—det var ett tankesätt. Tidiga webbbyggare skrev ofta små hjälpprogram för att automatisera det tråkiga:
PHP:s tidigaste versioner formades av den praktiska, få‑det‑gjort‑attityden.
När du känner till PHP:s rötter blir många av dess drag mer begripliga: fokus på att bädda in kod direkt i HTML, ett stort standardbibliotek inriktat på vanliga webbuppgifter och en preferens för bekvämlighet framför akademisk renhet.
Dessa val gjorde att PHP spreds snabbt, men de skapade också kompromisser som vi kommer tillbaka till senare.
Denna artikel går igenom hur PHP växte från Lerdorfs skript till ett community‑drivet språk, varför det passade hosting och LAMP‑stacken så bra, hur ekosystem som WordPress förstärkte det och vad modern PHP (7 och 8+) förändrade—så att du kan bedöma PHP idag utifrån verkligheten, inte nostalgi eller hype.
Mitten av 1990‑talet var webben mest statisk HTML. Vill du ha något dynamiskt—bearbeta ett formulär, visa en räknare, anpassa en sida per besökare—så brukade du ta till CGI‑skript, ofta skrivna i Perl.
Det fungerade, men det var inte smidigt.
CGI‑program kördes som separata processer för varje förfrågan. För enkla uppgifter innebar det många rörliga delar: en skriptfil med noggranna rättigheter, serverkonfiguration och en mental modell som inte kändes som "att skriva en webbsida." Du blandade inte bara in lite logik i HTML; du byggde ett litet program som skrev ut HTML som text.
För hobby‑sajter och små företag var de vanliga behoven repetitiva och praktiska:
De flesta satt på delad hosting med begränsad CPU, minne och lite kontroll över serverinställningar. Att installera egna moduler eller långkörande tjänster var inte realistiskt. Det du kunde göra var att ladda upp filer och köra enkla skript.
Dessa begränsningar pushade mot ett verktyg som:
Det gapet—mellan statiska sidor och tyngre skript—var vardagsproblemet PHP satte ut att lösa.
Rasmus Lerdorf hade inte för avsikt att uppfinna ett programspråk. Han ville något mycket vanligare: ett bättre sätt att köra sin egen webbplats.
Det tidigaste "PHP" började som en samling små C‑program han använde för att spåra besök till sitt online‑CV, plus några hjälpverktyg för grundläggande site‑uppgifter utan att ständigt redigera sidor för hand.
Då var det inte lika enkelt att veta vem som besökte din sida som att släppa in ett analysskript. Lerdorfs skript hjälpte till att logga och sammanfatta förfrågningar, vilket gjorde det lättare att förstå trafikmönster.
Vid sidan av det byggde han hjälpverktyg för vanliga webbuppgifter—enkla templating‑lösningar, små bitar dynamisk output och formulärhantering—så att sajten kunde kännas "levande" utan att bli en fullständig skräddarsydd applikation.
När du väl har verktyg för trafikanalys, formulärbehandling och återanvända sidkomponenter har du av misstag byggt något andra också kan använda.
Det är den viktiga knutpunkten: funktionaliteten var inte bunden till en layout eller en sida. Den var tillräckligt generell för att andra sajtägare kunde tänka sig att kopiera till sin egen webbplats.
Eftersom det började som en verktygslåda var ergonomin praktisk: gör det vanliga snabbt, överdesigna inte och sänk inlärningströskeln.
Den attityden—nyttan först, poleringen senare—gjorde PHP tillgängligt från början.
Sammanfattningen är enkel: PHP:s rötter var inte akademiska eller teoretiska. De var problemdrivna, inriktade på att få en riktig webbplats att fungera med mindre friktion.
PHP började inte som ett "språk" i den bemärkelsen vi tänker idag. Den första publika milstolpen var PHP/FI, som stod för "Personal Home Page / Forms Interpreter."
Namnet säger en hel del: det försökte inte bli allt. Det skulle hjälpa folk att bygga dynamiska sidor och bearbeta webbformulär utan att skriva ett helt program för varje uppgift.
PHP/FI samlade några praktiska idéer som tillsammans gjorde tidig webb‑utveckling mycket mindre plågsam:
Det var inte polerat, men det minskade mängden limkod folk behövde skriva bara för att få en sida att fungera.
Tidiga webbplatser stötte snabbt på begränsningar: så fort du ville ha feedbackformulär, gästböcker, registreringar eller enkel sökning behövde du ta emot användarinmatning och göra något med den.
PHP/FI gjorde formulärhantering till ett kärnfall. Istället för att se formulär som en avancerad funktion lutade det sig mot dem—vilket gjorde det enklare att läsa in skickade värden och generera en responsida.
Detta matchade vad vanliga sajtägare försökte bygga.
En av PHP/FI:s mest inflytelserika idéer var dess templatingstil: håll HTML som huvuddokumentet och fläta in små bitar serverlogik.
<!-- HTML-first, with small dynamic pieces -->
<p>Hello, <?php echo $name; ?>!</p>
För designers och tinkrare kändes detta naturligt: du kunde redigera en sida och lägga till "precis tillräckligt" dynamiskt beteende utan att anta ett helt separat system.
PHP/FI var inte elegant, och det försökte inte vara det. Folk använde det eftersom det var:
Dessa "killer‑funktioner" var inte bländande—de var precis vad den tidiga webben behövde.
Rasmus Lerdorfs tidiga PHP‑skript byggdes för att lösa hans egna problem: spåra besökare, återanvända vanliga sidor och slippa upprepa arbete.
Vad som gjorde det lilla verktyget till det som de flesta idag känner som "PHP" var inte en enda stor omskrivning—det var en stadig dragning från andra utvecklare som ville ha samma bekvämlighet för sina sajter.
Så fort PHP delades offentligt skickade användare in fixar, små funktioner och idéer. Den feedback‑slingan betydde att projektet började spegla många webbmasters behov istället för en enda persons.
Dokumentation förbättrades, kantfall lappades och språket började utveckla konventioner som gjorde det lättare att plocka upp och använda.
Ett stort vägskäl var PHP 3, som omskrev kärnan och introducerade namnet "PHP: Hypertext Preprocessor." Det var inte bara marknadsföring.
Omskrivningen gjorde språket mer konsekvent och enklare att utöka, vilket betydde att PHP kunde växa utan att bli en ohanterlig hög av engångsskript.
En bredare användarbas drev på integrationer med verktyg folk redan litade på. Tillägg började dyka upp som kopplade PHP till olika databaser och tjänster, så du var inte fast i en enda setup.
Istället för "ett skriptverktyg som skriver ut HTML" blev PHP ett praktiskt sätt att bygga datadrivna webbplatser—gästböcker, forum, kataloger och tidig e‑handel.
Nyckeln: community‑bidrag lade inte bara till funktioner. De förändrade PHP:s roll från ett hjälpsamt verktyg till en utbyggbar plattform som folk vågade satsa riktiga projekt på.
PHP blev inte standardvalet för så många webbplatser bara för att det var lätt att komma igång. En stor del av historien är att motorn under huven fick rejäl uppgradering—något som gjorde PHP snabbare, mer konsekvent och lättare att utöka.
Zend (grundat av Andi Gutmans och Zeev Suraski) introducerade Zend Engine som en ny kärna för PHP. Tänk dig att byta motor men behålla bilen.
Utvecklare kunde fortfarande skriva bekant PHP‑kod, men runtime blev bättre strukturerad internt.
Denna struktur möjliggjorde:
PHP 4 (drivet av Zend Engine 1) kom vid perfekt tidpunkt för webbens "hyra en serverbit"‑modell.
Delade hosting‑leverantörer kunde erbjuda PHP brett och billigt—många gjorde det. Den här tillgängligheten skapade en tillväxtloop: fler hosts stödde PHP, fler använde det; mer användning fick hosts att fortsätta stödja det.
I praktiska termer var PHP 4 "tillräckligt bra, överallt." Denna utbredning betydde minst lika mycket som några språkliga finesser.
PHP 5 (Zend Engine 2) drev PHP framåt för team som byggde större kodbaser. Huvudnyheten var starkare objektorientering: bättre klass‑hantering, förbättrade synlighetsregler och en grund för modernare mönster.
Det handlade inte om att göra PHP akademiskt—utan om att göra det enklare att organisera riktiga projekt, återanvända kod och underhålla applikationer över tid.
När PHP spreds uppstod ett nytt tryck: folk började förvänta sig att gammal kod skulle fortsätta fungera. Hosting‑företag, CMS‑plattformar och byråer var beroende av stabilitet.
Från denna punkt handlade PHP‑utveckling inte bara om att lägga till funktioner—utan också om att "inte bryta internet."
PHP vann inte för att det var det mest eleganta språket på papper. Det vann eftersom det gjorde det att bygga användbara webbsidor kändes omedelbart.
För tidiga webbbyggare—ofta designers, hobbyister eller småföretag—sänkte PHP tiden till första fungerande sak mer än nästan något annat.
Med PHP var feedback‑loopen nästan friktionsfri: ladda upp en fil, uppdatera sidan, se resultat. Det låter trivialt, men formade en hel generation av webbbygge.
Folk kunde börja med en enda dynamisk sida (kontaktformulär, gästbok, räknare) och växa därifrån.
Tidiga webbprojekt hade sällan stora ingenjörsavdelningar. De hade en utvecklare, kanske två, och en hög med brådskande uppgifter.
PHP passade den verkligheten: det minskade ceremonin kring driftsättning och gjorde inkrementella ändringar lätta att leverera.
PHP red på en våg av billig delad hosting. Många leverantörer förinstallerade det, så du behövde ingen speciell infrastruktur eller dyra servrar.
Driftsättning betydde ofta "kopiera filerna över", vilket matchade hur människor redan publicerade HTML.
När PHP‑adoptionen ökade blev det självförstärkande. Tutorials, kodsnuttar, forum och copy‑paste‑exempel fanns överallt.
Detta community‑minne gjorde PHP tillgängligt—även när de underliggande webbproblemen var allt annat än enkla.
PHP lyckades inte bara för att språket var lätt att plocka upp—det lyckades för att det hade ett "standardhem" på den tidiga webben.
Det hemmet var LAMP‑stacken: Linux + Apache + MySQL + PHP. I åratal var denna kombination standardreceptet för att köra dynamiska webbplatser, särskilt för små företag och personliga projekt.
Linux och Apache var tillgängliga och billiga att köra. PHP passade in i Apaches request/response‑modell: en besökare begärde en URL, Apache skickade förfrågan till PHP, och PHP genererade HTML på språng.
Det fanns ingen separat applikationsserver att hantera, vilket höll deployment enkel och billig.
MySQL kompletterade bilden. PHP:s inbyggda databasextentioner gjorde det enkelt att ansluta till MySQL, köra frågor och rendera resultat i en webbsida.
Denna tighta integration betydde att en stor andel databashämtade sajter kunde byggas med samma bekanta verktyg.
En stor accelerant var delad hosting. Många hosts erbjöd konton där PHP och MySQL redan var konfigurerade—ingen systemadministration krävdes.
Med kontrollpaneler som cPanel kunde användare skapa en MySQL‑databas, hantera tabeller i phpMyAdmin, ladda upp PHP‑filer via FTP och gå live snabbt.
Sedan kom one‑click‑installers (ofta för WordPress, forum och shoppingcart). Dessa normaliserade idén att "en webbplats är en PHP‑app + en MySQL‑databas", och gjorde PHP till den väg som krävde minst motstånd för miljontals sajtägare.
Stacken uppmuntrade ett praktiskt arbetsflöde: redigera en .php‑fil, uppdatera webbläsaren, justera SQL, upprepa.
Den formade också bekanta mönster—templates och includes, formulärhantering, sessions och CRUD‑sidor—som skapade en gemensam mental modell för webbbygge långt efter LAMP‑toppen.
PHP blev inte "överallt" bara på grund av syntaxen. Det blev ett standardval eftersom kompletta, installerbara produkter växte upp runt det—verktyg som löste riktiga affärsproblem med minimal setup.
Content management‑system gjorde PHP till ett klick‑beslut. Plattformar som WordPress, Drupal och Joomla paketerade svåra delar—adminpaneler, inloggningar, behörigheter, teman, plugins—så en sajtägare kunde publicera sidor utan att skriva kod.
Det betyder att varje CMS skapade sin egen gravitation: designers lärde sig temabyggande, byråer byggde återanvändbara erbjudanden och plugin‑marknader växte.
När en kunds sajt blev beroende av det ekosystemet valdes PHP om och om igen—ibland utan att kunden ens visste det.
Nätbutiker och communitysajter var tidiga webb‑beståndsdelar, och PHP passade väl in i delad hosting‑realiteten.
Programvara som Magento (och senare WooCommerce på WordPress), samt forumappar som phpBB, gav färdiga lösningar för kataloger, kundvagnar, konton och moderation.
Dessa projekt normaliserade också arbetsflödet: installera en app, konfigurera i webbläsaren och utöka med moduler—precis den typ av utveckling som lät PHP frodas.
Inte all PHP är publikt synlig. Många team använder det för interna dashboards, adminverktyg och enkla API:er som kopplar betalningar, lager, CRM‑system eller analysverktyg.
Dessa system syns inte i "vilket CMS är det?"‑skanningar, men de håller PHP i daglig användning.
När en stor del av webben körs på några enorma produkter (särskilt WordPress) är språket underliggande arv av de ekosystemen—inte bara en reflektion av språket i sig.
PHP:s räckvidd är i stor utsträckning räckvidden hos de ekosystem som byggts ovanpå det.
PHP:s framgång har alltid varit knuten till pragmatism—och pragmatism lämnar ofta grova kanter.
Många kritiker har grund i verklig historia, men inte alla speglar hur PHP används (eller skrivs) idag.
Ett frekvent klagomål är inkonsekvens: funktionsnamn som följer olika mönster, parametrar i olika ordning och äldre API:er som lever kvar bredvid nyare.
Det är verkligt—det är resultatet av att PHP växte snabbt, lade till funktioner i takt med att webben förändrades och behöll äldre gränssnitt för miljontals existerande sajter.
PHP stödjer också flera programmeringsstilar. Du kan skriva enkla "få det gjort"‑skript eller mer strukturerad objektorienterad kod.
Kritiker kallar detta "blandade paradigm"; förespråkare kallar det flexibilitet. Nackdelen är att team kan få ojämn kodkvalitet om de inte sätter standarder.
"PHP är osäkert" är en förenkling. De flesta PHP‑incidenter beror på applikationsmisstag: lita på användarinmatning, bygga SQL‑frågor genom strängkonkatenering, felkonfigurera filuppladdningar eller glömma åtkomstkontroller.
PHP:s historiska standardinställningar styrde inte alltid nybörjare mot säkra mönster, och dess enkelhet gjorde att många nybörjare driftsatte publik kod.
En mer korrekt slutsats: PHP gör det enkelt att bygga webbappar, och webbappar är lätta att göra fel i utan grundläggande säkerhetshygien.
PHP har ett tungt ansvar: bryt inte webben.
Denna bakåtkompatibilitet håller långlivade appar igång i åratal, men betyder också att legacy‑kod ofta hänger kvar—ibland långt efter sin "bäst före"‑datum. Företag kan lägga mer kraft på att underhålla gamla mönster än att adoptera bättre lösningar.
Rimlig kritik: inkonsekvens, legacy‑API:er och ojämna kodbaser är verkliga.
Föråldrad kritik: anta att moderna PHP‑projekt måste se ut som tidigt 2000‑tal eller att språket i sig är huvudorsaken till säkerhetsproblem.
I praktiken handlar skillnaden oftast om teamets praxis, inte verktyget.
PHP:s rykte hänger ofta ihop med kod skriven för många år sedan: blandning av HTML och logik i en fil, inkonsekvent stil och "funkar på min server"‑driftsätt.
PHP 7 och 8+ la inte bara till funktioner—de knuffade ekosystemet mot renare, snabbare och mer underhållbar utveckling.
PHP 7 gav stora prestandaförbättringar genom att omdesigna nyckel‑interna delar av motorn.
I klarspråk: samma app kunde hantera fler förfrågningar på samma hårdvara, eller kosta mindre att köra vid samma trafik.
Det spelade roll för delad hosting, trafiktäta WordPress‑sajter och företag som mätte "sidladdningstid" i förlorad försäljning. Det gjorde också att PHP kändes konkurrenskraftigt igen jämfört med nyare serverside‑alternativ.
PHP 8 införde funktioner som gör stora kodbaser enklare att förstå:
int|string). Det minskar gissningar och förbättrar verktygsstöd.Moderna PHP‑projekt använder vanligtvis Composer, standardverktyget för beroendehantering.
Istället för att kopiera bibliotek för hand deklarerar team beroenden i en fil, installerar förutsägbara versioner och använder autoloading. Det är en av anledningarna till att samtida PHP känns mycket mer "professionellt" än copy‑paste‑eran.
Gammal PHP betydde ofta ad‑hoc‑skript; modern PHP betyder oftast versionshanterade beroenden, ramverk, typad kod, automatiserade tester och prestanda som står sig under verklig trafik.
PHP är inte ett nostalgival—det är ett praktiskt verktyg som fortfarande passar många webbjobb mycket bra.
Nyckeln är att matcha det mot dina begränsningar, inte din ideologi.
PHP är särskilt bra när du bygger eller driver:
Om ditt projekt vinner på "många utvecklare känner redan till det, och hosting finns överallt", kan PHP minska friktionen.
Överväg alternativ om du behöver:
Det kan också vara värt att välja en annan stack om du bygger en helt ny produkt och vill ha starka default‑val för modern arkitektur (typade API:er, strukturerade tjänster och tydligare separation av ansvar).
Ställ dessa innan du väljer:
En lärdom från PHP:s ursprung är tidlös: vinnande verktyg minskar avståndet mellan idé och fungerande mjukvara.
Om du utvärderar om du ska fortsätta satsa på PHP eller bygga en ny tjänst vid sidan om (till exempel en React‑frontend med ett Go‑API) kan en snabb prototyp ta bort mycket osäkerhet. Plattformar som Koder.ai är byggda för det "ship‑first"‑arbetsflödet: du kan beskriva en app i chatten, generera ett fungerande webb‑ eller backendprojekt (React + Go med PostgreSQL) och iterera snabbt med funktioner som planeringsläge, snapshots och rollback—sedan exportera källkoden när du är redo.
För fler praktiska guider, läs /blog. Om du jämför driftsättnings‑ eller tjänstealternativ kan /pricing hjälpa dig att rama in kostnader.
Rasmus Lerdorf byggde en uppsättning små verktyg skrivna i C för att underhålla sin personliga webbplats—spåra besökare, återanvända siddelar och hantera enkel dynamisk output.
Eftersom målet var att ta bort repetitiva webbsysslor (inte att designa ett "perfekt" språk) fick PHP tidigt en praktisk inriktning: snabbt att driftsätta, enkelt att bädda in i HTML och fullt av webbfokuserade hjälpverktyg.
I mitten av 1990‑talet bestod de flesta sidor av statisk HTML. Allt som var dynamiskt (formulär, räknare, per‑användarinnehåll) krävde ofta CGI‑skript—vanligtvis skrivna i Perl.
Det fungerade, men var opraktiskt för vardagliga uppdateringar eftersom du ofta skrev ett separat program som skrev ut HTML, istället för att redigera en HTML‑sida och lägga till små serverlogiska bitar.
CGI‑program kördes vanligtvis som separata processer per begäran och krävde mer konfiguration (rättigheter, serverinställningar och en annan mental modell).
PHP fick dynamisk output att kännas närmare "att redigera en webbsida": skriv HTML, lägg till små serversidesnuttar, ladda upp, uppdatera sidan.
PHP/FI stod för "Personal Home Page / Forms Interpreter." Det var en tidig offentlig version fokuserad på att bygga dynamiska sidor och hantera formulär.
Dess "killer"‑idé var att kunna bädda in serverside‑kod direkt i sidor samtidigt som den erbjöd inbyggda bekvämligheter för vanliga webbuppgifter (särskilt formulärhantering och grundläggande databasåtkomst).
Det sänkte tröskeln för icke‑specialister: du kunde behålla HTML som huvud‑dokument och stoppa in små dynamiska delar (till exempel skriva ut ett namn eller loopa genom resultat).
Detta arbetssätt passade hur människor byggde sajter i delad hosting—stegvis—utan att först införa ett helt separat templatesystem.
När PHP började delas offentligt skickade andra utvecklare in felkorrigeringar, små funktioner och idéer.
Det skiftade PHP från "en persons verktygslåda" till ett ekosystemdrivet projekt där webbmasters verkliga behov (databaser, tillägg, portabilitet) formade språkets riktning.
PHP 3 var en större omskrivning som gjorde kärnan mer konsekvent och enklare att utöka, och introducerade namnet "PHP: Hypertext Preprocessor."
I praktiken var det här PHP blev en mer stabil, utbyggbar plattform istället för en samling ad‑hoc‑skript.
Zend Engine (infört av Andi Gutmans och Zeev Suraski) förbättrade P HP:s körning—bättre struktur, bättre prestanda och en tydligare väg för tillägg.
Det gjorde att hosting‑leverantörer kunde erbjuda PHP brett och billigt, och team kunde bygga större kodbaser med mer förutsägbart beteende.
LAMP (Linux, Apache, MySQL, PHP) blev standard för dynamiska sajter, särskilt på delad hosting.
PHP passade bra in i Apaches request/response‑modell och dess databasanslutningar gjorde MySQL‑drivna sidor enkla—så miljontals sajter standardiserade på samma verktygskedja och arbetsflöde.
Modern PHP (7 och 8+) gav stora prestandavinster och mer underhållbara språkelement, samtidigt som Composer standardiserade beroendehanteringen.
För att utvärdera PHP idag, överväg:
Att modernisera inkrementellt är ofta billigare än en total omskrivning om du redan har ett PHP‑system.