Eksamens rapport Informationsteknologi B

Transkript

1 2014 Eksamens rapport Informationsteknologi B Mathias Sondrup, Rasmus Larsen og Jonas Hansen

2 Indhold Indledende afsnit... 5 PROBLEMFORMULERING... 5 KRAV TIL LØSNING... 5 Brugergrænseflade... 5 Funktionalitet... 6 DEFINITION AF MÅLGRUPPE... 7 Løsningsforslag... 7 Løsningsforslag Løsningsforslag Løsningsforslag Valg af løsningsforslag...11 Valg af værktøjer...12 Programmeringssprog...12 PHP...12 MYSQL...12 HTML/CSS...12 Tidsplan...13 Teori...14 Udviklingsværktøjer...14 Programmeringssprog...16 PHP: Hypertext Preprocessor...16 MySQL...22 HTML...26 CSS...29 Usability...30 Client/server...31 KISS...32 Gestaltlovene...32 Indledende kravfangst...35 USER STORIES...35 Overordnet design...36 Gestaltlovene på vores hjemmeside

3 VALG AF FARVER...40 FARVERNES BETYDNING...40 Beskrivelse af udviklingen af server funktionaliteten...42 Resultatopgørelse...54 Evaluerende tanker...55 Konklusion...56 Bilag...57 Kildeliste...57 Kilde kode...58 About.php...58 admin edit_user.php...60 admin_edit_user_info.php...62 blog.php...64 contact.php...67 create_post.php...68 edit_all_users.php...70 edit_post.php...72 edit_posts.php...75 edit_user.php...78 edit_user_info.php...80 index.php...82 log_out.php...84 logged_in.php...85 login.php...86 login_page.php...87 register.php...88 register_check.php...90 register_user.php...91 single_post.php...94 submit_contact.php...96 submit_edit_post.php...97 submit_new_post.php...99 admin_nav.php

4 config.php functions.php nav.php ValidateForm.js style.css reset.css fra 4

5 Indledende afsnit PROBLEMFORMULERING Dette projekt arbejder med at udvikle en fodboldblog, hvor fodboldinteresserede kan finde fodbold artikler på en nem og simpel måde. Vi har opstillet en række problemstillinger, som skal være grundlag for vores hovedidé. Løsningsforslaget skal være funktionelt og brugervenligt. Hvordan aktiverer vi brugerne bedst mulig? Hvordan skaber vi en attraktiv og brugervenlig blog, som kan fange de fodboldinteresseredes interesse? Hvilke farver skal vi anvende på bloggen? KRAV TIL LØSNING I forbindelse med udviklingen af vores produkt, herunder vores fodbold blog har vi valgt at opdele vores krav i 2 kategorier. Den første kategori dækker over krav til selve brugergrænsefladen. Disse krav er sat på baggrund af vores problemformulering, målgruppe samt vores egne erfaringer af hvad der normalt fungerer bedst. Den anden kategori dækker over de krav vi har for selve funktionaliteten af bloggen. Brugergrænseflade Bloggen skal være simpelt opbygget, så brugeren har fokus på sidens formål nemlig at formidle information omkring fodbold som kommer ved læsning af artiklerne. Det er derfor vigtigt at der ikke er alt for meget støj som er med til at fjerne fokus fra artiklerne. Derfor skal siden opbygges efter KISS prencippet. Anvende farver til forskellige funktioner som brugeren kan relatere til som derfor vil gøre det lettere for brugeren at benytte hjemmesiden. Det skal være nemt for brugeren at navigere rundt på hjemmesiden og finde frem til forskellige kategorier på hjemmesiden. Derudover er det også vigtigt at brugeren er opmærksom på hvor på siden man befinder sig. Alt information skal være tilgængeligt på de forskellige sider, så brugeren ikke skal bruge tid på at udforske hjemmesiden. Det er derfor vigtigt at der ikke anvendes dropdown menuer eller andet hvor brugeren skal gøre noget aktivt før alt information vises. 5

6 Funktionalitet Der skal være en log ind funktion på hjemmesiden, hvor det både skal være muligt at oprette brugere samt logge ind på selve hjemmesiden og logge ud igen. Oprettede bruger skal inddeles i 3 forskellige kategorier hvor der vil blive givet mulighed for forskellige funktioner. o Kategori 1 er den højeste status en bruger kan have som kun skal gives til administrator på siden. Kategorien skal give mulighed for alle funktioner på siden, herunder: Redigerer af egen bruger. Redigerer andre brugere på hjemmesiden. Lave opslag / artikler på siden. Redigere opslag / artikler der allerede er på hjemmesiden. o Kategori 2 er den næste bedste status en bruger kan have og skal give mulighed for følgende funktioner: Redigerer af egen bruger. Oprette opslag / artikler på siden. Rediger opslag på siden som personen selv har oprettet. o Kategori 3 som er den laveste status en bruger kan have, som giver mulighed for følgende funktioner: Rederigering af egen bruger. Det skal være muligt for dem der bruger siden at kunne oprette en bruger til siden, som man kan anvende til at logge ind på siden. For at oprette en bruger skal man udfylde følgende informationer: Brugernavn, Password, , Fornavn og Efternavn. Det skal være muligt at logge ind på siden ved hjælp af log ind knappen, hvis man har oprettet en bruger på hjemmesiden. Det skal være muligt for personer der logget ind på siden, uanset hvilken status brugeren har at redigerer / opdaterer ens egen oplysninger, herunder Brugernavn, , kode, Fornavn og Efternavn. Det skal være muligt for brugere med status 1 at redigerer på andre brugere og deres bruger oplysninger, herunder de generelle oplysninger den almene bruger også selv kan ændre, plus hvilken status brugeren skal have. Det skal være muligt at kunne oprette opslag / artikler for brugere med status 1 eller 2, hvor brugeren skal udfylde følgende felter: Overskrift, brødtekst, kategori samt upload af billede. Dets skal være muligt at kunne ændre på de opslag / artikler der er blevet oprettet på siden. Brugere med status 1 skal kunne ændre på alle opslag / artikler på siden, hvorimod brugere med status 2 kun kan redigerer opslag / artikler som man selv har oprettet på siden. 6

7 Det skal være muligt at kunne sortere i opslagene / artiklerne ud fra hvilken kategori de ligger ind under (kategori = fodbold liga), så der kun vises opslag / artikler fra den valgte kategori. Skal være muligt at kunne trykke læs mere på de opslag / artikler der er vist på forsiden samt blog siden, hvor man så vil blive ført hen på en anden side hvor hele artiklen vil blive vist. DEFINITION AF MÅLGRUPPE Vi vil fokusere på den moderne del af befolkningen, som hører indenunder det blå segment i Minerva-modellen. Dette segment interesserer sig meget for udviklingen og ny teknologi, hvor de benytter internettet til at få information, hvilket vi mener, er en ideel målgruppe at gå efter. Vi vil særligt fokusere på det segment, som er interesseret i fodbold og har interesse for at holde som opdateret omkring fodbold verden ved at læse opslag / artikler på nettet. Løsningsforslag Til vores fodbold blog har valgt at lave 3 forskellige løsningsforslag, som alle sætter fokus på forskellige aspekter. Her har vi primært valgt at eksperimenterer meget med brugergrænsefladen og hvordan den kunne opbygges på forskellige måder, så bruger oplevelsen blev forandret. Nedenfor ses en liste af ting vi har eksperimentet med: Farver KISS Gestaltlovene Usability 7

8 Løsningsforslag 1 Beskrivelse Vores første løsningforslag er en af de mere omfattende blogge sådan rent design mæssigt godt kan minde om avis hjemmesider herunder BT, Politikken, Ekstra Blandet osv. På grund af den store mængde artikler / blogopslag som brugeren bliver mødt af på bloggens forside. På bloggens forside vil artiklerne være inddelt i kategorier så brugeren kan danne sig et overblik over de forskellige kategorier uden at skulle udforske bloggen yderligere ved brug af bloggens menu. Fordele Mulighed for brugeren for at få et overblik over kategorier på bloggen samt nyeste blogindlæg. Stor mulighed for bloggeren for at have en bred vifte af kategorier samt blogopslag i de forskellige kategorier uden at det bliver for svært at finde dem. Ulemper Mængden af information på forsiden er meget stor og kan derfor godt virke meget uoverskueligt. Det vil kræve en del front end samt back end for at få bloggen til at fungere funktionel. På grund af den store mængde information på forsiden, vil der være risiko for at loading tiden bliver relativ høj især hvis billederne ikke er komprimeret. Den information der gives til hvert opslag er meget basal og det vil derfor være en nødvendighed at gå på det enkelte opslag for at få en større mængde information. 8

9 Løsningsforslag 2 Beskrivelse Vores andet løsningforslag er en af de mere traditionelle blogge, hvor brugergrænsefladen er opbygget meget simple. Bloggen er opbygget af en header i toppen som givet et overblik over de forskellige kategorier der er på siden, derunder er siden opdelt to. Til venstre ses de nyeste opslag, hvor der først er et billede og derefter en god mængde tekst som giver et indblik i opslaget. Delen til højre fungerer mere som en reminder om forskellige ting, herunder nyhedsbrev om fx nye artikler, kategorier, sociale medier osv. Fordele Brugeren får en stor mængde information om de nyeste opslag på siden og behøver nødvendigvis ikke at gå ind på selve opslaget for at afgøre om det er interessant eller ej. Derudover er selve opbygningen på siden utrolig simpel og det vil derfor være ekstremt nemt at navigere sig rundt på siden. Ulemper På grund af at hvert enkel opslag fylder så meget, har brugeren kun adgang til en lille mængde opslag på forsiden af gangen og det kan derfor være svært for den enkelte bruger at finde lige præcis det opslag som han eller hun gerne vil finde. 9

10 Løsningsforslag 3 Beskrivelse Den sidste og tredje løsning minder meget om det andet løsningsforslag. Forskellen er dog at dette løsningsforslag er forsimplet yderligere ved at droppe indramningerne af de enkelte opslag samt sub menuen i venstre side er blevet fuldstændig fjernet. På den måde skal forbrugeren kun have fokus på selve menuen samt opslagene. Derudover er der lavet nogle ændringer i forhold til hvordan tingene er fremvist herunder logo, menu, overskrift og dato samt tid på opslagene. Fordele På grund af den lille mængde information som brugeren bliver mødt af, er det super nemt for brugeren at danne sig et overblik over siden og derfra navigere sig videre. Brugeren får en stor mængde information om de nyeste opslag på siden og behøver nødvendigvis ikke at gå ind på selve opslaget for at afgøre om det er interessant eller ej. Da siden er så simpel opbygget både når det kommer til farver og indramning af objekter, bliver brugerens fokus på opslagene som er hele ideen med bloggen ikke forstyrret af andet støj Ulemper Svært at få et komplet overblik over hvilke artikler som bloggen kan indeholder. 10

11 Valg af løsningsforslag Vi har valgt at vi gerne vil have at vores blog skal være super simpel så brugeren kan fokusere på det der relevant og at det skal være super nemt at navigere rundt på siden. Grunden til at vi har valgt at det skal være nemt og simpelt er fordi vi målrettet går efter læseren som allerede er interesseret for fodbold og ved hvad han gerne vil læse noget om. Derfor behøver læseren ikke et større udvalg af forskellige kategorier samt opslag under de enkelte kategorier for at navigere rundt på siden. Vi har derfor valgt at gå med løsningsforslag 3, da vi mener det er det løsningsforslag som passer bedst over ens med den blog vi vil producere i forhold til vores målgruppe. 11

12 Valg af værktøjer Programmeringssprog PHP Grunden til at vi har valgt at bruge PHP som vores server sprog i dette projekt er, at PHP for det første er et gratis open source sprog, dette gør at alting ligger offentligt tilgængeligt omkring sproget. Samtidigt med dette har PHP en ekstremt god dokumentation hvilket gør det meget nemmere at arbejde med. Derudover har vi også arbejdet med dette sprog hvilket gør det oplagt at benytte i forhold til sprog som ASP som vi ikke har arbejdet med før. MYSQL MYSQL er den mest normale type database at bruge, vi har derfor også valgt at bruge denne. Både på grund af tidligere erfaring vi har med brugen af denne database, samtidigt med at den er ekstremt godt integreret i langt de fleste web servers og i vores backend sprog PHP. HTML/CSS Til at lave frontend delen af vores hjemmeside har vi valgt HTML og CSS. Der er ikke rigtigt så mange muligheder ud over disse to til at lave denne del af hjemmesiden. Man kunne have lavet det XML, men da man alligevel vil skulle bruge en konverter til at lave disse XML dokumenter om til HTML i sidste ende så vi ingen grund til dette, da vi også allerede har en del erfaring i at bruge HTML og CSS. 12

13 Tidsplan 13

14 Teori Udviklingsværktøjer Sublime Text 3 Beta Sublime Text 3 Beta er det udviklingsværktøj som vi bruger til at skrive vores kode i, det er derved også det vigtigste af vores udviklingsværktøjer. Dette er et program der har en ekstremt simpel brugergrænseflade, hvor der nærmest ikke er nogle knapper, som der kan være med til at distrahere en mens man skriver kode. Dette betyder at alt man gør i programmet derfor foregår enten ved hjælp af de menuer som der er i toppen af skærmen, hvilket er en meget langsom metode. Ellers foregår alle aktionerne ved hjælp af hotkeys, denne mulighed for at gøre alting med hotkeys gør, at man kan arbejde ekstremt hurtigt i programmet, da alle funktioner kan tilgås ekstremt hurtigt. I sidste ende betyder dette at man kommer til at have et meget bedre workflow i programmet da man ikke hele tiden har brug for, at fjerne sine fingre fra tastaturret hver gang man skal bruge en funktion i programmet, da man bare lige trykke på en hotkey. Samtidigt med disse hotkeys er det muligt at ændre næsten hele programmet således at det passer lige præcis til den måde man selv arbejder bedst på. Dette kan gøres både ved hjælp af indstillinger i programmet, men også ved at installere plugins til programmet. Disse plugins kan være alt fra ændring i farven på teksten og baggrunden i programmet, til radikale ændringer i hvordan man skriver kode i programmet ved hjælp af en række shortcuts som gør at man kan skrive koden hurtigere. MAMP Det andet værktøj vi bruger i udviklingen af vores produkt er MAMP, dette står for Mac Apache MySQL PHP. Vi bruger under udviklingen MAMP som en server der køre på vores egen computer og som vi tilgår via localhost:8888 domænet i vores browser. Det denne server gør under udviklingen er at den fortolker vores PHP og sender HTML videre til browseren således, at den kan vise siden. Hvis vores PHP filer ikke blev fortolket af en server, ville der ikke være noget HTML som vores browser kunne læse. Grunden til dette er som vi senere vil komme ind på at PHP er et server sprog, altså et sprog der bliver fortolket på serveren og ikke hos klienten. Samtidigt med dette står MAMP også for opbevare vores MySQL database, samt sørge for adgang til denne, både ved hjælp af terminalen og ved hjælp af et værktøj inkluderet i MAMP der hedder PHPMyAdmin. Under udviklingen benytter vi os betydeligt mere af PHPMyAdmin end af terminalen. Grunden til dette er at det er betydeligt nemmere at redigere i en database ved hjælp af PPHMyAdmin, da man på denne måde har et GUI at se databasen i. I stedet for bare at have et terminal vindue som man vil have ved brug af terminalen. 14

15 Der er dog også fordele ved at bruge terminalen, den vigtigste af disse fordele er at man kan arbejde betydeligt hurtigere ved at bruge terminalen når man fuldstændig har lært alle de forskellige MySQL commands samt den rigtige syntaks at bruge dem i. Da vi ikke har helt nok erfaring i brugen af MySQL til dette har vi valgt bare at benytte os af PHPMyAdmin. 15

16 Programmeringssprog PHP: Hypertext Preprocessor PHP er et open source server sprog, og det er dette sprog vi har valgt at skrive vores server kode i. Dette betyder at alt det kode der køres af serveren udover database koden er skrevet i PHP. Da PHP er et kæmpe stort sprog, der kan bruges til at lave ekstremt mange ting, vil vi i dette afsnit ikke afdække alle de ting som PHP kan. Vi vil derimod fokusere på de ting som vi har benyttet PHP til i vores projekt. En af de helt store og relativt nye features i PHP er at man kan skrive objekt orienteret kode med det, det har vi i dette projekt undladt at gøre da vi mente at det ville være mest optimalt at undlade dette. Functions & Variables Funktioner og variabler er to meget simple dog ekstremt vigtige ting i alle programmeringssprog og dermed også i PHP. En variable kan egentlig ses som en boks. Denne boks har et navn og indeholder noget, dette kan være en string, integer, boolean eller en helt fjerde data type. Dette betyder at variabler egentlig er det der gør at vi kan holde styr på alt vores data. En mere avanceret type variable end disse variabler der kun inde holder en ting hver, er arrays. Et array er en liste der indeholder flere variabler under samme navn, som man så kan tilgå ved hjælp af det navn de selv har i arrayet. Et eksempel på et array skrevet i PHP kan ses nedenfor. $names = array( Jonas, Mathias, Rasmus, Mikkel ); Her kan man se at variablen ved navnet $names er et array. Dette array indeholder fire værdier Jonas, Mathias, Rasmus og Mikkel. Disse navne kan nu tilgås ved hjælp af det nummer de ligger som i arrayet. Dette vil sige at hvis vi gerne vil tilgå navnet Rasmus, ville vi skrive $names[2]. Grunden til at vi bruger nummeret to her til at få fat i den tredje værdi er at arrays i PHP er 0 baseret, hvilket vil sige at den første værdi har nummer 0. Udover at indeholde værdier kan arrays også indeholde andre arrays således at man kan have arrays der ligger inde i arrays. Dette kan være ekstremt praktisk hvis man skal opbevare store mængde data og gerne vil have det overskueligt. 16

17 En funktion er et stykke kode der ligger gemt under det navn som funktionen har. En funktion adskiller sig fra en variable ved at den både kan modtage inputs når man kalder den, samtidigt med at den også vil returnere en eller flere værdier. Selvom det ikke er altid at en funktion returnere en værdi, vil den de gange den ikke gør have kørt noget kode som har haft indflydelse på siden. Måden en man skriver en funktion i PHP ses nedenfor. function name( parameter_one, parameter_two ){ code segment... Som det kan ses her så starter man ved at bruge nøgleordet function dette giver PHP besked om at det her er en funktion. Herefter kommer navnet på funktionen i dette tilfælde name det efterfølges af en parentes. Inde i denne parentes er de parametre som funktionen modtager når man kalder den. Efter parentesen med parametrene i kommer der en curlybracket som indeholder alt den kode som vores funktion skal køre igennem når den kaldes. Måden man så kalder en funktion er ved at skrive dens navn efterfulgt at en start og en slut parentes. Hvis funktionen acceptere parametre skal disse parametre skrives inde i parentesen. Egentlig er størstedelen af de scripts man skriver i PHP opbygget af en lang række funktioner som der er indbygget, her kan man blandt andet nævne funktioner som session_start() og header(). Disse er begge to funktioner som der er indbygget i PHP. Den ene af dem, header, bruges til at sende en header til browseren, derfor kan denne funktion udelukkende udnyttes inden man har sendt noget som helst HTML til browseren. Da browseren ignorere headers som den modtager efter den er begyndt at vise HTML til brugeren. Den anden bruges til at starte brugen af sessioner på en side således, at man kan udnytte de værdier er gemt i session super globalen. Super Globals (GET POST SESSION) Super Globals er som navnet siger variabler der er mere end globale, altså super globale. Dette betyder at hvor globale variabler bare kan bruges overalt i et PHP dokument, så kan super globals gå mellem forskellige PHP sider. De Super Globals som vi har benyttet os af i vores projekt er GET, POST og SESSION. Selvom alle disse tre er Super Globals er de meget forskellige over virker på vidt forskellige måder. Det de dog alle sammen har tilfældes er at de alle er arays, dette vil sige at de skal tilgås som beskrevet ovenfor. Udover dette er de også de eneste variabler der starter med underscore og så skrives de også altid med stort. 17

18 GET GET Super Globalen er den mest usikre af alle Super Globalsne. Grunden til dette er at den skrives direkte i URL linjen, og den kan derfor meget nemt blive både læst og ændret af brugeren. Det er derfor vigtigt at man aldrig sender vigtige og sensitive oplysninger mellem sider ved hjælp af GET. Måden man skriver en GET variable er ved at tilføje et spørgsmåltegn bag en sides URL. Efter dette spørgsmålstegn tilføjer man så navnet på ens variable, efter dette navn indsætter man et lig med og så den værdi variablen skal være lig. Et eksempel på dette kan ses nedenfor. Her kan man se at selve sidens domæne er: og GET delen af denne URL string er?id=17. Som det kan ses her har vi som før nævnt spørgsmålstegnet for at vi at det nu er en GET variable vi skriver. Herefter har vi variable navnet id og til sidst har vi det som variablen bliver sat til som i dette tilfælde er 17. Når man skal tilgå denne variable i vores kode, skriver vi lige som med alle andre arrays navnet på arrayet, dog bruger vi ikke et nummer som indeks her. I stedet bruger vi navnet på variablen, som i dette tilfælde er id. Dette betyder at koden for at sætte en local variable i dette tilfælde $id til at være lig variablen fra GET Super Globalen kommer til at se således ud. $id = $_GET[ id ]; POST Den anden af de Super Globals vi bruger er POST. Denne Super Global sendes mellem siderne som en del af den HTTP body der sendes mellem sider. Dette betyder at det for det første er betydeligt svære overhovedet at finde frem til disse værdier i vores browser da vi skal ind og bruge nogle af de værktøjer der er indbygget i browseren. Yderligere kan man ikke ændre på disse, variabler i browseren, dette gør at de er meget mere sikre at sende oplysninger mellem sider med. Selvom man stadig vil kunne finde dem i browseren. Grunden til at det ikke gør så meget at disse variabler kan findes af brugeren i browseren er at POST requests normalt er indtastet af brugeren selv, og det betyder derfor ikke særlig meget at brugeren kan læse hvad de selv har skrevet. Da POST metoden er mere sikker end GET bruger vi igennem hele vores projekt denne Super Global, til at håndtere forms. Dette betyder at vi hele vejen igennem projektet holder alt information som vi får indtastet af vores bruger væk fra URL linjen. Samtidigt med at vi holder denne information sikker, således at det ikke er lige så nemt at gå uden om for eksempel vores log ind system. 18

19 SESSION Den sidste af de Super Globals som vi benytter i vores system er SESSION Super Globalen. Denne er lige som de andre et array med en række data i, som man tilgår ved at skrive: $_SESSION efter fulgt at et indeks for hvilken værdi i arrayet man gerne vil have fat i. Selvom man henter data fra denne Super Global på nogenlunde samme måde som med de andre, er denne dog rimelig unik i forhold til GET og POST. Den minder betydeligt mere om den fjerde Super Global COOKIE som vi ikke har benyttet os af i vores projekt og derfor ikke vil afdække her.måden denne Super Global er ved at gemmer en session cookie på brugerens computer, denne cookie indeholder et nummer. Serveren gemmer så alt det data der er gemt i denne SESSION, på serveren under dette nummer. Dette betyder at alt data der er gemt i SESSION Super Globalen er sikkert, da det jo ligger på serveren og ikke på brugerens computer i en cookie, som det ville ved brug af COOKIE Super Globalen. SESSION er lidt svære at sætte op end POST og GET. Grunden til dette er at man på hver eneste side man gerne vil benytte sig af dette SESSION array skal kalde funktionen session_start først. Når denne funktion er blevet kaldt kan siden tilgå SESSION Super Globalen. Når man først et nået til dette punkt er SESSION rimelig simpelt at bruge da man bare kan lave sætte nye SESSION variabler ligesom man ville gøre med alle andre variabler. Forskellen er bare her at man kan tilgå disse variabler på alle sider, indtil brugeren browser lukkes ned. Det er nemlig en meget vigtig ting at være klar over ved brugen af SESSION Super Globalen. En SESSION vare kun indtil browseren bliver lukket ned, så snart at brugeren lukker browseren så vil SESSION variablen blive slettet. Det er også vigtigt at være opmærksom på at det ikke er når den fane som brugeren benytter vores PHP side i lukkes ned, det skal være hele browseren der lukkes. En anden måde en SESSION kan sluttes på er ved at der ved hjælp af PHP kaldes session_destroy, denne funktion går ind og ødelægger den gemte SESSION, hvilket betyder at når brugeren loader en ny side, vil denne side ikke kunne tilgå den gamle SESSION. Dog kan den side der har kaldt session_destroy godt tilgå SESSION variablen indtil siden reloades. Det som vi benytter SESSION Super Globalen til i vores produkt er at holde styr på om brugeren er logget ind eller ej. Måden vi gør dette på er ved at gemme en SESSION når brugeren logger ind, denne SESSION indeholder brugerens id, status, username samt en variable der bare viser at brugeren er logget ind. Disse informationer bruges så på alle siderne i vores produkt, til at for det første at se om brugeren er logget ind, men også til at se om de har den status der kræves for at må gå ind på forskellige sider. 19

20 Loops Det eneste loop som vi har brugt i vores produkt er foreach-loopet, vi har ikke benyttes os af hverken for-loops eller while-loops da vi ikke har haft brug for disse. Vi vil derfor kun forklare om foreach-loopet i dette afsnit. Et foreach loop er opbygget som ses nedenfor: foreach ($data as $row) { code segment Som det kan ses ovenfor starter et foreach loop med nøgleordet foreach, dette er det ord der fortæller PHP at det der kommer nu er et foreach loop. Dette efterfølges af en parentes der indeholder det array som vores foreach loop skal køre igennem, og det navn som hver variable i foreach loopet skal have inde i foreach loopet. Herefter er der to curlybracket, i mellem disse er koden der skal køres så.det der afgør hvor mange gange et foreach loop køre er hvor mange værdier der er i det array som gives til foreach loopet. Dette betyder at hvis arrayet har en længde på 10 værdier, så vil loopet køre 10 gange. Dette er meget brugbart, især når vi henter data fra vores database. Her bruger vi foreach loopet til at behandle data fra vores database en række af gangen. If statement If statements er endnu en meget vigtig ting i PHP, og det er meget svært at lave et program der ikke indeholder dette. Funktionen af at if statement er at tjekke om et udtryk er sandt eller falsk. Dette er ekstremt vigtigt i ethvert program, at kunne tjekke hvad forskellige variabler er sat til, og derved kunne ændre hvad siden gør ud fra dette. Måden et if statement er bygget op på kan ses herunder: if(condition == true){ code segment Som det kan ses ovenfor starter et if statement ligesom nærmest alle andre ting i php med et nøgleord som i dette tilfælde er if. Herefter kommer der ligesom ved et foreach loop, en parentes hvor i den eller de ting der skal testet skrives. Herefter kommer der som der altid efter en test, en curlybracket som indeholder det kode der skal køres ved testen returnere true eller sandt. 20

21 Et eksempel på det vi har benyttet if statements til i vores produkt kunne være at tjekke om man er logget ind eller ej. Som det kan ses på billedet nedenfor er dette gjort inde i en funktion så vi bare kan kalde funktionen hver gang vi skal teste om en bruger er logget ind, i stedet for at skulle skrive hele if statementet igen. Som det kan ses er dette if statement inde i en funktion der hedder check_if_logged_in. I dette if statement tjekker vi om $_SESSION[ logged_in ] ikke er sat, samtidigt tjekker vi om $_SESSION[ logged_in ] er sat til true. Måden dette if statement er konstrueret på er at hvis bare en af disse to test returnere sandt, så vil testen blive sand. Og i dette tilfælde sende en header med værdien location: index.php. Det som denne header gør at sende brugeren til siden der hedder index.php. Dette er kun et meget lille eksempel på hvad man kan lave med if statements. De er noget af det kraftigste i alle programmerings sprog, da de bruges til alting. PDO PDO står for PHP Data Objekt. Dette objekt er en relativ ny ting i PHP, det erstatter den gamle metode som man brugte til at tilgå en database, og gør at man kan forbinde og interagere med en database betydeligt nemmere, samt mere sikkert. Da PDO som sagt er et objekt, kan vi ikke bare calle dette som en funktion. Vi er her nødt til at bruge en constructor metode. Måden denne metode kaldes kan ses nedenfor. Her på billedet konstruerer vi en ny udgave af PDO objektet ved hjælp af nøgleordet new. Dette bliver efterfulgt af PDO som bliver kaldet som en funktion, der kan modtage en række parametre. Det første af disse er hvilken database der skal tilsluttes til. Her skal angives, typen af database, databasens vært og databasens navn. Dette bliver i vores tilfælde til denne string: "mysql:host=$dbhost;dbname=$dbname". Herefter skal denne funktion have to paramtre mere, username og password til brugeren. Når den har disse kan den oprette forbindelse til serveren, og vi kan derved interagere med vores server. Efterfølgende sætter vi dog også to attributter til dette PDO objekt. Disse er ATTR_ERRMODE og ERRMODE_EXCEPTION. Disse to attributter gør at vi registrere de fejl der kan opstå under brugen af denne forbindelse, dette er meget brugbart især i udviklingen af siden da vi kan se, hvad grunden til at noget ikke virker er. 21

22 Når man har oprettet en forbindelse til en database ved hjælp af PDO, kan man begynde at benytte alle de metoder som der ligger i PDO objektet. De to mest brugbare af disse er prepare() og execute(). Disse to bruges hver eneste gang vi gerne vil interagere med databasen. Først bruges prepare() metoden, måden denne metode virker er ved at den modtager et statament der passer til den type database som man har valgt at benytte, vores tilfælde er det MySQL. Dog er det ikke hele statementet man indtaster her. Ens værdier indtastes som variabler ved hjælp af at skrive kolon og så et navn i stedet for den egentlige værdi. Herefter går man videre til at bruge execute() metoden, denne metode har brug for et parameter der er en array. Denne array indeholder alle de variabler som vi har sat i vores prepare() metode, måden man skrive dette rent kodemæssigt kan ses nedenfor: execute(array( id => $id, name => $name)); Variable navnene der er blevet sat i prepare() metoden ses her skrevet i situationstegn, disse sættes så til at pege med en anden værdi eller variable som vi har i vores PHP dokument ved hjælp af =>. Når denne execute() metode så vil MySQL statementet fra prepare() metoden blive kørt i datasen, med de værdier der er specificeret i execute(). Grunden til at denne metode til at interagere med en database, er så god at bruge i forhold til de gamle MySQL funktionern i PHP er, at den er betydeligt mere sikker samt mere effektiv. Grunden til, at denne er mere sikker at at de værdier man indtaster i execute() metoden, vil blive escaped for alle specielle karaktere, således at man er sikker på at der ikke ligger noget MySQL kode i disse variabler, som kunne gå ind og ændre på vores database. Dette resultere i at ens forbindelse er meget mere sikker mod SQL injections, da alle de værdier som vi indsætter i vores database udover selve vores MySQL statement, vil blive ændret således at alle karaktere der kunne risikere at ændre noget i vores database ikke længere kan dette. MySQL MySQL er som sådan ikke et programmeringssprog, det er derimod det sprog som vi skriver vores database i. Hele vores database er bygget op i dette sprog, og alt den data som vi har liggende i vores database, ligger gemt i SQL dokumenter. Grunden til at disse dokumenter er SQL og ikke MySQL er, at MySQL bare er en variation af SQL. En ting der er vigtig at være opmærksom på er at alle MySQL nøgleord skrives med udelukkende store bogstaver. De MySQL statements som vi benytter os mest af i vores produkt, og som man også generelt benytter sig mest af i brugen af MySQL er INSERT, SELECT og UPDATE. 22

23 INSERT statementet bruges til at indsætte ting i vores database, syntaksen for brugen af INSERT statements er som følger: INSERT INTO `tabelnavn`(`feltnavn`, `feltnavn2`) VALUES( værdi1, værdi2 ); Her kan det ses at statementet startes med nøgleordene INSERT INTO, disse efterfølges af navnet på tabellen, som vi gerne vil indsætte vores værdier i. Herefter kommer der først en parentes der indeholder navnene på alle de felter som vi gerne vil ændre i tabellen. Denne parentes er efterfulgt af nøgleordet VALUES, herefter kommer der en parentes der indeholder de værdier vi gerne vil indsætte. Måden det afgøres hvilken værdi der skal indsættes i hvilket felt er ved den rækekfølge de kommer i. Dette betyder at den først værdi bliver indsat i det første felt, den anden værdi i det andet felt og så videre. Et SELECT statement bruges til at vælge række fra vores database, SELECT kan både bruges til at finde hele rækker fra databasen, samt at finde enkelte værdier i databasen. Vi har i vores projekt kun benyttet det til at finde hele rækker, det er derfor kun den syntaks jeg vil forklare yderligere, denne ses nedenfor. SELECT * FROM `tabelnavn` Som det kan ses her er syntaksen for dette ekstremt simpel. Det indledes med nøgleordet SELECT dette efterfølges af * som i regulair expressions kan stå for hvad som helst, dette efterfølges af nøgleordet FROM. Efter dette nøgleord kommer navnet på den tabel som vi gerne vil indsætte vores værdier i. Det er dog sjældent at man kun bruger dette meget simple SELECT query. Normalt vil det blive efter fulgt af nøgleordet WHERE, som specificere hvilke rækker fra tabellen vi gerne vil vælge. Syntaksen for brugen af dette sammen med SELECT kan ses her. SELECT * FROM `tabelnavn` WHERE `id` = værdi Som det her kan ses efterfølges WHERE nøgleordet af navnet på det felt vi gerne vil sortere efter, herefter ses den værdi dette felt skal være lig for at rækken vælges. 23

24 Det sidste af de queries som vi gør stor brug af i vores produkt er UPDATE, denne query bruges som navnet beskriver til at opdatere vores tabel. Her kan der ligesom med tilfældet er med SELECT specificeres yderligere hvilke rækker der skal opdateres ved hjælp af WHERE kodeordet. Syntaksen for brugen af UPDATE ses herunder. UPDATE `tabelnavn` SET `feltnavn` = værdi ; Som det kan ses her starter dette query som altid med et nøgleord i dette tilfælde UPDATE, dette efterfølges af navnet på den tabel man gerne vil opdatere. Herefter skrives nøgleordet SET, dette efterfølges af navnet på et felt, samt et lighedstegn og det man gerne vil sætte feltnavnet til. Database Vores database er som sagt lavet i MySQL. Den består af tre tabeller users, posts og contact. Alle disse tabeller har et felt med værdien id, dette id er tabellens primary key, altså en nøgle som er unik for hver række i tabellen. Dette gør at man altid vil kunne finde en specifik række ud fra dette felt i tabellen. Som det kan ses her er id sat som primary key, samtidigt med at den er sat til auto_increment således at den automatisk sættes til et højere end det højeste id der er tilstede på nuværende tidspunkt. 24

25 Nedenfor ses billeder af strukturen på posts tabellen, ligesom ved users er det her id der er primary key. Dette kan ses ved at dette navn er understreget. Til sidst kan herunder ses den sidste tabel i vores database contact. Den gennemgående ting i alle disse tabeller er som tidligere nævnt at id er primary key, samtidigt med at den er sat til auto_increment. 25

26 HTML HTML står for Hyper Text Markup Language, og bruges til at fortælle browseren hvilke noget content den skal vise. HTML dokumenter skrives som rent text og kan derfor skrives i alle text editors som tillader at man gemmer content som ren text. Elements HTML består udelukkende af forskellige sæt af elementer som bruges til at definere den semantiske mening af ens content. Et element inkluderer alt imellem start tag og end tag af to ens tags. Det er dog meget forskellige hvor specifik en betydning forskellige elementer har, nogle er meget specifikke hvorimod andre er mindre præcise. Et eksempel på elementer som har en meget præcis mening kunne være img eller h1 taggsne, som klart og tydeligt betyder This is an image og This is a heading. Hvorimod section tagget ikke har nogen konkret betydning This is a section on the page Et anden ting som også er vigtigt at vide omkring elementer er at de godt kan indeholder andre elementer. Det har så den betydning at der bliver skabt et hierarki i blandt elementer. På billedet nedenfor kan ses et klassisk eksempel på et hierarki blandt elementer hvor <html></html> har den højeste værdi, derefter kommer <body></body> elementer til sidst <p></p>. html elementet: html elementet er roden til et HTML eller XHTML dokument og alle andre elementer skal være placeret indenfor html elementet. Det betyder at html elementet har den højeste status af alle elementer og vil derfor altid være øverst i hierarkiet. 26

27 head elementet: head elementet indeholder en masse metadata omkring HTML dokumentet samt inkludere scripts og fortæller browseren hvor den kan finde de stylesheets som der bliver linket til. Billedet nedenfor viser alle elementer der kan skrives inden i head elementet: body elementet: body elementet indeholder alt content på siden, det vil at alt der vises på siden er skrevet inden i body elementet. Tags Alle elementer indeholder tags. Når man snakker om tags er de defineret ved at de starter med et mindre end tegn ( < ) og slutter med et større end tegn ( > ). Det der er inden for disse to tegn, er så selve tagget. Alle tags har et nøgleord, dette er det ord der beskriver hvad det er for et tag. Et eksempel på dette kan være et p som beskriver at det er et paragraph tag. Der findes som hovedregel to typer tages, starting og closing tags. Disse tags er egentlig ens, udover at starting tagget indeholder de attributter som der er til tagget, og closing tagsne har en skråstreg / efter <. Eksempel på tag der er lukket af default: 27

28 Eksempel der kræves at blive lukket med brug af backslash: Attributes Som nævnt tidligere kan et tag indeholder en attribut. En attribut kan indeholder yderligere information omkring tagget. En attribut består normalt af to dele: Et attribut navn. Et attribut value. Et attribut navn er den attribut du ønsker dit element til at have, hvor attribut valuen er den værdi du ønsker attributten skal have. Et eksempel kunne være et p tag som du ønsker skal have en class, hvor class svarer til attributtens name og den værdi der skrives inde i class, er så denne attributtens value. Det er altid vigtigt at sørger for at attributtens value står i enten quotation marks eller double quotation marks. Doctype Et doctype skal placeres i toppen af HTML dokumentet og fortæller browseren hvilken version af HTML, siden er skrevet i. Måden hvorpå doctypen har været skrevet på i de forskellige versioner har varieret meget, men i den nyeste udgave af HTML HTML 5 skal man skrive følgende: Comments En anden ting som også kan være yderst vigtigt er kommentarer i ens kode. I ens HTML kode kan man lave kommentarer som ikke bliver vist i browseren når siden loades, på den måde kan man lave nyttige kommentarer om hvad de forskellige elementer gør på siden. Man laver kommentar på følgende måde: 28

29 CSS CSS står for Cascading Style Sheets og er et kodesprog som bruges til at specificere hvordan forskellige informationer skrevet i et Markup Language HTML bliver vist for brugeren i fx et browser vindue. På den måde bruger man CSS til at skabe en god brugergrænseflade som øger produktets usability. For at ens informationer skrevet i et Markup Language - HTML kan blive stylet,, kræver det at man forbinder ens HTML dokument med ens stylesheet. Dette gøres ved at inkludere linket til stylesheetet i HTML dokumentets head. Herefter styler man de forskellige elementer ved at man først skriver det element man ønsker at style (selector). Herefter laver man 2 curlibrackets, alt imellem curlibrackets svarer til den style du ønsker at tilføje dit valgte element. Hver enkel style du tilføjer til dit element kaldes en declaration og består af en poperty i dette tilfælde color: efterfulgt af en value svarende til blue; 29

30 Usability Usability handler hvor let det er at benytte menneske skabte objekter, herunder hjemmesider, software og meget meget mere. For at ens objekt har en god usability har Jakob Nielsen usability ekspert, opsat 5 komponenter som skaber et godt usability. Learnability Efficiency Memorability Errors Satisfaction Learnability Hvor let det er for brugeren af benytte hjemmesiden for første gang og udfører helt simple opgaver på siden. Efficiency Når brugeren først har lært designet og hjemmesiden at kende hvor nemt og hurtigt kan brugeren så udfører forskellige opgaver på siden. Memorability Hvis brugeren vender tilbage til hjemmesiden efter en længere periode hvor brugeren ikke har benyttet hjemmesiden, hvor nemt og hurtigt kan brugeren genopbygge sine tidligere færdigheder som han havde i at benytte hjemmesiden. Errors Hvor mange fejl laver brugeren ved benyttelse af hjemmesiden, og hvor ofte opstår disse fejl samt hvor nemt kan brugeren komme videre og igen benytte hjemmesiden efter de hensigtsmæssige årsager. Satisfaction Hvor brugervenligt er designet opbygget - er designet behageligt at anvende. 30

31 Client/server Vi har i vores produkt et stort sammen spil mellem klienten, i dette tilfælde brugerens browser, og vores server. Der er masser af interaktioner mellem klienten og serveren i vores produkt, da hele produktets virkemåde / funktionalitet er opbygget efter det. Alle vores filer som browseren viser, er PHP filer, som først skal fortolkes af en server, før browseren kan vise dem. Det vil sige at måden hvorpå vores klient får fat i oplysningerne omkring en side på, er ved at sende en page request til serveren om en specifik side. Serveren kører så PHP scriptet og sender HTML samt CSS tilbage til browseren. Denne form for request kører hver gang en bruger skal bruge enhver side på vores produkt (som også ligger på serveren). Selvom langt størstedelen af interaktionen mellem serveren og klienten sker ved ganske normale page request, er der også andre interaktioner. En af dem er ved brug af vores post request når en form indsendes. Når dette sker sendes der udover den normale page request også en række post værdier med, som er en yderligere interaktion mellem klienten og serveren. Post request som denne kan vi fx udnytte til at sætte ting ind i vores database. En anden ting som også er muligt for klienten ved brug af browseren er at få uploadet filer, i forhold til vores produkt er der her udelukkende snak om billeder, til vores server. Her bliver billedet sendt ved hjælp af en post request som sendes til vores server, hvorefter billedet bliver gemt der og fil adressen for det gemmes i vores database således at serveren igen på et senere tidspunkt kan tilgå dette og vise det til brugeren i browseren. 31

32 KISS KISS eller Keep It Simple Stupid er et design princip som bygger på at systemer, herunder hjemmesider fungerer bedst ved at simplificerer det mest muligt uden at man forsimpler funktionaliteten på selve hjemmesiden. Det er derfor vigtigt at man stadig bibeholder de elementer som gør at hjemmesiden har den funktion den har men at man at disse elementer fremstår så simple så muligt, så det ikke forvirrer brugeren. Gestaltlovene Gestaltlovene prøver at give en beskrivelse om hvordan menneskets hjerne opfatter forskellige visuelle elementer, herunder objekter og figurer på hjemmesider. Man bruger derfor gestaltlovene til at skabe brugervenlige brugergrænseflader på hjemmesider ved at organisere forskellige visuelle elementer på hjemmesiden ved hjælp af de 6 grundlæggende gestaltlove: Loven om nærhed Loven om lukkethed Loven om lighed Loven om forbundenhed Loven om forsættelse Loven om figur og baggrund Loven om nærhed Loven om nærhed siger, at visuelle objekter der er placeret nær hinanden hører mere sammen end visuelle objekter der er placeret langt væk, da nærhed er med til at skabe sammenhørighed mellem visuelle objekter. 32

33 Loven om lukkethed Loven om lukkethed siger at visuelle objekter som er indrammet på en eller anden vis, hører mere sammen med end visuelle objekter der er indrammet lidt eller slet ikke. Loven om lighed Loven om lighed siger at visuelle objekter som ligner hinanden det kan være i form af farve, form og lignende, hører mere sammen end visuelle objekter som ligner hinanden mindre. Loven om lighed fungerer bedst i sammenspil med loven om nærhed, da det ellers godt kan blive svært at drage paralleller mellem visuelle objekter hvis afstanden er for stor, og der er derfor risiko for at de stadig vil blive anset som forskellige selv om farverne eller formen er den samme. Loven om forbundethed Loven om forbundethed siger at visuelle objekter som kraftig forbundet hører mere sammen end visuelle objekter der forbundet lidt eller slet ikke. 33

34 Loven om forsættelse Loven om forsættelse siger at visuelle objekter der er arrangeret på linje eller som et symbol hører mere sammen end visuelle objekter der ikke er arrangeret således. Loven om figur og baggrund Loven om figur og baggrund siger at det er vigtigt at gøre brugeren opmærksom på hvad der er baggrund og hvad der er figur. For at gøre dette benytter man de 5 andre gestaltlove. 34

35 Indledende kravfangst USER STORIES Alexander Jeg er en ung mandlig fodboldspiller på 20 år, som går til fodboldtræning tre gange om ugen. Derudover har jeg en stor passion for den engelske Premier League og jeg følger med i alle de kampe, som jeg har mulighed for at se. Jeg snakker oftest med mine venner om fodbold omkring tipsforslag og de forskellige klubber. Jeg vil gerne kunne have en blog via internettet, hvor man kan blive opdateret om de forskellige storklubber rundt om i verden. Jeg benytter dagligt flere forskellige hjemmesider til at få den information om fodbold, som dækker mit behov og det kunne derfor være fedt hvis man fik alle nyheder på én hjemmeside. En ideal løsning kunne være en fodboldblog, hvor skribenterne har en stor lidenskab indenfor det specifikke emne og holder fokus kun på fodbold. Simon Jeg er 24 år og interesserer mig specielt for de mindre fodboldrækker, såsom den engelske Championship og League 1 og ikke mindst den danske NordicBet Liga. Der er desværre ingen af mine venner, som interesserer sig for disse fodboldrækker og jeg synes det er svært, at finde gode fakta og information om det på nettet. Det kunne være fedt, hvis der fandtes en hjemmeside, hvor de fokuserede på disse fodboldrækker og har lyst til at dele deres viden med andre. Jeg vil være utroligt glad for, hvis der var sådan en hjemmeside, som jeg kunne få information fra, da jeg mener, at der er mangel på sådan en mediekilde, der fokuserer på disse områder. Christopher Jeg benytter mig af fodboldblogs hver evig eneste dag for at få inspiration og nyheder fra fodboldverden. Jeg er altid nysgerrig efter, at vide hvad der sker i de forskellige klubber og jeg synes det er interessant, at følge med i de forskellige debatter på nettet, hvor andre fodboldentusiaster kommer med deres holdninger til eksempelvis transfers, managerskift, gårsdagens kampe osv. Jeg finder det interessant, at høre hvad anmelderne har at sige om de forskellige kampe, der er blevet spillet. Jakob Jeg søger en overskuelig fodboldblog, som giver mig de informationer, som jeg har brug for. Lige nu benytter jeg mig af diverse sportssider til at læse om fodbold, men der er desværre også information om mange andre sportsgrene, hvilket jeg ikke har brug for at vide noget om. Hvis der var en søgefunktion på bloggen, så man kunne benytte sig af, til at søge blandt de forskellige fodboldklubber og nyheder, kunne det være med til at øge mit ønske for et bedre overblik. 35

36 Overordnet design Gestaltlovene på vores hjemmeside Navigation Den første del på vores hjemmeside hvor vi har anvendt gestaltlovene er til vores navigation Ved at alle elementer i navigationen er indrammet ved hjælp af en mørk baggrund som adskiller fra sidens ellers generelle hvide baggrund, bliver loven om lukkethed sat i spil. Dette gør at alle elementer i navigationen kommer til at høre mere sammen end de gør med de resterende elementer på siden. Dog bliver loven om lighed anvendt til at gøre brugeren opmærksom på at de forskellige link har forskellige funktioner ved at hvert link adskilt fra de andre ved at de har deres egen farvekode. Dette er især vigtigt da alle sammen linker til forskellige undersider på hjemmesiden. Derudover bliver loven om forsættelse også anvendt i det de alle sammen ligger på en vandret linje, som igen er markeret ved den mørke baggrund. På den måde vil de alle sammen blive opfattet som links, da man automatisk ved brug af det første link vil anslå at de andre også har den samme funktion. 36

37 Blog opslag / artikler Et andet sted hvor vi har brugt gestaltlovene er til style af vores blog opslag / artikler. Her har vi primært valgt at anvende loven om nærhed, i det alle de forskellige elementer som omhandler de enkelte blog opslag / artikler er placeret nær hinanden. Dette gør at man ser på alle elementer som et samlet element som danner rammer for hele opslaget. 37

38 Input felter En anden ting som der er meget gennemgående på hele hjemmesiden er stylingen af input felterne. I eksemplet er der taget udgangspunkt i kontakt siden. Til style af alle input felter som textfelter har vi valgt at gøre brug af loven om lighed i det vi har valgt at give alle input felterne den samme border, både farve samt tykkelse. På den måde får man følelsen af at de har den samme funktion, i dette tilfælde at der skal skrives tekst i dem. Derudover har vi også anvendt loven om forsættelse i det alle elementerne vil blive anset som en lodret linje i det alle input felterne har den samme bredde. 38

39 Sub menu Det sidste sted hvor vi har valgt at anvende gestaltlovene er ved vores undermenu inde på undersiden blog. Her har vi anvendt loven om lighed i det vi har givet alle elementerne denne samme style i form af font og border. På den måde vil de alle sammen blive anset for at have den samme funktion nemlig at søge i artiklerne efter artikler med den valgte kategori. Derudover har vi også anvendt loven om nærhed da vi har valgt at ligge elementerne tæt op ad hinanden. Vi har også brugt denne lov på en anden måde, i det vi har valgt at ligge sub menuen med mindre afstand op til navigationen end ned til artiklerne fordi at sub menuen har en relation i forhold til navigationen da den også er med til at ændre siden indhold. 39

40 VALG AF FARVER Farverne på en blog er et designelement, som er yderst vigtig i og med, at de er med til, at danne et førstehåndsindtryk og et forhold mellem de besøgende og bloggen. Farverne er de visuelle elementer, som kan være et af de største elementer, der er med til at skabe en interesse. Det er vigtigt at skabe en blog, hvor brugeren kan føle sig veltilpas og som tilpasser sig målgruppen. Hvis bloggen er designet i et layout med for mange iøjefaldende og/eller skarpe farver, vil brugeren kunne have svært ved at holde fokus på informationen. Vi har valgt at designe vores layout til bloggen med en hvid baggrund og dertil en gråtonet tekst for at skabe en blog med et godt overblik uden alt for mange farver, som kan distrahere øjets blikfang. Vi har brugt en funktion på bloggen til at fremhæve forskellige farver, som bliver vist, når man holder markøren over knappen. Derudover vil knappen være fremhævet af farven, når man er inde på en bestemt kategori. På denne måde bliver knapperne fremhævet og er med til at give bloggen nogle farverige effekter. Denne effekt er illustreret på figur 1. Figur 1 FARVERNES BETYDNING Blå Vi har valgt at benytte farven blå til noget af teksten på bloggen, da denne farve er beroligende og viser kreativitet, seriøsitet og intelligens. Derudover symboliserer den loyalitet, visdom og tillid og er benyttet af mange store virksomheder. Vi synes at den giver en behagelig ro og er med til at skabe en følelse af orden, hvilket er noget vi ligger stor vægt på med vores fodboldblog. Rød Den røde farve er en bemærkelsesværdig og meget stærk farve, som springer i øjnene på en. Rød bliver oftest brugt til, at signalere advarsel eller forsigtighed og har nemt ved stjæle opmærksomheden fra andre farver og dermed skabe et blikfang. Vi har bl.a. benyttet os af 40

41 farven rød til delete-knappen, hvis man ønsker at slette det man lige har skrevet. Rød er nemlig ofte forbundet med ordet stop eller fortryd og vi mener derfor at farven passer godt her. Grøn Farven grøn er forbundet med en følelsesmæssigt positiv farve og har en stærk følelse af rigtigt og forkert. Den giver samtidig håb og giver den moralske og relevante beslutning. Vi har derfor valgt den grønne farve til knappen, hvis man ønsker at poste et opslag, da den er med til at symbolisere, noget der er rigtigt at gøre. 41

42 Beskrivelse af udviklingen af server funktionaliteten Inden vi begyndte på itterationerne af vores systemudvikling havde vi kun vores front end delen af vores produkt, således at siden var helt statisk. For at få siden til at fungere dynamisk har vi lavet en række system udviklings iterationer. Planlægning af iterationen Måden vi har besluttet hvilke iterationer vi skulle lave først gav meget sig selv, da nogle ting er nødvendige for at andre ting på siden kan virke. Grundet dette er den første iteration vi har tænkt os at lave muligheden for brugere at registrere sig på siden. Herefter går vi videre til den næste itteration som er log ind funktionalite. Når disse itterationer er lavet og testet går vi videre til de funktionaliteter som folk skal have når de er logget ind. Den første af disse itterationer er muligheden for de enkelte brugere at ændre i deres bruger oplysninger. Herefter itterere vi yderligere således at brugeren kan lave opslag på siden, og når dette så er lavet også kan ændre i disse opslag. Register Krav: Det skal være muligt for brugeren at oprette en bruger med username, password, , fornavn og efternavn. Brugeren kan automatisk blive logget ind med username vedkommende har oprettet. Kryptere password således at det ikke kan tilgås lige så nemt. Test specifikation: Prøve at oprette en bruger, se om den bliver gemt korrekt i Databasen, samt se at man bliver logget ind på siden. Tjekke i databasen at passwordet er blevet krypteret. Design Måden dette skal gøres på er ved at sende de informationer som brugeren indtaster i en form til en anden side der kan behandle disse, dette skal gøres ved hjælp af post. Herefter skal passwordet krypteres, dette har vi valgt at gøre ved hjælp af MD5 kryptering. Herefter skal der laves to variabler som der skal postes sammen med de indtastede værdier fra brugeren. Disse er status og creation_time. Når disse er lavet skal alt dataen skrives til databasen og brugeren skal sendes til logged_in.php siden. 42

43 Implementering Måden vi implementere dette er ved først at ændre i vores form element således at method attributten er sat til post og action er sat til register_user.php. Dette løser den først del af designet, nemlig at sende den data brugeren indtaster til vores bearbejdningsside. Krypteringen af kode ordet sker ved hjælp af den meget simple linje kode der kan ses nedenfor. Som det kan ses her benytter vi os af den indbyggede funktion i PHP der hedder hash(). Denne funktion acceptere to parametre, det første af disse er hvilken type kryptering vi gerne vil benytte os af, vi har som tidligere nævnt valgt at benytte md5. Det andet parameter er det vi gerne vil have krypteret, her indtaster vi passwordet. Det næste skridt i registreringen er at lave to variable status og creation_time. Her vælger vi at give status en værdi af 3, da det er den laveste af de mulige statusser, og derfor også den hvor man kan mindst. Denne status kan blive ændret på et senere tidspunkt hvis brugeren skal kunne noget mere. Den anden variable creation_time sætter vi lig time() funktionen der er indbygget i PHP, denne funktion angiver hvad klokken og datoen er lige nu. Dette er ved hjælp af denne funktion angivet i sekunder siden Unix Epoch (den 1. januar 1970 klokken 00:00:00 GMT). Herefter skal vi have alle disse værdier ind i vores database, måden vi gør dette er ved at gøre brug af PDO (PHP Data Object). Ved hjælp af dette opretter vi en forbindelse til vores database, herefter forbereder vi ved hjælp af prepare() metoden vores MySQL statement. Når vi nu har forberedt vores MySQL query kan vi udføre denne ved hjælp af execute() metoden. Execute() modtager de værdier vi gerne vil have sat ind i vores query some vi havde forberet ved hjælp af prepare(), og den sender så hele MySQL statementet med værdier til vores database. Alt dette gøres inde i et try/catch statement, således at vi kan fange enhver fejl der kunne ske ved at prøve at indsætte dette i vores database. Hvis det lykkedes at sætte det ind i databasen og vores try/catch ikke fanger nogle fejl, logger vi brugeren ind. Dette gøres ved at oprette en session og sætte 4 variabler i denne. Disse værider kan ses til venstre. Som det også kan ses på billedet sender vi, efter at have logget brugeren ind, vedkommende videre til logged_in.php siden. 43

44 Test Vi tester at dette virker ved at udføre vores test specifikationer. Som det står i vores test specifikationer starter vi med at prøve at oprette en bruger ved at udfylde vores register form, og så indsende denne. Af hvad man kan se fra browseren er brugeren blevet registret korrekt, og man kan også se at vi ender på logged_in.php, hvilket altså betyder at vi er blevet logget ind. For at tjekke om brugeren også er blevet oprettet som forventet i databasen, åbner vi PHPMyAdmin. Her kan vi se at vores bruger ganske rigtigt ligger i tabellen users, og vi kan samtidigt også se at vores kodeord ganske som forventet er blevet krypteret. Log in Krav: Det skal være muligt for brugeren at logge ind. Det skal gemmes i en session at brugeren er logget ind således at de bliver ved med at være det når man skifter mellem sider. Test specifikation: Prøve at logge ind med det rigtige kodeord og brugernavn, samt at prøve med forkerte kombinationer. Prøve at skifte mellem forskellige sider og se om vi stadig er logget ind. Design: For at opnå vores krav til log in delen af vores system udvikling, har vi brug for først og fremmest at sende den information brugeren indtaster i vores log in felter. Dette skal ligesom med registreringen sendes med post. Når vores bearbejdnings side så modtager dataen skal kodeordet først krypteres. Herefter skal vi have fat i information fra databasen således at vi kan verificere informationen fra brugeren. Efter at informationen er blevet verificeret skal vi have sat en session, der gør at brugeren ses som at være logget ind. Når dette er gjort skal brugeren sendes over til logged_in.php. Implementering: For at implementere vores design, starter vi med at ændre i vores login form, således at form tagget får en method attribut der er sat til post samt en action attribut der er sat til login.php. Dette gør at det username og password som brugeren indtaster bliver overført til vores bearbejdnings side som i dette tilfælde er login.php. Her skal vi som beskrevet i design afsnittet først have krypteret vores password, således at vi kan tjekke det imod det krypterede password fra databasen. Dette gøres på samme måde som i registreringsdelen, ved hjælp af hash() funktionen. 44

45 Når passwordet nu er blevet krypteret skal vi have fat i brugerne fra vores database således at vi kan tjekke om de indtastede informationer passer til disse. Dette gøres som hele vejen igennem projektet ved hjælp af PDO. Forbindelse oprettes ved at lave et nyt PDO objekt, som holder forbindelse til databasen. Vi benytter så dette objekt ved hjælp af prepare() og execute() metoderne som ses nedenfor. Som det kan ses på dette udsnit af koden henter vi alle brugere fra vores database, grunden til at vi gør dette er at vi har valgt først at sortere i vores brugere i forhold til log in oplysningerne i selve PHP dokumentet, i stedet for at gøre det allerede i MySQL queriet. Når vi nu har alle brugerne fra databasen, benytter vi et foreach-loop til at løbe igennem alle disse brugere og teste om en af dem matcher det som vores bruger har indtastet i log in formen. Det if statement som vi bruger til at tjekke de oplysninger som brugeren har indtastet imod oplysningerne fra databasen ser ud som vist nedenfor. I dette if statement benytter vi os af funktionen strtolower() det som denne funktion gør at den tager en string og gør alle bogstaver i den små. Grunden til at vi bruger denne funktion er, at vi ikke har lyst til at gå op i om brugeren bruger store eller små bogstaver i sin kode og sit brugernavn, da vi fra et useabillity standpunkt mener at det er meget mere brugervenligt ikke at skulle tænke over store og små bogstaver i sin kode. Det if statementet så egentlig tjekker er om der er en række i vores users tabel hvor username passer til det vores bruger har indtastet samtidigt med at passwordet gør det. Hvis den finder en række hvor både username og password passer, så skal brugeren logges ind og derefter sendes videre til logged_in.php. Dette gøres ved hjælp af de samme fem linjer kode som i registrerings delen. Det der sker her er som tidligere beskrevet at der sættes fire SESSION variabler og derefter kaldes header() funktionen, hvor vi indtaster location: logged_in.php. Dette gør at brugeren ganske som ønsket sendes til logged_in.php. Hvis vores if statement derimod ikke finder nogen rækker hvor både username og password passer, skal brugeren sendes tilbage til login_page.php, og selvfølgelig heller ikke logges ind. 45

46 Test: For at teste at vores produkt virker som det skal gør vi som beskrevet i test specifikationerne. Her prøver vi at logge ind, først med en username og password kombination som vi ved passer til en bruger som vi har i databasen. Her kan vi som forventet se at vi bliver sendt videre til logged_in.php. For at teste den anden test specifikation, prøver vi at gå tilbage til index.php og ser her om vi stadig er logget ind. Vi kan her se at vi ganske som forventet stadig er logget ind. Dette betyder at vores SESSION virker som forventet. Når vi nu har tjekket at login funktionen virker som forventet når man indtaster et rigtigt password og username. Derfor prøver vi nu at indtaste et forkert username, samt password. Vi kan her også ganske som forventet se at vi ikke bliver logget ind, men i stedet bliver sendt tilbage til login_page.php. Edit user Krav: Det skal være muligt for brugeren at ændre sine egne oplysninger, når han/hun er logget ind. Test specifikation: Prøve at ændre i brugerens oplysninger og gemme disse, derefter tjekke at de er blevet gemt i databasen som forventet. Design: Måden vi har tænkt os at lave denne del af siden så den opfylder kravet som vi har sat til den, er ved først at hente de oplysninger som der allerede ligger om brugeren, disse skal så skrives ud til brugeren. Herefter skal vi have den information som brugeren har indtastet over til bearbejdningssiden. Dette skal gøres på samme måde som altid ved hjælp af post. Herefter skal vi have krypteret kodeordet, og derefer sat denne information ind i databasen i stedet for det der allerede står. Hvis dette lykkedes korrekt skal brugeren sendes tilbage til logged_in.php. Dette kan ses mere grafisk på blogdiagrammet nedenfor. 46

47 Implementering: Måden vi implementerede dette design i vores kode var ved først at lave en forbindelse til databasen ved hjælp af vores PDO objekt, via denne forbindelse henter vi så den information som der ligger om brugeren i databasen. Måden dette gøres er ved at tage det id der ligger gemt i brugerens SESSION og så finde den bruger i databasen der har dette id. Dette gøres ved hjælp af koden der kan ses herunder. Som det kan ses på billedet vælger vi alle de rækker fra users tabellen, hvor id er lig $_SESSION[ id ]. Herefter sættes de værdier der returneres fra dette query ind i det form element som der skal udfyldes af brugeren, denne form har ligesom alle de andre forms fået en method attribut sat til post, samt en action attribut sat til edit_user.php. Når informationen nu er blevet sendt over til vores bearbejdningsside skal vi have først have krypteret passwordet, dette gøres på samme måde her, som det er blevet gjort alle de andre steder hvor vores bruger indtaster sit password. Når dette nu er krypteret skal alle værdierne sættes indsættes in databasen, i stedet for de værdier der står der på nuværende tidspunkt. Dette gøres ved hjælp af et Update statement i vores MySQL kode. Dette ser ud som vist på billedet nedenfor. Her kan det ses at vi se at alle de ting som brugere har indtastet på siden bliver opdateret i vores database ved hjælp af disse linjer kode. Efter disse linjer er der selvfølgelig et execute() call som gør at updaten faktisk finder sted. Når databasen nu er blevet opdateret, skal brugeren bare sendes videre. Dette gøres som altid ved hjælp af header() funktionen. 47

48 Test: For at tjekke at denne del af vores hjemmeside virker som vi gerne vil have den til, logger vi ind med en af de brugere som vi har oprettet på siden. Herefter prøver vi at ændre i denne brugers oplysninger, denne ændring går igennem som forventet. Og ifølge det vi ser i browseren burde oplysningerne nu være ændret. For at tjekke at dette også er tilfældet, går vi ind i vores database og ser at oplysningerne er ændret ganske som vi havde forventet. Create post Krav: Brugeren skal når han/hun er logget ind kunne oprette opslag på siden hvis de har en status på 1 eller 2. Test specifikation: Prøve at logge ind som en bruger der har en status på enten 1 eller 2, og derefter prøve at oprette et nyt opslag. Design: For at opfylde kravet om at man skal kunne oprette opslag på vores hjemmeside, hvis man status 1 eller 2, skal vi som altid have en form der er sat til at bruge post. Derefter skal vores bearbejdningsside så sende disse informationer til vores database, og herefter sende brugeren tilbage til logged_in.php. Dette er også beskrevet på blokdiagrammet som kan ses nedenfor. Implementering: For at implementere dette design, skal vi som ved alle de andre itterationer hvor vi benytter os at informationer fra brugeren, have indstillet form elementet til at bruge post og sende informationen til en specifik side. Når denne data så er nået frem til vores bearbejdningsside skal vi have fat i det højeste id der er på posts på nuværende tidspunkt. Da vi skal bruge det id der ligger et højere end dette til at gemme det billede der er uploadet med postet, da dette skal uploades med nummeret på det id som postet har fået. Måden vi gør dette er ved at hente de posts der er i databasen, og så sortere dem således at det med højest id ligger først. Herefter bruger vi et foreach-loop, til at få dette id. Det id vi her så har fået fat i addere vi med 1 således at vi får det id der ligger et nummer højere. Dette tal gemmes billedet så under, og idet gemmes sammen med de andre variabler, som der skal indsættes i databasen. 48

49 Disse variabler skal så bare indsættes i vores database, dette gøres på sammen måde som det skete når man oprettede en ny bruger, ved hjælp af et INSERT statement i vores MySQL. Vi vil her ikke gå længere i dybden med dette da det er gjort på helt samme måde som i registreringen af en ny bruger. Denne gang indsættes værdierne bare i posts tabellen i stedet for users tabellen. Dog skal vi her ikke logge brugeren ind, derfor sætter vi ikke nogen session. I stedet skal vi også have uploadet den fil som der er blevet sendt ved hjælp af post til vores server. Denne server uploades ved hjælp af funktionen move_uploaded_file(). I denne funktion indsætter vi det midlertidige navn på vores billede, dette navn er blevet sat automatisk da billedet blev uploadet. Den anden parameter er hvor billedet skal flyttes hen, dette har vi indstillet tidligere da vi fandt frem til det id som vores nye post skulle have. Når dette billede er blevet uploadet sender vi brugeren tilbage til logged_in.php, ved hjælp af vores header() funktion som tidligere beskrevet. Test: For at udføre vores test specifikation logger vi ind på siden med en bruger der har status 1. Når vi nu er logget ind som denne bruger, går vi ind og udfylder den form der er til at lave et nyt opslag. Når vi nu har udfyldt denne form, indsendes den. Vi kan i browseren ikke se nogle fejl, hvilket tyder på at der ikke har været nogle fejl under oprettelsen af dette post. For at være helt sikre på at dette post er blevet oprettet som vi gerne vil have det til, går vi ind i databasen og tjekker at alle værdier ligger gemt ligesom vi forventer at de gør. Det kan vi se at de gør, udover at tjekke databasen tager vi også den filstig der ligger gemt i databasen, og tjekker at billedet rent faktisk ligger på den plads som denne stig har specificeret. Det kan vi se er tilfældet her, hvilket betyder at denne del af vores backend system har klaret den test som vi havde specificeret for at tjekke om det virkede som det skulle. Edit post Krav: Brugeren skal når de er logget ind som status 2 kunne ændre samt slette sine egne posts. Hvis brugeren er logget ind som status 1 skal han/hun kunne ændre i alle opslag på siden samt slette alle opslag. Test specifikation: Logge ind som en bruger med status 2, og så prøve at ændre i et post, som er lavet af denne bruger, samt prøve at slette et opslag der også er lavet af denne bruger. Logge ind som en bruger med status 1, og så prøve at ændre i både opslag lavet af brugeren selv samt opslag lavet af andre, samt prøve at slette et opslag der er lavet af enhver bruger. 49

50 Design: Da der på denne side skal være forskel på om man loader den som en bruger med status 1 eller status 2, skal vi starte ud med at tjekke hvilken en af disse to statusser brugeren der prøver at loade siden har.herefter efter skal vi hvis brugeren har status 1 hente alle posts. Hvis brugeren derimod har status 2 skal vi kun hente de posts som der er skrevet af denne specifikke bruger. Herefter skal vi give brugeren adgang til at ændre i det post som vedkommende gerne vil ændre i. Måden vi har tænkt os at gøre det muligt for brugeren er ved at ændre i disse er at hver af opslag der bliver listet op som brugeren har adgang til at ændre i skal linke til en ny side hvor alle oplysningerne for dette opslag står, med mulighed for at ændre i disse, på denne side skal der være to muligheder enten at slette opslaget eller at ændre i det. Fra denne side skal de informationer som brugeren indtaster sendes videre til en bearbejdningsside, denne bearbejdningsside skal så afgøre om brugeren har trykket slet opslaget eller opdater. Hvis der er valgt at slette opslaget, skal siden gå ind i databasen og slette dette opslag. Ellers skal denne side ændre databasen til at passe til der som brugeren nu har ændret i opslaget. Herefter skal brugeren sendes tilbage til den side hvor på han/hun kan vælge mellem opslag som vedkommende gerne vil ændre eller slette. Denne måde hvor på brugeren bliver sendt rundt mellem de forskellige sider kan ses på blokdiagrammet nedenfor. Implementering: For at implementere denne design løsning starter vi med at lave to if statements disse skal stå for at afgøre om brugeren har status 1 eller 2. Måden dette gøres på er ved at det første if statement tjekker om status er lig 1. Hvis den er dette skal samtlige opslag fra posts databasen hentes. Dette gøres ved at vi som altid opretter en forbindelse til databasen ved hjælp af PDO. Herefter benytter vi prepare() metoden til at klargøre et MySQL statement til vores database. I dette tilfælde ser dette MySQL statement således ud: 'SELECT * FROM posts ORDER BY posttime DESC'. Udover bare at hente alle posts fra databasen arrangere dette statement dem også efter hvornår de er blevet postet, således at de nyeste er øverst, og de laveste er nederst. Det næste if statment efter dette tjekker om brugerens status er lig 2. Hvis den er dette hentes alle opslag fra databasen som er lavet af denne bruger. MySQL statementet for dette er næsten 50

51 magen til det andet. Udover at der her bare kun hentes de opslag hvor feltet authorid i databasen er lig det id der er gemt i brugerens SESSION. Når vi nu har alle de opslag som brugeren har rettigheder til at ændre i skriver vi disse ud på siden. Måden brugeren kommer videre her fra er ved at hvert af disse opslag har et link til edit_post.php, efterfulgt af en $_GET variable der indeholder idet på det post som linket hører til. Når brugeren kliker på et af disse opslag kommer vedkommende over til edit_post.php, her tjekkes hvilket id der er blevet sat i $_GET variablen. PHP dokumentet opretter så en forbindelse til databasen ved hjælp af PDO og henter det opslag der har dette id. Måden dette hentes er som altid ved hjælp af prepare() og execute(). Det MySQL statement der bruges til at hente dette opslag ser således ud: "SELECT * FROM posts WHERE id = :id". Den variable som står som :id her er egentlig det id der er gemt i $_GET[ id ] fra før. Når dette er blevet hentet bruges der et foreach-loop til at gemme værdierne fra databasen i variabler således at vi kan skrive dem ud til brugeren, og han får afgang til at ændre i dem. Disse værdier bliver skrevet ud til brugeren i en form. Denne form har som altid en method attribut der er sat til post, samtidigt har den en action attribut der er sat til submit_edit_post.php da det er denne side vi har tænkt os at benytte til at behandle det som brugeren indtaster. Denne form har to submit knapper, denne af disse er til at slette det pågældende opslag, og den andet er til at opdatere opslaget. Når brugeren så indsender denne form kommer dataen som før nævnt til submit_edit_post.php, det der sker på denne side er at der først er noget sikkerhed der tjekker at det faktisk er en bruger der har rettigheder til at ændre i lige præcis dette opslag der er gået ind på siden. Måden dette gøres på er ved først at hente det pågældende opslag fra databasen, dette gøres på samme måde som tidligere beskrevet, herefter bruger vi et if statement som kan ses herunder til at afgøre om brugeren har ret til at ændre i dette opslag. Først tjekkes der er om $userid(id fra brugerns SESSION) ikke er lig $authorid(forfatter id fra databasen). Hvis det er tilfældet at disse er ikke lige hinanden tjekkes det om brugerns status er ikke er lig 1. Hvis dette if statement også er sandt betyder det at vi har at gøre med en bruger der ikke burde have adgang til dette post og vi sender derfor denne bruger tilbage til logged_in.php med beskeden access=denied. 51

52 Når vi nu er sikre på at det er en bruger der har ret til at ændre i opslaget, bruger vi et if statement til at finde ud af om brugeren har besluttet at slette opslaget eller bare ændre i det. Hvis det første if statement som tjekker om brugeren har trykket på delete knappen, hvis dette er tilfældet køres det kode som kan ses nedenfor. Som det kan ses her slettes opslaget først i databasen, dette gøres ved hjælp af MySQL statementet: DELETE FROM. Herefter specificeres det er der skal slettes der hvor id er lig vores opslags id ($postid). Når dette MySQL er kørt igennem, bruges den indbyggede PHP funktion unlink() til at slette den fil der har været relateret til dette post, således at der ikke ligger en fil bare at flyder rundt på vores server uden at have noget opslag relateret til den.til sidst sendes brugeren tilbage til edit_posts.php ved hjælp af header() funktionen. Hvis dette if statement ikke viser at der er trykker på delete, går koden videre til næste if statement hvilket tjekker om der er trykket på opdater knappen. Hvis dette er tilfældet opdateres databasen og filen til at passe til det som brugeren nu har uploadet. Vi vil ikke gå dybere ind i hvordan dette gøres da det gøres på samme måde som opdateringen af user informationen sker. Test: For at teste om denne del af systemet virker prøver vi som beskrevet i test specifikationerne først at logge ind som en bruger med status 2. Her prøver vi først at ændre på et at de opslag, som er lavet af denne bruger. I browseren kan vi ikke se nogle tegn på at der er problemer, hvilket vi også kan se er tilfældet når vi tjekker om ændringerne er gået igennem til vores database. Når vi nu har testet at vi kan ændre i et opslag, prøver vi på samme måde at gå ind og slette et opslag, ved at trykke på delete knappen i stedet for opdater. Endnu engang kan vi se at opslaget forsvinder fra listen over opslag som vi kan ændre på, og når vi tjekker databasen er dette opslag også væk. For at være sikker på at filen også er blevet slettet tjekker vi der hvor filen lå før, om den stadig ligger der eller ej. Det gør den ikke, hvilket betyder at den er blevet slettet som forventet. Nu går vi videre til testen for brugeren med status 1. Vi prøver her at ændre på et opslag der er lavet af en anden end brugeren selv, her kan vi se at opslaget bliver ændret ganske som forventet. Dette kan både ses i browseren samt i databasen. Herefter prøver vi at slette det samme opslag 52