Underlätta felsökning med testprogram

Har du ett problem du vill ha hjälp med? Gör det enkelt för dina kollegor med ett testprogram som påvisar felet.

Ibland stöter man på problem, eller beteenden, som man inte förstår. Oavsett om det är HTML, CSS, PHP eller SQL, så underlättar det att skriva ett enkelt testprogram, ett testprogram som påvisar beteendet.

Genom att skriva detta lilla testprogram, uppnår du två saker:

1) Lär dig själv.  Du lär dig om beteendet genom att skriva kodexemplet, ofta kan svaren, på dina funderingar, uppenbara sig genom att du skriver testprogrammet. Det är, helt enkelt, ett bra sätt att lära sig.

2) Få hjälp med svaren. Du underlättar för kollegor, med-studenter och lärare, när de försöker hjälpa dig att finna svaren. Genom att presentera ett litet exempel så gör du det enkelt för en annan person att kommentera beteendet, eller föreslå varianter på lösningar. 

Kolla några befintliga testprogram
På dbwebb.se/examples hittar du ett par exempel på just såna här små testprogram. Det bästa är om du kompletterar ditt testprogram med att visa dess källkod. Det kan du göra antingen via filändelsen .phps (visa php källkod om konfigurerat i webbservern) eller genom att använda skriptet source.php (senaste versionen finns via dbwebb.se/source eller https://github.com/mosbth/Utility/blob/master/source.php). 

Mallen till testprogrammen
Tjuvkika gärna på exempelprogrammen på dbwebb.se/examples. Vill du göra ett eget så kan du använda mallen, http://dbwebb.se/examples/mall.php, och ladda sedan upp det på driftsservern.

Lycka till!

Unix, rättigheter på kataloger och filer

Här följer en text som förklarar filrättigheter i Unix (eller Linux). Om du undrar vad skillnaden är mellan 644 och 755 så har du hamnat rätt.

Filrättigheter
När det gäller filrättigheter talar vi ofta i termer av 755 eller 644. En fil, eller katalog, har alltid en ägare och en grupp. Den första siffran anger vad objektets ägare får göra, den andra siffran anger vad medlemmar av gruppen får göra och den tredje siffran anger vad alla andra får göra med objektet.

Siffrorna som används för att representera filrättigheterna, 755, 644 osv, är addition av r (4), w (2) och x (1). r står för read (läsbar), w för write (skrivbar) och x för executable (körbar).

755 (rwxr-xr-x) betyder att användaren får läsa, skriva och exekvera medans gruppen och alla andra får läsa och exekvera. Detta används ofta på kataloger eller körbara filer. Det är viktigt att en katalog är "körbar", annars kan användaren inte ställa sig i den med "cd".

644 (rw-r--r--) betyder att användaren får läsa och skriva medans gruppen och alla andra endast får läsa. Detta används på vanliga filer, kod eller dokument.

Detta är de två vanligaste sätten att definera rättigheter på en fil eller katalog i Unix. Vill du ha en mer utförlig förklaring, och få koll på specialfall, då rekommenderas att läsa manualsidan för kommandot chmod (change mod), det är kommandot som ändrar fil-rättigheter i ett Unix-system.

http://www.freebsd.org/cgi/man.cgi?chmod

Default-rättigheter

När du skapar en ny fil eller katalog så ges den default-rättigheter. Dina default-rättigheter styrs av din startupfil och kommandot umask. Läs följande artikel om du vill ändra dina default-rättigheter.

http://db-o-webb.blogspot.com/2009/09/sshstudentbthse-editera-initfilen-vid.html

Rättigheter och webbplatser

När vi jobbar med webbplatser så är det viktigt att webbservern kan läsa våra filer och kataloger. Därför använder vi 755 på kataloger och 644 på filer. Det skadar inte om du använder 755 på dina filer, det fungerar, men är inte "semantiskt" korrekt.

Om du har fel rättigheter, kan det betyda att webbservern ej kan läsa dina filer eller kataloger, då kan du få följande fel.

Fel rättigheter på fil (se skillnaden mellan php- och html-filer):
http://dbwebb.se/examples/forbidden.php
http://dbwebb.se/examples/forbidden.html

Fel rättigheter på katalog:
http://dbwebb.se/examples/forbidden

Sätt på output buffering i PHP

Artikeln är flyttad till det nya dbwebb-forumet: http://dbwebb.se/forum/viewtopic.php?t=3556

--

Output buffering är ett sätt att undvika felmeddelanden i form av :

Warning: Cannot modify header information - headers already sent by (output started at /home/saxon/teachers/tek/mos/www/test/1.php:2) in /home/saxon/teachers/tek/mos/www/test/2.php on line 4

eller

Warning: Cannot modify header information - headers already sent by (output started at /usr/home/mos/htdocs/dbwebb.se/htmlphp/kmom04/me2/incl/config.php:4) in /usr/home/mos/htdocs/dbwebb.se/htmlphp/kmom04/me2/incl/test/kmom03_sessiondestroy.php on line 17 

Med output buffering så buffras all output och skickas när den är klar. Du ändrar detta beteende i php.ini-filen eller med en .htaccess-fil.

Välj något av alternativen för att sätta på eller stänga av output buffering.

php.ini:
output_buffering=4096
output_buffering = Off

.htaccess i samma katalog som din webbapplikation:

php_value output_buffering 4096

php_value output_buffering Off

I studentmiljö och för utveckling så kan det vara okey att använda output_buffering för att komma runt problemet. Om du kodar för en riktig webbplats så bör du dock ta reda på det egentliga problemet och skriva din kod rätt.

Men, det funkar utmärkt som en snabb "workaround".

Felmeddelandet "Cannot modify header" beskrivs i följande artikel:
http://db-o-webb.blogspot.com/2010/02/warning-cannot-modify-header.html

Ändra teckenkodning i jEdit

Detta är för dig som vill byta teckenkodning för texteditorn jEdit.

Du kan ändra teckenkodning dels i nuvarande fil och dels som globala default inställning för alla nya filer.

Så här ser det ut när du byter till UTF-8 för nuvarande fil (Utilities - Buffer Options).

Ändra till UTF-8 för nuvarande öppna fil.

Så här ser det ut när du ändrar till UTF-8 i de globala default inställningarna (Utilities - Global Options).

Ändra till UTF-8 för alla nya filer.

Dubbelkolla vilken teckenkodning som gäller för nuvarande fil, antingen genom att öppna (Utilities - Buffer Options) eller genom att titta längst ned i statusraden på sidan.

Ett bra tips är att starta om applikationen när du gjort ändringarna. De filer som redan är öppna har kvar sina "buffer options".

Visar UTF-8 som nuvarande teckenkodning.

Teckensätt, varför blir mina åäö konstiga (character set, charset, collation)

Detta är en minnesanteckning till mig själv att bättre förklara hur man som utvecklare kan och bör hantera teckenkodning i databaser, webb och php.

Följande har jag hittills.

iso8859-1 och utf8, så här ser filerna ut i webbläsaren vid mixtrade teckensätt.
http://www.student.bth.se/~mos/charset/

Det är utf8 i databasen men inte i min webbapplikation?
Sätt teckensätt på klient/server-kopplingen med php-mysqli-funtionen:
http://se.php.net/manual/en/mysqli.set-charset.php

Läs om bakgrunden i MySQL's manual (flera sidor, pekar till ett bra ställe att börja läsa):
http://dev.mysql.com/doc/refman/5.1/en/charset.html

Mer?
Var konsekvent, använd samma teckensätt i alla delar av applikationen, då funkar det.

Problem att skapa MySQL tabeller med ENGINE=InnoDB

"PHP och MySQL.
Jag försöker skapa två tabeller med ett FOREIGN KEY constraint och jag använder ENGINE=InnoDB. Jag använder multi_query(). Jag får följande felmeddelande:

Error code: 1005 (Can't create table 'test.test_professor' (errno: 150))"

Problemet uppkommer ofta i kursen dbwebb:kmom05. Vi har haft detta problem ett tag tillbaka. Det är rimligt att det är relaterat till följande MySQL-bugg:

http://bugs.mysql.com/bug.php?id=40877 (precis som någon antyder i flashback-forumet)

Ett möjligt problem i sammanhanget är att installationsprogrammet på Windows Essentials installerar InnoDB som default storage engine. Normalt är det MyISAM som är default. Av denna anledningen så är det klart rekommenderat att explicit ange vilken storage engine som avses vid CREATE TABLE.

Dokumenterar att InnoDB är default i MySQL Essentials på Windows.
http://dev.mysql.com/doc/refman/5.1/en/innodb.html

"The Windows Essentials installer makes InnoDB the MySQL default storage engine on Windows, if the server being installed supports InnoDB."

Visa (SHOW ENGINE) vilken storage engine som för tillfället är default i din databas.
http://dev.mysql.com/doc/refman/5.0/en/show-engines.html

Jag gjorde ett testfall och testade på två olika maskiner.

Koden till testfallet på GitHub.
http://github.com/mosbth/Utility/blob/master/multiquery_foreignkey_fails_errorcode_150.php

Fails on MySQL 5.1.38 using Engine=InnoDB and multi_query().
http://dev.phpersia.org/utility/multiquery_foreignkey_fails_errorcode_150.php

Works on MySQL 5.0.51.
http://www.student.bth.se/~mos/utility/multiquery_foreignkey_fails_errorcode_150.php

För att undvika problemet så byt ut ENGINE=InnoDB till ENGINE=MyISAM.
Eller ange ENGINE=MyISAM explicit (om InnoDB är default).
Eller exekvera SQL-kommandona ett och ett med query() (istället för multi_query()).
Eller välj en MySQL version där problemet är löst (se buggrapporten för detaljer).

Enligt buggrapporten skall problemet vara löst from release 5.1.42. Se changeloggen.

"Multiple-statement execution could fail. (Bug#40877)"

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-42.html

2010-04-28: Jag kan med testprogrammet återupprepa samma problem med Engine=InnoDB och multi_query() på  5.1.45 (Windows 7). Problemet kvarstår sålunda. Jag gjorde en ny sökning i MySQL bugdatabas och möjligen är följande buggrapport (en spinoff på bug#40877) en lösning på problemet.

http://bugs.mysql.com/bug.php?id=48024

Warning: Cannot modify header information - headers already sent by (output started at...)

Artikeln är flyttad till det nya dbwebb-forumet: http://dbwebb.se/forum/viewtopic.php?f=12&t=3557

---

Ett vanligt felmeddelande, och ibland svårt att finna orsaken till, är följande:

Warning: Cannot modify header information - headers already sent by (output started at /home/saxon/teachers/tek/mos/www/test/1.php:2) in /home/saxon/teachers/tek/mos/www/test/2.php on line 4

Eller som i bilden nedan.

Felmeddelandet innebär att output (till webbläsaren)  har startat och därmed har HTTP headern skickats. Troligen försöker du göra någon funktion som påverkar header-informationen, tex genom att anropa funktionen header() eller påverka sessionen. Därav felmeddelandet, på ren svenska:

"Jag har redan skickat header-informationen, du kan inte påverka den."

Felmeddelandet kan innebära att man skrivit ut data till webbläsaren, innan man anropat funktionen header(). Den direkta orsaken är ofta tomma rader/mellanslag/tab före starttag (<?php) eller efter slut-tag (?>). 

Problemet kan också inträffa när man börjar använda sessioner. Även där är ofta den direkta orsaken att man skrivit ut något (echo) eller har tomma tecken/rader (mellanslag, tab, ny rad) innan man startat sessionen (session_start()). En bra förklaring på detta finns på följande inlägg:

http://stackoverflow.com/questions/2173826/warning-can-not-modify-header-information-header-already-sent-by-output-starte

Felet kan också bero på att man inkluderar filer som är sparade som UTF BOM. Spara dem som UTF8 no-BOM. UTF8 BOM innehåller ett par tecken i början av filen. Det gör inte UTF8 no-BOM

http://en.wikipedia.org/wiki/Byte_order_mark

Se till att ha filen source.php i katalogen så brukar det vara enklare att felsöka och leta. Senaste versionen av source.php finns på github:

http://github.com/mosbth/Utility eller http://dbwebb.se/source

Ett vanligt sätt att undvika dessa problem är att utelämna php-sluttag. Vi rekommenderar att du utelämnar sluttaggen när du kan. Läs om detta på Zends guidelines för kodning (Zend, ett PHP-ramverk).

http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

Ett annat sätt att påverka dessa felmeddelanden är att använda output buffering. Då lagras all output och skickas i en klump när den är klar. Läs om output buffering i följande artikel.

http://db-o-webb.blogspot.com/2011/02/satt-pa-output-buffering-i-php.html

Taktik för felsökning och sätt att skaffa hjälp

Intro
Vår labbmiljö består av flera olika operativsystem, programvaror och vi använder olika webbläsare. Miljön kan vara komplex.

Kurserna samkörs och förutom lärarna så kan du få hjälp av studenter, antingen från din egen kurs eller någon av syskonkurserna. Chansen är stor att någon kan hjälpa dig med dina problem. Fråga snällt.

Här följer några tips som underlättar för dina kompisar (och lärare) att svara på dina frågor och hjälpa dig med felsökning.

1) Felsök och avgränsa felet. 
 Ju bättre du kan avgränsa det desto mindre felkällor att hantera. Minimera och begränsa. Väl avgränsade fel ger ofta snabba svar.

2) Gör ett foruminlägg. 
Säg vilket kursmoment och övning som du gör (berätta var du är i instruktionen). Berätta vad du försöker göra och vilker resultat du förväntar dig. Får du ett felmeddelande så klipp in det exakt.

3) Återupprepa felet.
Beskriv hur man kan återupprepa felet. Om någon annan kan återupprepa felet så brukar det gå snabbt att få hjälp.

4) Bifoga bra-att-ha-saker.
- Ge länkar till din existerande webbapplikation och den länk som ger felet.
- Visa källkoden som genererar felet (http://pastebin.com/)
- Visa skärmdump (http://bayimg.com/, http://tinypic.com/)

5) IRC.
Be om hjälp i chatten (irc://irc.bsnet.se/#db-o-webb). Berätta vilken kurs du gör (oophp, dbwebb, dbwebb2, db) Får du inte svar direkt så avvakta. Häng kvar. Svaret och hjälpen brukar alltid komma.

När du fått svar och löst problemet så skriver du det i forumet. Då hjälper du dina student-kompisar med deras egen felsökning.