Zoals ik afgelopen maandag al schreef ben ik begonnen met een opleiding tot webontwikkelaar. Programmeren heeft me al tijd al getrokken en het einde van mijn vorige baan leek me een mooie gelegenheid om te kijken of ik me niet alsnog in die richting kon specialiseren. Ik heb uiteindelijk voor web development gekozen omdat de talen die daarvoor nodig zijn het minst abstract zijn. Een van de redenen dat ik na de middelbare school niet voor informatica/ict koos, was dat ik van wiskunde weinig kaas gegeten had.

Nu dus alsnog

Vorige maand ben ik met mijn opleiding gestart. Ter voorbereiding had ik al het nodige gegaan. Ik las Lezen, weten en niet vergeten van Mark Tigchelaar, volgde de MOOC Learning how to learn en ging aan de slag met het boek waarop die cursus is gebaseerd, A mind for numbers van Barbara Oakley. Het leek me nuttig om mijn kennis over leren te actualiseren omdat het toch al weer even geleden is dat ik nog studeerde.

Een van de dingen die ik opstak was dat dagelijks er bezig zijn het leren bevordert. Dat gaat me gelukkig met al mijn training met het wandelen aan de hand van deze serie van Peter over het boek Zen Habits – Mastering the Art of Change van Leo Babauta uitstekend af. Dagelijks ermee bezig zijn, versterkt het geheugen, losse onderdelen smelten samen waardoor je ze gemakkelijker onthoudt en je krijgt routine.

Wat me naar aanleiding van de boeken en de MOOC ook van belang leek, was om te oefenen en daarbij meerdere bronnen te gebruiken. De een legt het toch iets anders uit dan de ander uit en bovendien zorgen ze voor divers oefenmateriaal. Jezelf testen is een van de beste manieren om te toetsen of je iets begrijpt.

Oefenstof

Al met al heb ik afgelopen maanden al behoorlijk wat geoefend met HTML/CSS, JavaScript/jQuery, PHP/MySQL en Bootstrap. Het lijkt me daarom nu mijn opleiding echt begonnen is tijd voor de volgende stap: een wekelijkse web devopment uitdaging waarmee ik wat ik leer kan toepassen. Ik ga proberen om de opdracht steeds net iets moeilijker te maken dan ik al heb geleerd omdat dat ik dan de hard start, jump to easy techniek kan toepassen. Maar daarover waarschijnlijk meer in een van mijn afleveringen en mijn nieuwe serie Van lezen naar doen, waarvan maandag het eerste deel verschijnt.

Wat is het idee?

Het is mijn bedoeling om (mijzelf)* voortaan iedere vrijdag (voor de eerste aflevering heb ik vanwege onverwacht bezoek een dag gesmokkeld) een web devopment uitdaging te geven. De week daarna presenteer ik dan de oplossing en de uitleg daarbij plus een nieuwe opdracht. Op die manier hoop ik een leuke manier wat ik leer nog eens extra toe te passen en met een beetje geluk bouw ik dan ook een aardig portfolio op.

Uitdaging 1

• Bouw een website om alle web development uitdagingen op te presenteren.

*Uiteraard mag je meedoen en jouw oplossing van de uitdaging hier of volgende volgende week als reactie achterlaten.

@foto VIA PIXABAY met CC0 verklarinG

De uitdaging die ik mijzelf stelde in de eerste aflevering van deze nieuwe serie over de vorderingen die ik maak tijdens mijn opleiding tot webontwikkelaar was om een website te bouwen. De serie heet Web development uitdagingen en toen bleek dat het bijbehorende domein nog vrij was, heb ik dat maar snel geregistreerd.

Het resultaat van uitdaging 1 is dan ook te bewonderen op dat nieuwe domein. Dat geeft mij de vrijheid om te oefenen zonder dat ik mijn blog in de weg zit. Neem vooral even een kijkje, ik loop niet weg.

De uitdaging die ik mij hier stelde viel uiteen in een tweetal deeluitdagingen:

1. Ontwerp een pagina die responsive is. Of te wel een pagina die er op elk formaat scherm goed uitziet. Natuurlijk had ik het mezelf makkelijk kunnen maken door uit te gaan van een kant-en-klaar Bootstrap ontwerp maar daarmee zou de uitdaging een stuk minder interessant zijn. Het was er mij juist om te doen om een zelf van de grond af een responsive website te bouwen en zo toe te passen wat ik tijdens mijn opleiding heb geleerd.Gelukkig blijkt responsive design niet heel ingewikkeld. Het geheim zit hem vooral in de grid en de media queries. Het eerste is een matrix waarmee je een scherm onderverdeelt in vlakken. Bij grid systems als Bootstrap zijn dat er meestal 12. Een pagina is dan opgebouwd uit rijen met daarin kolommen. De som van het totale aantal kolommen in een volledige rij bedraagt altijd 12. Ik heb in mijn ontwerp gekozen voor een item van drie kolommen (het menu), een van zes voor de hoofdtekst  waar nu nog een dummytekst staat en waar drie kolommen voor Done/To do.

   Bekijk je de pagina echter met een smartphone dan zijn de elementen gestapeld, of stacked, zoals dat in het Engels heet. Dat doe je door media queries op te nemen in je stylesheet. Een media query ziet er bijvoorbeeld zo uit:

   @media screen and (max-width: 767px){
   	[class*="col-"] {
       width: 100%;
   }
   

   Deze regel zorgt ervoor dat op schermen die maximaal 767 pixels breed zijn (smartphones) alle elementen de klasse “col-” in de naam 100% breed zijn en dus gestapeld worden.

   In de stylesheet en de html pagina heb ik ook van jQuery gebruikt om de pagina schaalbaar te maken,  het menu te verbergen bij kleine schermen om de breedte van het middengedeelte breder te maken als er een geen menu in beeld is. In code ziet dat er als volgt uit:

   <script>
   	$(document).ready(function() {
   		$("#menubutton").click(function() {
   			$("#menubutton").hide();
   			$("#menu").show();
   			$("#content").toggleClass("col-md-9");
   		});
   	});
   </script>

2. Het tweede deel van de uitdaging lag in het grafisch ontwerp van de de site. Zelf heb ik weinig kleurgevoel maar gelukkig is daar Paletton (voorheen Color Scheme Designer). Kleurenlay-outs met 2, 3,  of 4 kleurgroepen of juist varianten van één bepaalde tint, het kan allemaal met een paar klikken. Zelf koos ik via de kleurencirkel voor een ontwerp met 1 hoofdkleur en 2 secundaire kleuren die ik keurig geëxporteerd kreeg naar CSS waarden. Maar het bleek nog een aardige klus om en ander te verwerken in mijn eigen pagina-ontwerp. Eerst had ik ook nog een lichtgroene zijbalk, maar dat vond ik minder mooi. Wat er staat, bevalt me zolang het duurt. Het aanpassen van het kleurenschema hoeft echter – dat heb ik nu wel geleerd – geen heel ingewikkelde zaak te zijn en omdat ik daarbij niet op mijn eigen gevoel voor kleurencombinaties hoef te vertrouwen, heb ik goede hoop dat het resultaat blijft ogen.

Web development uitdaging 2

Tot zover mijn uitwerking van de uitdaging van anderhalve week geleden.  Nu staat er nog dummycontent op de site en werken de links nog niet. Voordat ik aan mijn opleiding begon heb ik ook wat gewinkeld bij Udemy. De uitdaging voor volgende week is om de opdrachten die ik daarvoor gemaakt heb nog eens door te nemen en te verwerken in mijn nieuwe site.

PS: bij nader inzien leek het mij handiger om de verschijningsdagen van Van lezen naar doen en Web development uitdagingen om te draaien. De tweede aflevering van Van lezen naar doen verschijnt dan ook komende vrijdag en de web development uitdagingen blijven op de maandag.

Na het stellen van mijn opdracht in de vorige aflevering van deze serie had ik ook de opdracht die ik daarna wilde uitvoeren al snel in gedachten. Ik heb nu besloten beide opdrachten om te draaien. Ik was van plan om eerst de site van inhoud te voorzien en daarna te zorgen voor een goede paginastructuur.

Bij nader inzien lijkt me dat een onlogische volgorde. Het toevoegen van pagina’s gaat namelijk een stuk efficiënter als je eerst zorgt voor een goede paginastructuur. Op die manier hoef je per pagina zo weinig mogelijk te wijzigen.

Een stukje geschiedenis

Een webpagina bestaat voor een groot deel uit onderdelen die voor elke pagina hetzelfde zijn. Denk een een header, een menu en een footer. Alleen het gedeelte met de inhoud van een pagina is steeds verschillend. Voordat dynamische websites opkwamen kon je in HTML dergelijke onderdelen in je site zetten met frames en een frameset. Belangrijk nadeel van deze techniek is dat leessoftware voor blinden een slechtzienden er niet mee overweg, wat waarschijnlijk een reden is geweest waarom de frame techniek geen onderdeel meer uitmaakt van HTML5.

Enter PHP

Tegenwoordig los je bovengenoemd scenario op met wat server side includes worden genoemd. Je maakt dan losse pagina’s voor je footer, je menu enz. en die voeg je dan op de plek waar ze in pagina moeten toe aan de code. Voor web development uitdagingen pagina betekende dat ik de werkende index.php pagina heb gepakt en daar de header, het menu, de footer en de aside van mee gemaakt heb. Voordeel van deze  aanpak is dat ik dus niet op 10 pagina’s het menu moet aanpassen, maar alleen maar menu.php.

Pagina’s in een andere pagina opnemen gaat heel makkelijk met include. Mocht een in te voegen deel van een pagina nu essentieel zijn voor de werking van de pagina dan heb je daar de functie require voor. In dat geval zal de pagina niet werken als het benodigde bestand ontbreekt. Van beide functies heb je ook een _once variant. Die is handig om te voorkomen dat je 2 keer een include opneemt waarin je een functie definieert. Een functie mag namelijk maar een keer gedefinieerd worden.

Includepad

Het is gebruikelijk de losse in te voegen bestanden in een includes map te zetten. Bijvoorbeeld www.example.com/includes/menu.php. Nadeel van deze werkwijze is dat het menu los van de site waar het bijhoort  te benaderen is. Je kunt er ook voor kiezen om je includes op te slaan in de map boven je www (root) map. Je verwijst dan als volgt vanaf de root ../includes.menu.php. Het menu wordt nu keurig opgenomen in de site maar is door bezoekers niet meer los te benaderen.

Benieuwd naar het resultaat tot nu toe? Klik op de schermafbeelding van de website. Die geeft overigens niet de actuele situatie weer.

Volgende uitdaging:

Lege pagina’s vullen.

Zaterdag schreef ik dat je door de includes map buiten de www/public_html map te plaatsen, een map hoger dus, een mooie manier hebt om ervoor te zorgen dat bestanden die je opneemt als onderdeel van andere pagina’s niet als zelfstandige pagina’s te benaderen zijn. Gisteravond meende ik te ontdekken dat dat voor deze website niet lukte.

Het ging althans niet via WinSCP, maar ik ontdekte net pas dat het wel ging ik de file manager van het beheer systeem van de website gebruikte.  Ondertussen had ik al al drie andere oplossingen gevonden. Die schrijf ik maar gauw op voordat ik ze vergeet.

Methode 1: .htaccess

De eerste methode is waarschijnlijk de eenvoudigste. Stel dat je de map onzichtbaar niet benaderbaar wilt hebben. Je plaatst dan in die map het bestandje .htaccess. Dat wil zeggen: beginnen met een punt en eindigen zonder extensie. Dat bestandje heeft maar 1 regel nodig:

deny from all

De methode werkt prima, maar heeft als nadeel dat het er gebruikersonvriendelijk uit ziet. Kijk maar:

Forbidden

You don’t have permission to access /wachtwoord/ on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Methode 2: gebruik functies

Methode 2 levert een blanco scherm op. Zie dit voorbeeld. De pagina bevat echter wel code. Maar die code maakt onderdeel uit van een functie en het resultaat van de functie is pas zichtbaar als de functie aangeroepen wordt, wat hier dus niet is gebeurd. Dit principe kun je gebruiken om de van inhoud van pagina’s in een includemap onzichtbaar te maken. Je neemt het bestand op in een pagina en roept vanaf die pagina de functie pas aan. Je kunt het ook gebruiken als je alleen HTML hebt. Je maakt dan als volgt een functie aan:

function htmlWeergeven() {
echo '
<p>Hier plaats je alle html code</p>
';
}

PHP code is nooit zichtbaar en een browser in de code de opdracht is gegeven HTML output te generen, bijvoorbeeld met het commando echo, zoals hierboven.

Methode 3: gebruik het verschil in URL

Dit vind ik zelf de leukste methode omdat je hiermee de vrijheid hebt om zelf te bepalen wat je bezoeker te zien krijgt.

Waar het bij deze methode om draait, is dat de bestanden toegankelijk moeten zijn als ze ingevoegd zijn, met ofwel include of met require. Benader je het losse bestand dan dient het bestand niet toegankelijk te zijn. Het draait om de url. Als een bestand ingevoegd is, heeft het geen zelfstandige url. Als je bestand zelf benadert, krijg je bijvoorbeeld deze url:
http://webdevelopmentuitdagingen.nl/oefenpaginas/includes/verbergen.php

Het gaat om  de map includes. Die wil ik ontoegankelijk maken. In PHP kun je met verschillende functies urls uitlezen.  De code die daarvoor zorgt in bovengenoemd bestand is:

$url = $_SERVER['REQUEST_URI'];
$url = explode('/', $url);
print_r($url);

In de eerste regel wordt de url van het bestand als tekst (string) opgeslagen opgeslagen in de variabele $url. De 2 regel maakt losse blokken van de url met de / als scheidingsteken en de derde regel toont die losse blokken; of array elementen, om ze hun juiste namen te geven. De print_r regel toont de array op het scherm en moet weg voor je het bestand daadwerkelijk uploadt.

Je kunt nu een voorwaarde maken op basis van de url. Array element nummer 2 van $url is includes. Dat kun je bevragen:

if ($url[2]=='includes') {
		echo '<h1>Excuses</h1><p>Deze pagina is helaas
 niet beschikbaar. Klik 
<a href="http://www.webdevelopmentuitdagingen.nl">hier
</a> om terug te gaan naar de site.<p>';
		exit();
	}

Binnen dat echo is natuurlijk alles mogelijk. Maar je kunt ook automatisch doorlinken door in plaats van echo header('Location:http://www.webdevelopmentuitdagingen.nl'); op te nemen. Voor die header mag echter geen enkele code ge-echo’d. worden, zelfs geen spatie of nog erger html code die niet gemaakt is door PHP.

Typ overigens niet Loation i.p.v. Location, een tikfout die mij nogal eens overkomt. De hoofdletter, de () en de aanhalingstekens zijn verplicht, net als de puntkomma aan het einde.

Het commmando exit() zorgt ervoor dat alle code die hierna komt niet meer uitgevoerd wordt, hetzij PHP, hetzij HTML/JavaScript. En exit() werkt ook voor de pagina waarin het bestand eventueel ingevoegd wordt.

Het mooie van dit script op basis van if ($url[2]=='includes') is dat je de conditie zo in kunt vullen als je zelf wilt en dat je ook helemaal zelf kunt invullen wat er gebeurt als niet aan de conditie wordt voldaan. Je kunt bij wijze van een spreken een pseudo-404-pagina ontwerpen als je daar zin in hebt. Of een mooie easter egg verstoppen.

En het allerleukste?

Je kunt dit script uiteraard met een simpele regel code ‘includen’ of ‘requiren’ in alle bestanden waarvan je inhoud wilt verbergen.

Voor ik aan mijn opleidingstraject tot web developer begon, heb ik eerst gekeken of het mij echt interesseerde en of ik er voldoende van begreep om het enigszins kansrijk te maken.

Ik ben namelijk nogal talig aangelegd, wiskunde is dan ook niet mijn sterkste kant. Die eerste kennismaking verliep aan de hand van de Udemy Course The Complete Web Developer Course van Rob Percival HTML & CSS. Design and build websites van Jon Duckett, HTML en CSS de basis van Andree Hollander, Handboek JavaScript & jQuery van Peter Kassenaar en wat CodeCademy. Toen mijn vorige baan teneinde liep was ik al begonnen, vandaar en het duurde even voor ik met mijn cursus kon beginnen.

Testen en nog eens testen

Omdat ik ervan doordrongen was dat mezelf testen voor mij een belangrijke voorwaarde is om succesvol te leren, heb ik zo veel mogelijk oefeningen gemaakt en heb daarnaast veel in Anki gezet (Anki is een programma waarmee je jezelf kunt overhoren volgens de principes van gespreid herhalen).  Veel van wat ik in Anki zette, formuleerde ik als kleine opdracht: maak een array met zeven huisdieren en geef er daarvan drie cursief weer. Doordat ik die opdrachten uitschrijf in Notepad++ en vervolgens in de browser open om te kijken of het daadwerkelijk werkt, maak ik me de eigenaardigheden van de code eerder eigen dan wanneer ik de oplossingen alleen voor me uit prevel. Dit alles wordt nog versterkt doordat ik Anki iedere avond gebruik. Ook met de opdrachten van mijn opleiding probeer ik dagelijks bezig te zijn.

Web Development uitdagingen

De afgelopen dagen ben ik bezig geweest de opdrachten die ik voor de Udemy cursus gemaakt heb, online te zetten op Web development uitdagingen, de site bij deze blogserie. Ik vond die cursus als inleiding behoorlijk interessant, zeker omdat je zowel kennismaakte met HTML/CSS als met JavaScript/jQuery en PHP/MySQL en Bootstap. Het is echter inleidend en mijn huidige opleiding graaft dieper.

Challenges

Maar omdat de Udemy cursus iedere module afsloot met een leuke programmeeropdracht, leek het mij aardig om die programmeeropdrachten op de site te zetten. Hier en daar heb ik er wat aanpassingen in aangebracht. Zo kreeg ik met mijn oorspronkelijke uitwerking van PHP opdracht een PHP foutmelding als ik mijn eigen woonplaats opzocht. Dat heb ik opgevangen door eerst te controleren of de url bestaat (i.e. geen 404 oplevert).

Voor het geheime dagboek dat de MySQL module vormde heb ik besloten om de md5 encryptie te vervangen door password_hash en password_verify. Dit omdat PHP.net het gebruik van md5 afraadt bij het opslaan van wachtwoorden.

Tot slot vond ik het spelen met JavaScript spelletje zo leuk, dat ik er zelf nog een versie voor 2 personen voor heb gemaakt.

Neem dus vooral een kijkje op Web development uitdagingen.

Volgende uitdaging:

Maak een contactformulier.

Gisteren en vandaag heb ik na het zien van een stukje code dat ergens anders ontbrak  gebruikt om me eens flink te verdiepen in de veiligheid van PHP. En dan vooral de veiligheid van gebruikersinvoer want dat je die niet zonder meer mag vertrouwen is me de afgelopen maanden al wel duidelijk geworden.

En het was maar goed dat ik me erin verdiepte. Er ontbrak dus ergens een stukje code. In mijn code voor het gastenboek dat binnenkort hopelijk op Web development uitdagingen verschijnt. Dat kan tot het onderstaande resultaat leiden:

Hoe heb ik deze ‘hack’ bewerkstelligd? Op de plek waar ik een bericht in kon vullen, heb ik simpelweg het volgende ingevuld:

<script>alert('Gehackt!');</script>

Dat was alles. Maar naar natuurlijk zijn er gevaarlijkere manieren om deze kwetsbaarheid te exploiteren. Je zou bijvoorbeeld een script van een andere pc kunnen laden en met met dat script die ander ongemerkt toegang geven tot jouw computer. De techniek heet Cross-site scripting (XSS).

Kwetsbaarheid oplossen

Gelukkig is de kwetsbaarheid die ik hier liet zien betrekkelijk eenvoudig op te lossen. Het gaat erom dat de PHP engine op de server te gevaarlijke code niet meer als zodanig interpreteert. Aanhalingstekens en haken moeten daartoe omgezet worden in ongevaarlijke tekens. Meerdere mogelijkheden, ik noem er drie:

1. strip_tags.() Deze functie zorgt er in bovenstaande voorbeeld voor dat de script tags verwijderd worden waardoor het voorbeeld slechts een onschuldige tekst oplevert.
2. htmlentities(). Deze functie zorgt ervoor dat alle karakters waarvoor de functie aangeroepen wordt, omgezet wordt naar HTML code.
3. htmlspecialchars() Doet hetzelfde als nummer 2, maar behoudt accenten. Die worden door htmlentities() namelijk omgezet in HTML code.

Zelf geef ik de voorkeur aan htmlspecialchars(). Hoe maak je de code nu veilig? Ik geef de code die berichten uit het gastenboek laat zien.

function show_post($result)
		{
			
			foreach ($result as $key => $value)
				{
					echo '<div class="box">';
					foreach ($value as $subkey => $subvalue)
						{
							$subkey = htmlspecialchars($subkey);
							$subvalue = htmlspecialchars($subvalue);
							echo '<div class="' . $subkey . '">' .  $subvalue . '</div>';	
							if($subkey == "id")
								{
									echo '<a href="update.php?id=' . $subvalue . '"><div class="update"></div></a>';
									echo '<a href="delete.php?id=' . $subvalue . '"><div class="delete"></div></a>';
								}
						}
					
					echo '</div>';
				}

In de oorspronkelijke code ontbraken regels 9 en 10. Deze regels zorgen er nu voor dat de gebruikersinvoer gecontroleerd wordt voordat deze op het scherm getoond wordt.

Nog een kwetsbaarheid

Bij formulieren is het gebruikelijk om aan te geven welke method (get of post) er gebruikt wordt. En welke pagina de afhandeling verzorgt (action). Het action attribuut kan sinds HTML5 weggelaten worden. In dat geval is de huidige pagina de pagina die het formulier afhandelt.

Je kunt ook kiezen voor een stukje PHP. De functie $_SERVER[‘PHP_SELF’] is huidige pagina. Die kun je als volgt opnemen in je action.

<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">

Met htmlspecialchars dus. Doe je dat niet dan kun je met de volgende tekst achter de url in de adresbalk hetzelfde ‘Gehackt’ scherm te zien krijgen als waar we mee begonnen.

/%22%3E%3Cscript%3Ealert('Gehackt!')%3C/script%3E

Het laatste voorbeeld is overigens afkomstig van W3Schools. Welbestede dagen, zou ik denken. Eenvoudig te testen veiligheid.

Wordt ongetwijfeld vervolgd, al is het maar met een aflevering over gebruikersinvoer en de database.

Veel te lang niet geblogd. Maar goed, ik leer van alles. Hoog tijd om daarvan verslag te zodat ik het nog wat beter leer en onthoud. Na avonturen met PHP heb ik in mijn opleiding inmiddels ook het MySQL-gedeelte – ofwel werken met databases – succesvol afgerond. Maar voor ik dat hier laat zien nog een stukje PHP.

Eén van de dingen die nog openstaan – zowel hier als op Web development uitdagingen – is een contactformulier. En laat je die nu vrij eenvoudig kunnen maken met PHP, zeker als je gebruikmaakt van frameworks, bibliotheken die je kunt invoegen in pagina’s die je zelf ontwikkelt. Voordeel daarvan is onder andere dat je je minder druk hoeft te maken om allerlei veiligheidsrisico’s. Natuurlijk kun je niet alles blindelings vertrouwen, zo kan het geen kwaad om htmlspecialchars() om je gebruikersinvoer te zetten.

Een bekend framework is PEAR. Het zit meegeleverd bij PHP. Niet compleet, de Mail module moet je dan zelf weer installeren. Heb je dat eenmaal voor elkaar dan is de rest betrekkelijk eenvoudig.

De 3 stappen

1. Bouw een html pagina met daarin een formulier. In de meest basale vorm ziet dat er zo uit:

   <form method="post" action="contact.php">
   	<label>Naam   <input type="text" name="naam" required></label>
   	<label>E-mailadres  <input type="email" name="email" required></label>
   	<label>Je bericht <textarea name="bericht" required></textarea></label>
   	<input type="submit" name="submit" id="submit" value="Versturen">
   </form>

   Het contact-attribuut mag in html5 overigens weggelaten worden als de huidige pagina voor de afhandeling zorgt.

2. De tweede stap is dat je bovenaan de pagina een PHP-blok plaatst dat voor de afhandeling zorgt – lees: dat bepaalt wat er gebeurt als je op ‘Versturen’ klikt. In de eerste plaats moet je require_once 'Mail.php'; invoegen. Vervolgens moet je controleren of er op ‘Versturen’ is gedrukt. Logischerwijs heb ik gekozen voor de $_POST-verzendmethode want ik wil niet dat de hele inhoud van het contactformulier in de adresbalk komt te staan. Ik wil controleren of alle velden ingevuld zijn – en niet door op de spatiebalk te drukken – en ik wil nogmaals controleren of het e-mailadres geldig is. Dat heb ik weliswaar al gedaan met html door <input type=”email” /> aan te geven maar een extra controle lijkt me niet onverstandig. De code komt er als volgt uit te zien:

   if (isset($_POST['submit']) && !empty(trim($_POST['naam'])) && !empty(trim($_POST['bericht'])) && !filter_var($_POST['email'], FILTER_VALIDATE_EMAIL) === false)

   De trim() functie zorgt ervoor dat spaties weggehaald worden. In eerste instantie had ik gekozen voor trim() in combinatie met isset() maar dat bleek niet te werken. De inhoud van deze regel: er is op de knop met de naam submit geklikt, na weghalen van de spaties zijn de velden ‘naam’ en ‘bericht’ niet leeg en het e-mailadres in $_POST[‘email’] is niet ongeldig.

3. Als aan die voorwaarden is voldaan, kan het daadwerkelijke mailscript in gang gezet worden. Dat mailscript bestaat kort gezegd weer uit drie onderdelen: a) de mailsettings (een Gmail-adres werkt niet), b) de mail zelf die is opgebouwd uit een aantal header variabelen en die gegevens uit $_POST bevatten omdat daar de inhoud van de mail in staat en tot slot c) het mechanisme dat het versturen van de mail bewerkstelligt.Tot zover mijn korte uitleg over het PEAR mailscript. Mocht je meer willen weten, laat dan vooral een reactie achter in de comments of gebruik natuurlijk het contactformulier van Web development uitdagingen.

To do

• Uitzoeken of een captcha mogelijk is.
• Contactformulier bij dit blog maken.

Toen ik eind januari hoorde dat ik mijn opleiding tot web developer succesvol had afgerond, nam ik mij voor om vanaf maart alle tussentoetsen en het examen opnieuw te maken. Tegen die tijd was er behoorlijk wat tijd voorbij gegaan sinds ik ze maakte zodat  opnieuw maken een goede en leerzame herhaaloefening zou zijn van stof die misschien een beetje was weggezakt.

Een ander plan

Maar mijn oom en tante hadden een beter idee. Voor fietsers in de mooie regio Noord-Limburg verhuren zij sinds kort kamers op de bovenverdieping van hun boerderijwoning en daar wilden ze graag een site voor hebben. Of ik die wilde maken? Natuurlijk had ik daar wel oren naar want ik realiseerde me meteen dat de opdracht alles zou bevatten wat ik tijdens mijn opleiding had geleerd en nog heel wat meer. We werden het er al snel over eens dat mijn oom en tante voor de inhoudelijke invulling zouden zorgen en hun wensen kenbaar zouden maken wat betreft vormgeving zodat ik me kon richten op de technische kant.

De website van mijn oom en tante is te vinden via Slapen en Ontbijten “Op de Kogel”  of door op bovenstaande afbeelding te klikken. Bekijk de site vooral en boek een kamer want het is inderdaad een mooie omgeving.

Wat kwam er kijken bij de site?

• De site moest goed werken op alle mogelijke schermen. Websitebouwers noemen dat responsive design. Dit was een behoorlijke klus omdat het bij de extra opdrachten van mijn opleiding hoorde en dus niet werd getoetst.
• Een fotoboek en een slider.
• Een contactformulier dat automatisch een mailtje stuurt nadat het ingevuld is.
• Sommige pagina’s moeten door mijn oom en tante gewijzigd kunnen worden zonder dat ze dat steeds aan mij moeten vragen.
• Er moest dus gewerkt worden met een database en een administrator gedeelte waarin op een eenvoudige manier wijzigingen aangebracht kunnen worden aan pagina’s. Ik heb daarvoor CKEditor gekozen.
• Het administrator gedeelte dient uiteraard afgeschermd te zijn met een login en wachtwoord.
• En bijna tot slot, maar niet onbelangrijk: ik had voor het eerst echt met klanten te maken die wensen hadden voor hun website. En er veranderde tijdens het ontwerpen weleens wat of er kwam een nieuw idee.
• Dat zorgde er dus voor dat ik de site van de grond af aan op moest bouwen. Mijn oom en tante hadden ideeën, het was aan mij om die in een werkzame site om te zetten. En voor het eerst zonder stappenplan (= te maken opdrachten) van de opleiding.

Al met al was het een leuke en ook leerzame klus.  En had je nu al op Slapen en Ontbijten “Op de Kogel” gekeken?