49 besökare, 1 medlem och 2 Studenter är online nu
Loopia

PHP och MySQL

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!

 

UNIX, Linux eller Windows?

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.

UNIX, Linux eller Windows?

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.

 

Vit sida visas utan innehåll

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:

<?php

echo
"Det här är "fel" i en sträng";
echo
'Det här är "rätt" i en sträng';
echo
"Det här är 'rätt' i en sträng";

?>

Läs mer om 'enkla citationstecken' och "dubbla citationstecken" i guiden Formmail - skicka formulär till epost » (avsnittet "GET_MAGIC_QUOTES_GPC").

TIPS! Använd error_reporting när du felsöker dokumenten - se avsnittet nedan.

 

Allmänna felsökningstips

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

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 rätt editor

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:

 

Testa vissa delar av koden

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.

 

error_reporting - visa eller dölj felmeddelanden

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:

// visar felmeddelanden när du testar dina script
ini_set('display_errors', 1);

// visar ALLA felmeddelanden

error_reporting(E_ALL);

När alla felmeddelanden visas så kommer du att få en mängd 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 UTOM noteringar om fel:

// visar felmeddelanden när du testar dina script
ini_set('display_errors', 1);

// visar alla felmeddelanden men INTE "E_NOTICE" (standardvärdet i php.ini)
error_reporting(E_ALL ^ E_NOTICE);

 

Om din webbserver är konfigurerad att visa felrapporter kan du stänga av dem genom att ange detta i din PHP-kod:

// stäng av all error reporting
error_reporting(0);

Läs mer om "ERROR_REPORTING" hos PHP.net

 

TIPS! Aktivera felrapporteringen när du felsöker koden och stäng av den när du är klar med din felsökning.

 

 

Spara UTF-8 utan BOM

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

UTF med BOM

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

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!

 

Notepad++

Om du använder Notepad++ kan du välja att spara dokumentet som UTF-8 men utan BOM:

 

Dreamweaver

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.

 


TIPS! Läs mer i guiden Teckenkodning - charset » om teckenkodning.

 

 

"Warning: Cannot modify header information - headers already sent by..."

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.

Blankrader och blanksteg

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.

 

Kolla MySQL-tabellerna

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 »

Kolla din teckenuppsättning i phpMyAdmin

Välj din databas och menyn "Operationer".

I fältet "Kollationering" väljer du teckenuppsättningen "latin1_swedish_ci":

 

Använd OB_START() och OB_END_FLUSH()

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.

 

Använd "output buffering"

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:

<?php
ob_start();


//sidans innehåll och kod här...


// skickar lagrat innehåll
ob_end_flush();
?>

Läs mer om "OB_START" hos PHP.net

 

"failed to open stream: Permission denied in..."

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")

 

MySQL server wait_timeout

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:

// SESSION WAIT_TIMEOUT i sekunder för MySQL-server, ändra värdet om scripten gör timeout
mysql_query("SET SESSION wait_timeout=600") or die(mysql_error());

Ange koden i dina PHP-dokument FÖRE de querys som orsakar "server_wait_timeout".

 

MySQL max_user_connections

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:

<?php

// ansluter till MySQL och den angivna databasen
$opendb =mysql_connect("localhost", "root", "password") or die(mysql_error());
mysql_select_db("databasnamn") or die(mysql_error());

//sidans kod och innehåll här...


// stänger databasen
mysql_close($opendb);

?>

Läs mer om "MYSQL_CLOSE" hos PHP.net