:w\subsection{Server-opzet}
Het was van belang om ontwikkeling aan dit project met een goede basis te starten. Dit begon bij het nadenken over de manier waarop de bestanden van de website in mapjes geordend zouden worden en hoe deze vervolgens vanaf de server aan de gebruiker gepresenteerd dienden te worden. Allereerst moest de \texttt{.git}-map --- welke in de \textit{root} van het project zat wegens het gebruik van \textit{git} om bestanden op de server te laden --- voor bezoekers van buiten verborgen worden. Er waren twee manier waarop dit gedaan kon worden: de map kon met behulp van een \texttt{.htaccess}-bestand worden afgeschermd of het hosten van de website werd niet gedaan vanuit de \textit{root} van het project, maar vanuit een hoger-gelegen map. Voor dit tweede werd gekozen omdat dit zowel makkelijker te implementeren was als een robuustere oplossing leek. Het hosten van de \textit{web root} werd dus gedaan vanuit de map \texttt{www/}. Onderdelen als \textit{CSS}-, \textit{JavaScript}-bestanden en plaatjes werden respectievelijk in de mappen \texttt{static/css/}, \texttt{static/js/} en \texttt{statis/images/} gezet. Om deze mappen voor externe bezoekers bereikbaar te maken werd de map \texttt{static/} binnen de \textit{virtual host} van de \textit{Apache}-configuratie als een alias gehost op \texttt{[domein]/static}. De achterliggende \textit{PHP}-bestanden die niet vanuit \textit{AJAX} aangeroepen dienden te worden en dus ook niet vanaf het web beschikbaar moesten zijn werden in de map \texttt{php/} gezet. Als laatste werden de menubalk en \textit{footer} van de pagina's, als zijnde veelvoorkomende elementen, in de map \texttt{elements/} gezet.

\subsection{Dubbele code}
Waarom er voor de zojuist genoemde pagina-onderdelen een aparte map was heeft naast de roep om orde alles te maken met het voorkomen van herhaling in de code. Zoals misschien wel te begrijpen is, heb je bij een website bestaande uit meerdere pagina's op ieder van deze pagina's bijvoorbeeld een kopie van het menu nodig. Nou kun je in ieder \textit{PHP}- of \textit{HTML}-bestand datzelfde menu kopiëren, maar dit zou herhaling en problemen bij het willen maken van aanpassingen opleveren. Daarom is gekozen om de zich in het \texttt{elements}-mapje bevindende elementen met behulp van \textit{PHP} in te voegen. Ook achter de schermen is zowel bij vaak gebruikte stukken \textit{PHP}- als \textit{JavaScript}-code geprobeerd deze in 'e'en enkel bestand te zetten, zodat deze vervolgens in andere bestanden kan worden gevoegd. In het geval van \textit{JavaScript} was dit een ietwat minder elegant proces, omdat er binnen deze taal geen universeel ondersteunde manier is om bestanden in andere bestanden op te nemen. De wijze waarop dit is opgelost is door het benodigde bestand in het \textit{HTML}-document te laden voorafgaand het bestand met de code die het vereistte.

\subsection{Beveiliging}
Het is voor iedere website van belang om tegen kwaadwillende gebruikers beschermd te zijn. Hierbij zijn, in het geval van een dynamische website als deze, \textit{SQL}-injecties en \textit{Cross Site Scripting} twee van de de meest kwaadaardige. Tegen de eerste was bescherming vrij eenvoudig; door gebruik te maken van de \textit{PDO}-functies \texttt{prepare()} en \texttt{execute()}. De eerste de \textit{query} defini"erend met enkel de plaatsing van de variabelen, de tweede deze geposintioneerde variabelen een waarde toekennend.\\
Tegen \textit{Cross Site Scripting}, ookwel het injecteren van \textit{HTML}-code, werd beschermd door alle gebruikersinvoer die in de database diende te worden opgeslagen eerst door de \textit{PHP}-functie \texttt{htmlspecialchars()} te halen. In de eerste plaats van gekozen om dit met de functie \texttt{htmlentities()} te doen, maar dit bleek problematisch bij de implementatie van MarkDown --- welke verderop behandeld zal worden.

\subsection{Tokens en e-mail}
Een andere manier van beveiligen, in dit geval van gebruikers tegen andere gebruikers met wat dubieuzere motieven, kwam tot stand met het per e-mail versturen van \textit{tokens}. Dit vindt allereerst plaats bij het registreren. Nadat een gebruiker zijn gegevens heeft ingevuld, wordt er een e-mail naar het door hem of haar opgegeven adres gestuurd met daarin een \textit{token}-bevattende activatie link. Na het drukken op deze link wordt achter de schermen het account van de gebruiker geactiveerd en kan deze beginnen met het gebruik van de website. Dit gebeurt om zowel het bezit van het e-mailadres vast te stellen als om te voorkomen dat gebruikers herhaaldelijk accounts kunnen aanmaken. Soortgelijk is het mechanisme bij het opvragen van een wachtwoordsverandering en bij het verander van het e-mailadres. Bij die eerste is gekozen voor per e-mail verstuurde tokens omdat de enige betrouwbare manier is om de identiteit van een gebruiker te verifi"eren, bij de tweede logischerwijs omdat ook van dit nieuwe e-mailadres vastgesteld moet worden dat de gebruiker hier de eigenaar van is. [database en implementatie]

\subsection{Captcha's}
Onze opdrachtgever vond het van belang dat gebruikers bepaalde aspecten, namelijk het registreren,  het \textit{resetten} van wachtwoorden en het plaatsen van een bericht, niet door gebruikers ge"exploiteerd kunnen worden door er binnen te korte tijd herhaaldelijk gebruik van te maken. Om deze \textit{spam} te voorkomen is gebruik gemaakt van de \textit{reCAPTCHA} van Google. Deze \textit{CAPTCHA} is toegevoegd aan de betreffende formulieren en moet door de gebruiker opgelost worden voordat het formulier succesvol verwerkt zal worden door de server. De opdracht van de \texttt{CAPTCHA} wordt bij herhaaldelijk gebruik steeds ingewikkelder en maak het gebruik van automatische scriptjes onmogelijk. Een belangrijke reden voor het gebruik van de \textit{CATPCHA} is tevens dat bij het wachtwoordreset een e-mail naar de gebruiker wordt gestuurd en er bij herhaaldelijke aanvraag ook een grote hoeveelheid e-mails gestuurd kunnen worden. Dit is met deze toevoeging dus niet meer mogelijk.

\subsection{Gravatar}


\subsection{MarkDown}

\subsection{Tekst op de home-pagina}
