Logga in
Exemplen våra guider är testade och fungerar enligt de versioner av PHP och MySQL som anges i varje guide. I guiderna anges också vilka övriga förutsättningar som bör vara uppfyllda för att exemplen ska fungera. Att förutse och informera om ALLA eventuella fel som kan inträffa är inte möjligt och den här guiden samlar tips på tänkbara felorsaker om dina PHP-filer inte fungerar korrekt.
Vår målsättning är att den här guiden förnyas med fler felsökningstips! Har du egna erfarenhetar av fel som uppstått och kan ge tips till andra så får du gärna dela med dig av tipsen genom att kontakta oss » så att vi kan uppdatera den här guiden med nya tips!
Om du har problem med dina PHP-filer eller MySQL-databas kan felet bero på ditt webbhotell. Vissa webbhotell har begränsningar i konfigurationen av serverprogram som Apache och MySQL-server och det kan påverka dina PHP-script. Om du följt de övriga felsökningstipsen nedan utan resultat bör du kontakta ditt webbhotell och kolla om andra kunder har samma problem.
Om du har din webbplats på ett webbhotell erbjuder de ofta utrymme på Windows-server eller UNIX/Linux-server. Observera att du inte behöver inte välja det operativsystem som du har på din egen dator.
Flera webbhotell rekommenderar UNIX/Linux som standardsystem då det snabbt och säkert hanterar vanliga HTML-sidor, PHP, Perl och Python samt många tredjepartsprodukter som WordPress, Joomla och liknande.
PHP-installationen brukar vara speciellt anpassad för UNIX/Linux och erbjuder då fler komponenter än Windows. Välj en Windows-server om du kommer att använda ASP, ASP.NET, Ms Access och Ms SQL Server.
Du har utökat stöd för PHP under UNIX/Linux och Webdesignskolans PHP- och MySQL-guider är testade på UNIX-server.
Om du har Windows-server kan detta innebära att vissa script inte fungerar då de nödvändiga PHP-komponenterna inte är installerade.
En tom vit sida i webbläsaren beror oftast på att PHP-koden saknar vissa tecken (eller förekommer dubbelt) så att syntaxen blir felaktig. Resultatet blir oftast inget felmeddelande utan bara en tom sida...
Kontrollera din kod noga och leta efter tecken som saknas, angivits på fel plats eller förekommer dubbelt.
Om du missat något av tecknen { } ( ) [ ] ' " . , fungerar inte din PHP-kod korrekt och resultat blir en tom vit sida när koden körs i webbläsaren.
Om du använder en felaktigt kombination av 'enkla citationstecken' och "dubbla citationstecken" i strängar så kan strängarna delas upp och även bli en del av själva koden.
Här är några exempel:
TIPS! Använd error_reporting när du felsöker dokumenten - se avsnittet nedan.
Det är ofta svårt att hitta felen i koden och några metoder för att upptäcka felen kan vara enligt nedan.
Testa koden kontinuerligt och gör backuper av den fungerande PHP-filen som du kan återgå till om de ändringar du gjort inte fungerar som du tänkt.
Använd en editor som färgkodar din kod så ser du direkt när något tecken påverkar koden.
Här är ett exempel från en editor där en 'enkelfnutt' utelämnats och det visas direkt när färgen skiftar:
RÄTT:
FEL:
Kommentera bort avsnitt i koden och testa om sidan visas så kan du ringa in den del av koden där felet kan finnas.
Använd slash och asterisk för längre avsnitt kod:
/* din kod här... */
Använd dubbel slash för enstaka rader kod:
// din kod här
I exemplet nedan är hela avsnittet bortkommenterat och sidan visas nu åter i webbläsaren:
Sidan visas alltså, men fungerar inte förrän kodavsnittet felsökts och rättats till.
TIPS! Använd error_reporting när du felsöker dokumenten - se avsnittet nedan.
Felmeddelanden kan vara till hjälp när du felsöker dina PHP-sidor. Det finns ett antal nivåer av felrapportering och du kan själv ange typen med hjälp av funktionen ERROR_REPORTING()
Läs mer om "ERROR_REPORTING" hos PHP.net
Kontrollera din PHP-installation om display_errors är aktiverat.
Se guiden phpinfo - info om PHP-installation »
Exemplet visar att felrapporteringen är avstängd:
Fel uppstår ibland och det behöver inte vara allvarliga fel som påverkar funktionen i dina sidor. Det finns olika anledningar att inte visa eventuella fel som uppstår under körning av din kod.
En anledning är att det innebär en säkerhetsrisk att visa felmeddelanden i webbläsaren. En annan anledning är att det ger ett oseriöst intryck för dina besökare om det visas felmeddelanden.
Du kan välja att visa felen i en loggfil som "error.log" eller liknande. Kontrollera detta med ditt webbhotell. Tänk på att loggfilen kan bli full om en maxgräns används och det i sig kan generera fel. Töm loggfilen regelbundet.
Det är en bra metod att aktivera felrapportering när du testar din kod. Du ser direkt i webbläsaren vilka felmeddelanden som genereras och kan felsöka koden. Stäng av felrapporteringen när du är klar med felsökningen.
Kodexemplen nedan visar hur du aktiverar och stänger av felrapportering i webbläsaren.
OBS! Anges denna kod före den övriga koden som ska testköras.
Koden nedan aktiverar felrapporteringen och visar ALLA felmeddelanden:
När alla felmeddelanden visas så kommer du att få en mängd felmeddelanden av typen NOTICE dvs noteringar om fel. Det betyder inte att din kod är helt felaktig men kan vara en rekommendation.
Ett exempel är att du får varningen: "Notice: Undefined variable" som innebär att variabeln är odefinierad eller tom. Detta är inget fel men genererar ett felmeddelande i form av en notering.
Koden nedan aktiverar felrapporteringen och visar alla felmeddelanden FÖRUTOM noteringar om fel:
Om din webbserver är konfigurerad att visa felrapporter kan du stänga av felmeddelanden genom att ange detta i din PHP-kod:
Om du använder PHP 8 så kommer alla felmeddelanden visas, inklusive notiser. Det är en grundinställning i PHP 8 som inte fanns i PHP 7 och tidigare versioner.
För att endast visa fel som påverkar körningen som tex "Fatal runtime error" kan du ange koden nedan:
Läs mer om "ERROR_REPORTING" hos PHP.net
Ett vanligt fel är att ditt dokument innehåller osynliga tecken som används av den teckenuppsättning du sparat dokumentet med.
De extra tecknen används som styrkod för olika ändamål och i PHP-dokument kan det vara just det som gör att din kod blir felaktig.
Teckenuppsättningen UTF-8 lägger till ett "byte-order-mark", kallas också för BOM, för att ange att koden använder 16-bitar (UTF-16) eller 32-bitar (UTF-32) men BOM fyller inte samma funktion i UTF-8.
De webbläsare och editorer som inte hanterar UTF-8 korrekt lägger till tecknet: "" istället för BOM i början av sidans innehåll. Detta innebär att det tecknet skickas före header-informationen.
Läs mer om UTF, Unicode och BOM här:
http://www.unicode.org/unicode/faq/utf_bom.html
http://en.wikipedia.org/wiki/Unicode
http://en.wikipedia.org/wiki/Byte_Order_Mark
Här är ett exempel där en PHP-fil sparats i Notepad som UTF-8 och ett extra tecken lagts till. I koden syns inte tecknet men det visas i webbläsaren:
Exemplet med BOM ovan resulterade inte i att någon extra header skickades då det tolkades som ett vanligt tecken. Men då den här typen av tecken inte syns i din kod så kan de vara orsaken till att en header skickas före din PHP-header.
I vissa editorer kan du välja att spara" UTF-8 utan BOM" men om den möjligheten inte finns bör du undvika UTF-8 och spara som ANSI eller annan teckenuppsättning.
Notepad (Anteckningar) i Windows har detta problem och du kan inte välja att spara som "UTF-8 without BOM". Se därför till att du aldrig sparar (eller öppnar) dokumenten som UTF-8.
FEL!
RÄTT!
Om du använder Notepad++ kan du välja att spara dokumentet som UTF-8 men utan BOM:
Om du använder Dreamweaver kan du välja att spara dokumentet som UTF-8 men utan BOM.
Öppna dialogrutan "Preferences" (Inställningar) med menyn "Edit/Preferences" (Redigera/Inställningar) eller snabbkommando CTRL+U.
I kategorin "Nytt dokument" ser du till att valet är gjort enligt nedan (om du vill använda UTF-8):
Inställningen ovan ger teckenuppsättningen:
<meta charset="utf-8">
Om du inte vill använda Unicode kan du använda "Västeuropeisk" teckenuppsättning:
Inställningen ovan ger teckenuppsättningen:
<meta charset="iso-8859-1">
När du använder andra editorer än exemplen ovan måste du kolla upp var du anger att UTF-8 ska sparas (och öppnas) utan BOM. Även om inte uttrycket "BOM" finns i din editor kan tex "autodetect UTF-8 file" ändå innebära att BOM används.
HTTP Headers innehåller information som skickas med en sida men som inte visas i själva sidan.
Headers är meta-information som skickas före all annan HTML-kod och sidinnehållet.
Läs mer om "header" hos PHP.net
Headers måste skickas före övrigt sidinnehåll och i PHP är ett vanligt förekommande fel att något ändå skickas före header-informationen. Det kan vara blankrader, mellanslag eller vanlig HTML och det kan generera ett felmeddelande som detta:
"Warning: Cannot modify header information - headers already sent by..."
Prova någon av åtgärderna nedan för att ta bort den information som skickas före header.
Ta bort alla blanksteg (mellanslag) och blankrader (radbrytningar) i början och slutet av dokumentet. Kolla också noga att inga blanksteg eller tomma rader finns före eller efter öppning och stängning av PHP-avsnitten <?php och ?>
OBS! Även om du själv varit noga kan det vara den editor du öppnar dina sidor med som lägger till extra rader i slutet av dokumentet när det öppnas men inte när det sparas. Kolla hur sidorna ser ut när du öppnat dem i din editor.
Informationen som hämtas från MySQL kan påverka PHP-koden om BOM (byte-order-mark) hämtas från tabellen.
Om du har problem med headers kan du se till att du använder annan teckenuppsättning än UTF-8 i dina tabeller. Läs mer om teckenuppsättningar i guiden MySQL och databaser »
Välj din databas och menyn "Operationer".
I fältet "Kollationering" väljer du teckenuppsättningen "latin1_swedish_ci":
Om du kontrollerat felkällorna ovan men trots detta inte kan lösa problemet med:
"Warning: Cannot modify header information - headers already sent by..."
så kan du prova med output buffering. Se avsnittet nedan.
Output buffering används för att kontrollera innehållet som skickas från scriptet. Använd funktionen OB_START() för att starta lagring av innehållet. Inget innehåll skickas från scriptet utan lagras i en intern buffer. När scriptet körts till slutet av sidkoden så skickas innehållet som lagrats.
Du kan också anropa funktionen OB_END_FLUSH(); för att skicka det lagrade innehållet till webbläsaren.
Om du kontrollerat felkällorna ovan men trots detta inte kan lösa problemet med:
"Warning: Cannot modify header information - headers already sent by..."
(se avsnittet ovan) så kan du prova med output buffering.
I exemplet nedan används output buffering för att lagra allt innehåll och skicka det när körningen av scriptet avslutats:
Läs mer om "OB_START" hos PHP.net
Felmeddelande av typen: "failed to open stream: Permission denied in..." beror oftast på att du inte har rättigheter att skriva till filer och mappar eller köra filer på din webbserver. Se till att de mappar och filer som berörs av koden har rättigheter för att skriva till filer eller mappar.
De nivåer som brukar fungera för att köra script och programkod är CHMOD 755 för mappar och CHMOD 644 för filer men konfigurationen av serverprogrammen på vissa webbhotell kräver att du själv ändrar till en högre nivå.
Den högsta nivån CHMOD 777 ger fullständiga rättigheter men kan samtidigt innebära en säkerhetsrisk. Om programmen som körs på webbservern innehåller någon form av säkerhetsluckor så kan en obehörig användare utnyttja detta.
OBS! Läs mer i guiden Använda FTP-program » (avsnittet "CHMOD")
Om du gör frågor mot MySQL-databasen som tar lång tid kan servern göra timeout och avbryta din query. Standarvärdet för "mysql.connect_timeout" är 60 sekunder för MySQL-server. Du kan ändra timeout-tiden med funktionen MYSQL_QUERY.
Exemplet nedan anges timeout-tiden 10 minuter:
Ange koden i dina PHP-dokument FÖRE de querys som orsakar "server_wait_timeout".
Antalet anslutningar till databasen är begränsat och du kan få felmeddelanden av typen:
"Kunde inte ansluta till MySQL: User yourusernamn@ already has more than 'max_user_connections' active connections"
Varje connection använder relativt mycket minne och för att öka driftsäkerheten anger webbhotellen en gräns för antalet anslutningar mot din databas. En öppnad anslutning stängs automatiskt när körningen av scriptet är utförd och den ska egentligen inte behöva stängas manuellt. Om databasen har många användare samtidigt, eller du av annan anledning får felmeddelandet ovan, kan du stänga varje öppnad anslutning med funktionen MYSQL_CLOSE.
Exemplet visar hur den öppnade anslutningen $opendb databasen stängs i slutet av dokumentet:
Läs mer om "MYSQL_CLOSE" hos PHP.net
skriv ut »