Het probleem

Bij het creeëren van je datamodel heb je wellicht rekening gehouden met het optimaal gebruiken van de datatypes die MySQL aanreikt. Een voorbeeld is het verschil tussen de tinyint en de smallint, een tinyint kan maximum waarde 255 bevatten en een smallint maximum 65 535 (wanneer ze worden ingesteld als unsigned). In een optimale database is er goed afgewogen welke datatypes er gebruikt worden voor welk veld. De unieke sleutel van je gebruikerstabel zal waarschijnlijk geen tinyint zijn, tenzij je maar 255 leden verwacht. Maar hoeveel leden verwachten je dan wel? Omdat dit moeilijk in te schatten is, hebben Massimo en ikzelf een tool geschreven die ons toont hoe ver de tabelvelden ‘bevolkt’ zijn. Met de Data Type Usage Profiler (DTUP) kan een volledige database beheerd worden en kunnen de volgende datatypes gecontroleerd worden op hun bevolkingsgraad:

• alle integers (tinyint, smallint, mediumint, int en bigint)
• alle teksten (tinytext, text, mediumtext en longtext)
• varchar (met eigen ingestelde lengte)

In de DTUP zijn er 4 niveaus of zones waarin een datatype zich kan bevinden. Elke zone heeft een kleuraanduiding die terugkomen in de tabelweergave van de databasetabel en in de grafische weergave. De mogelijke zones zijn:

1. > 90% – Rood
2. > 75% – Licht rood
3. > 50% – Oranje
4. < 50% – Groen

Als een datatype zich in de groene of oranje zone bevindt, is er nog geen reden tot het doorvoeren van database aanpassingen. Als echter de het bezettingspercentage > 75% is, dan kan misschien geopteerd worden om een datatype hoger te nemen of de lengte aan te passen. De test op de datatypes uit de reeks van integer gaat kijken naar de hoogste waarde in de tabel. De varchar en text reeks gaat rekening houden met de lengte die het aantal karakters in beslag neemt.

DTUP is gemaakt met het vertrouwde CodeIgniter en Smarty. De pagina die getoond wordt door de controller te bezoeken, bestaat uit 3 delen.

1. Overzicht: geeft het aantal gevallen weer die voorkomen in elke zone op een pie chart;
2. Tabellenlijst: alle tabellen die voorkomen in de gebruikte database;
3. Databasetabellen: bevat een tabel die weergeeft hoeveel waarden er in gebruik zijn en hoeveel er maximum gebruikt mogen worden met als laatste kolom in de tabel de procentuele verhouding tussen aantal gebruikte en maximum te gebruiken. Een bar chart vervolledigt de tabel door op een grafische manier de verhouding nogmaals weer te geven. Zowel de tabel als de grafiek maken gebruik van de kleuren die bij de zones horen.

Waar jullie allemaal op wachten, screenshots

Deze pie chart toont de beknopt overzicht van alle velden uit de database. Het grootste deel in de voorbeeld database is gezond (groen) en enkele velden bevinden zich in de kritische zone. De velden die vooral in die rode zone liggen zijn velden waarvan we op voorhand de maximale lengte kennen, bijvoorbeeld omdat we een MD5 hash gebruiken.

Bovenstaande schermafbeelding geeft duidelijk weer waar dit artikel en DTUP eigenlijk om draait. Alle velden van een bepaalde tabel worden getoond met informatie zoals aantal gebruikt, maximum te gebruiken en de procentuele verhouding. Ook het datatype is weergegeven zodat er van hieruit beslist kan worden welk datatype misschien de opvolger kan worden van het huidige, te kleine, datatype.

Bovenstaand voorbeeld kan een deel zijn van een gebruikerstabel. Zoals al gezegd, wisten we op voorhand dat het wachtwoord 32 tekens lang ging zijn, dus dat rode veld is geen verrassing. Het veld waarin de gebruikersnaam wordt bijgehouden is ook volledig gebruikt. Er heeft zich namelijk een gebruiker geregistreerd met een gebruikersnaam die net 32 karakters is. Nu is de vraag, houden we de beperking op die 32 tekens, of breiden we het veld uit? Dat hangt natuurlijk af van het doel. In ons voorbeeld stellen we dat er van hogerhand beslist is dat een gebruikersnaam nooit langer mag zijn dan 32 tekens.

Dit voorbeeldje ging over een varchar veld. Het is een heel ander verhaal wanneer het gaat om een unieke sleutel die automatisch verhoogd wordt met AUTO_INCREMENT.

In onze instellingen tabel is er gekozen om met een tinyint te werken als unieke sleutel die maximum 255 records toelaat. Zoals te zien is in bovenstaande figuur is ondertussen waarde 240 bereikt. Als er nog meer instellingen bijkomen, is het misschien niet onbelangrijk om op dit moment het datatype tinyint op te krikken naar een smallint die tot waarde 65 535 aankan. Voor deze tabel is het natuurlijk geen probleem als de unieke sleutels op zijn. Voor een gebruikerstabel, waarvan de ID zichzelf verhoogt, kan dit veel kritischer zijn omdat, eenmaal de grens bereikt is, er geen leden meer kunnen registreren en dat wil je natuurlijk niet.

Voila

Ik hoop dat ik jullie een nieuwe kijk heb kunnen geven op de manier waarop Massimo en ikzelf Spacetarion onderhouden.

Dit zelfgeschreven profiler tooltje met behulp van CodeIgniter, Smarty en een MySQL database laat ons toe nauwgezet de bevolking van onze datatypes te monitoren. Deze pagina is toegankelijk vanuit het beheerpaneel van Spacetarion dat opgebouwd is met ExtJS. Binnenkort zullen onze trouwe volgers ook een blik kunnen werpen op de adminkant van Spacetarion. Zo weten jullie des te meer waar wij mee bezig zijn. Met dat paneel en deze DTUP kunnen wij ons uitgebreid systeem opvolgen om het zo stabiel mogelijk te presenteren aan de spelers, hopelijk aan jou dus.

Verbeteringen? Altijd mogelijk…

Mogelijke verbeteringen zijn er altijd, zo zou ik nog kunnen voorzien dat het datatype vanuit de DTUP gewijzigd kan worden. Een tweede verbetering die ik nog zou kunnen doorvoeren, is alle autonummeringvelden als speciaal veld behandelen waarbij een verhouding van > 75% echt kritiek is. In het geval van kritieke autonumeringvelden kan ik via een cronjob mezelf via mail op de hoogte houden en direct ingrijpen. Een stap verder is dat het systeem zichzelf kan verbeteren door automatisch zijn datatype te verhogen en me via mail op de hoogte stellen dat deze actie ondernomen werd.

De DTUP staat nog maar in z’n kinderschoenen en kan dus nog verder uitgebreid worden. Misschien heb jij wel een suggestie die DTUP kan omvormen tot een mooi product dat voor iedereen te downloaden zal zijn in de toekomst? Laat het ons zeker weten!

Waarom zit het niet standaard in CodeIgniter?

Daar zijn 2 goede redenen voor. De eerste is de meest voor de hand liggende. CodeIgniter heeft namelijk zijn eigen manier om om te gaan met templates. In CodeIgniter termen noemen deze ‘view files’. Telkens wanneer je het volgende doet, roep je dus eigenlijk een template aan.

$this->load->view('home', $data);

Een andere mogelijke reden waarom Smarty niet standaard bij CodeIgniter wordt geleverd is omdat er meerdere mogelijkheden zijn. Smarty is wel de bekendste, maar zeker niet de enige template engine. Een template engine biedt natuurlijk vele voordelen waaronder caching, afscherming van de PHP code voor designers, handige tags, etc.

Waar zetten we Smarty?

De eerste stap is natuurlijk het uploaden van de Smarty bestanden naar je webhost. De beste locatie om deze te plaatsen vind ik persoonlijk de libraries map onder system/application/. Dit enerzijds omdat Smarty een library is die je zal gebruiken en anderszijds omdat ik al mijn eigen uitbreidingen in die map plaats. Zo blijven alle zelfgemaakte bestanden mooi bij elkaar en kan ik beter het overzicht behouden. Mijn system/application/libraries map zie je links op de afbeelding.

Zoals je ziet heb ik de originele naam van de Smarty map behouden. Hierdoor kan ik makkelijk zien welke versie ik heb wanneer er updates uitkomen. Deze naam mag je uiteraard zelf kiezen, maar ik zou de bestanden wel in een map houden, ook weer om het overzicht te behouden.

Noot: wanneer je werkt met meerdere applicaties op één CodeIgniter installatie, kan het handig zijn om deze map in system/libraries te plaatsen. Op die manier hoef je maar één keer Smarty te uploaden in plaats van één keer voor elke applicatie.

De Smarty klasse

Het is uiteraard niet voldoende om gewoon de map te uploaden naar je server. Het Smarty object moet bereikbaar zijn vanuit de CodeIgniter klassen (meestal vanuit een controller). Een klasse toevoegen aan het CodeIgniter framework is helemaal niet moeilijk, eerst moet je de klasse uiteraard schrijven en deze daarna gewoon automatisch inladen met behulp van autoload.php.

Zoals je uit de onderstaande code kan afleiden, heb ik deze klasse de naam ‘S’ gegeven. Ik heb gekozen om ‘S’ als naam te nemen in plaats van ‘MY_Smarty’ om de simpele reden dat ‘S’ korter is dan ‘MY_Smarty’ (en omdat ‘Smarty’ al gereseveerd is door … jawel … Smarty zelf). Wanneer ik nu een template aanroep hoef ik dus niet altijd

$this->my_smarty->display('home');

te gebruiken, maar simpelweg

$this->s->display('home');

wat in de grotere applicaties toch al snel heel wat typwerk minder is. De hardcore Smarty fans zien ook meteen dat ik de extensie .tpl kan weglaten bij het aanroepen van een template. Deze ‘functionaliteit’ is ook voorzien in de S klasse.

Zoals je op de afbeelding van mijn bestandsstructuur al kon zien, heb ik gewoon een bestandje S.php aangemaakt in de system/application/libraries/ map. De inhoud van dit bestand is als volgt:

<?php
require_once "Smarty-2.6.22/Smarty.class.php";
 
class S extends Smarty {
    function S() {
        $this->Smarty();
 
        // Het config object van CodeIgniter ophalen
        $config =& get_config();
 
        // Aan de hand van de config de mappen die Smarty zal gebruiken instellen
        $this->template_dir = (!empty($config['smarty_template_dir']) ? $config['smarty_template_dir'] : BASEPATH . 'application/views/');
        $this->compile_dir = (!empty($config['smarty_compile_dir']) ? $config['compile_dir'] : BASEPATH . 'cache/');
 
        // base_url is een handige functie, die willen we altijd bij ons hebben
        // In een Smarty template kunnen we dan gewoon {$base_url} gebruiken
        if (function_exists('base_url')) {
            $this->assign('base_url', base_url());
        }
 
        $this->clear_all_cache();
    }
 
    function display($resource_name) {
        // .tpl toevoegen indien dit niet in het gevraagde bestand staat
        if (strpos($resource_name, '.tpl') === false) {
            $resource_name .= '.tpl';
        }
 
        // Hier kan je allerlei code toevoegen die moet gebeuren vlak voor het tonen van de pagina
 
        // De pagina tonen
        return parent::display($resource_name);
    }
}

Let op: de compile map die je aangeeft moet schrijfbaar zijn door de webserver. Ik gebruik altijd 777, maar misschien is minder ook al goed. Kan iemand dat duidelijk maken?

De S klasse moet natuurlijk in het CodeIgniter framework worden ingeladen voordat je deze kan gebruiken in een controller. Hiervoor open je gewoon system/application/config/autoload.php en voeg je bij het ‘libraries’ onderdeel de ‘S’ klasse toe als volgt:

$autoload['libraries'] = array('s');

Wat met $smarty.session?

CodeIgniter maakt, zoals je misschien weet, geen gebruik van de globale $_SESSION variabele van PHP. Om gegevens bij te houden, maakt CI gebruik van cookies en/of een database (kan je instellen in het config bestand). Dit brengt echter wel een minpunt met zich mee in dit geval. Smarty kan namelijk de $_SESSION variabele aanspreken met behulp van $smarty.session. Maar aangezien CI hier geen gebruik van maakt, is dit niet mogelijk

Maar voor elk probleem is natuurlijk een oplossing. Ik heb in de display functie van de S klasse een stukje code geschreven dat alle gegevens uit $this->session (de plaats waar CI alle sessiegegevens opslaat) haalt en ze doorgeeft aan Smarty. Dit is makkelijk te doen met een foreach, maar dat laat ik als uitstekende oefening voor thuis.

Een klein voorbeeldje

system/application/controllers/Voorbeeld.php

<?php
class Voorbeeld extends Controller {
    function index()
    {
        $tekst = 'hello world...';
        $this->s->assign('tekst', $tekst);
        $this->s->display('voorbeeld');
    }
}

system/application/views/voorbeeld.tpl

Dit is de doorgegeven tekst:<br />
<br />
{$tekst}

Wanneer je aan een klein projectje werkt, is het makkelijk om zelf even elke dag na het programmeren snel even alle bestanden af te halen. Wanneer je echter aan grote projecten werkt, zoals ik nu aan Spacetarion, kan het afhalen van alle bestanden al snel 5 tot 10 minuten duren. Daarom had ik nood aan een automatische oplossing. Omdat ik deze best wel handig in gebruik vind, deel ik mijn opgedane kennis graag met jullie. Als fervente CodeIgniter fan, heb ik dit natuurlijk met behulp van dit framework gedaan.

Wat heb ik allemaal nodig?

Er zijn 2 dingen die nodig zijn om dit werkend te krijgen. Eerst en vooral moet je toegang hebben tot cronjobs. Dit hangt af van je webhost. De meeste fatsoenlijke hosts, zoals Futureweb en Combell, ondersteunen cronjobs. De cronjob zorgt ervoor dat het script automatisch elke 24 uur wordt uitgevoerd. Eigenlijk zal het script dus ook werken zonder cronjobs, maar dan moet je er zelf aan denken elke dag de controller een bezoekje te brengen.

Een andere voorwaarde is dat je je CodeIgniter system map niet buiten de web root hebt staan. CI buiten de web root installeren is veiliger omdat mensen geen toegang kunnen krijgen tot de bestanden in de installatie. Het nadeel is echter dat ook de ‘gebruiker’ die PHP uitvoert (Apache) ook geen rechten heeft om bestanden buiten de root te lezen. Aangezien het script dat we gaan gebruiken van elk bestand de inhoud moet kunnen lezen, zal dit enkel werken indien CI volledig in de web root staat. Meestal is deze root de map ‘www’ of ‘public_html’. Het kan zijn dat je bij jouw host enkel toegang hebt tot de web root. Indien je nergens een map ‘www’ of ‘public_html’ terugvind, is dit het geval en kan je het script gebruiken.

Noot: wanneer je je system map wel in de www map hebt staan, kan je deze nog altijd afschermen van het publiek door een klein .htaccess bestand in de system map te zetten. De inhoud van dit .htaccess bestand moet dan het volgende zijn:

order allow,deny
deny from any

Op die manier zal iedereen (behalve de Apache gebruiker) een 403 Forbidden error krijgen. Zo zijn je bestanden toch beschermd (wel minder goed dan gewoon alles buiten de www map te zetten natuurlijk) en kan je toch dit backup script gebruiken.

De controller

We maken in de map system/application/controllers een nieuw bestand aan met als naam backup.php. We voorzien in dit bestand 2 functies: 1 functie die elke dag een backup zal nemen en 1 functie die elke maandag (dit wordt bepaald in de cronjob) de laatste backup per e-mail zal versturen. De inhoud van Backup.php is als volgt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

<?php
class Backup extends Controller
{
	function __construct()
	{
		parent::__construct();
 
		define('PASSWORD', 'your_password');
		define('MAX_BACKUPS', 14);
		define('BACKUP_DIR', '/welke/map/je/wil/backuppen/');
	}
 
	function index($password = null)
	{
		if ($password !== PASSWORD)
		{
			die('Get out');
		}
 
		$this->load->library('zip');
 
		// Bestanden backuppen
		$this->zip->read_dir(BACKUP_DIR);
 
		// Database backuppen
		$this->load->dbutil();
		$backup = &$this->dbutil->backup(array('format' => 'txt'));
		$this->zip->add_data('database.txt', $backup);
 
		// Het zip bestand opslaan
		$this->zip->archive(BACKUP_DIR . 'backups/' . date('YmdHis') . ' - ' . $this->zip->get_file_num() . ' files.zip');
 
		// Overbodige backups verwijderen
		$this->load->helper('file');
		$files = get_filenames(BACKUP_DIR . 'backups/');
 
		// Controleren of er al backups zijn
		if (count($files) !== 0)
		{
			sort($files);
 
			$delete = count($files) - MAX_BACKUPS;
			for ($i = 0; $i < $delete; $i++)
			{
				unlink(BACKUP_DIR . 'backups/' . $files[$i]);
			}
		}
	}
 
	function mail_backup($password = null)
	{
		if ($password !== PASSWORD)
		{
			die('Get out');
		}
 
		$this->load->helper('file');
		$files = get_filenames(BACKUP_DIR . 'backups/');
 
		// Controleren of er al backups zijn
		if (count($files) !== 0)
		{
			rsort($files);
 
			// De laatste backup mailen
			$this->load->library('email');
			$this->email->from('no-reply@example.com', 'Backup system');
			$this->email->to('you@example.com');
			$this->email->subject('Your backup');
			$this->email->message('Your backup');
			$this->email->attach(BACKUP_DIR . 'backups/' . $files[0]);
			$this->email->send();
		}
	}
}

De cronjob

De cronjob zal ervoor zorgen dat de Backup controller elke 24 uur opgeroepen wordt. Deze controller zal dan een backup nemen en het bestand opslaan op de server. De manier om cronjobs in te stellen is bij elke host meestal anders. Ik kan dus niet stap voor stap uitleggen hoe je dit moet doen. Het commando dat moet worden uitgevoerd is echter altijd hetzelfde, en ziet er als volgt uit:

1

0 0 * * * wget http://www.jouwsite.be/backup/index/your_password/ -O /dev/null

Deze cronjob zal elke dag om 0:00 worden uitgevoerd. Dit tijdstip kan je zelf aanpassen. De structuur van de argumenten is ‘minuut’, ‘uur’, ‘dag van de maand’, ‘maand’, ‘dag van de week’. Indien je 12 0 * * 1 gebruikt, zal er elke maandag om 12 uur ’s middags een backup worden genomen.

Je moet natuurlijk ook de ‘jouwsite.be’ vervangen door het domein waarop jouw site staat. De ‘your_password’ op het einde is het wachtwoord dat je hebt gedefiniëerd in de controller. De ‘-O /dev/null’ zorgt ervoor dat de cronjob geen logfile zal schrijven naar de website. Indien je dit weglaat zal er elke keer de cronjob wordt uitgevoerd een bestand in de root van je website bijkomen. Na verloop van tijd kan dit aantal flink oplopen. Het is dus een goed idee om deze logfiles weg te laten.

Je kan ook een aparte cronjob aanmaken om de laatste backup per e-mail te ontvangen. Persoonlijk neem ik elke dag een backup, en krijg ik elke maandag om 6 uur ’s morgens graag de laatste backup in mijn inbox. Deze cronjob ziet er als volgt uit:

0 6 * * 1 wget http://www.jouwsite.be/backup/mail_backup/your_password -O /dev/null

Het resultaat

Het resultaat is best wel duidelijk. Je webserver zal nu elke dag een backup nemen van alle bestanden EN de volledige database. Ook zal je elke maandag een e-mail krijgen waarin de laatst genomen backup zal zitten. Ook zullen op de server maximaal 14 backups worden bijhouden, zo heb je iets of wat controle over hoeveel plaats de verschillende backups innemen.

Zoals je misschien al gemerkt hebt, zijn alle werken op deze website gelicenseerd onder een Creative Commons licentie. Wanneer je mijn werk wil gebruiken kan je dat vrij doen, zolang je mijn naam bij het werk zet en het niet dient voor commerciële doeleinden. Wanneer je mijn naam liever niet bij het werk wil zetten of de scripts toch wil gebruiken voor commerciële doeleinden, dien je eerst een schriftelijke toestemming aan mij te vragen.

Is het mogelijk voor mij?

Er is één grote voorwaarde opdat je CodeIgniter kan installeren buiten deze map. De host die je je webruimte aanbied, moet jouw de juiste rechten geven zodat je bestanden kan uploaden boven de www map. Bij mijn vorige host, One.com, kon dit niet. Daarom ben ik ongeveer een jaar geleden verhuist naar een host die dat wel ondersteunt, Futureweb.be. De www map waarover ik steeds spreek, kan ook onder een andere naam voorkomen, bijvoorbeeld public_html of wwwroot.

CodeIgniter installeren

Het installeren van CodeIgniter is super makkelijk. Het enige dat je moet doen is de laatste versie van het framework downloaden van codeigniter.com en het pakket uitpakken. Wanneer dat gebeurd is kan je gewoon de system map en het index.php bestand uploaden naar je webhost.

Normaal gezien upload je deze bestanden naar één en dezelfde map op de server, maar indien je CodeIgniter buiten de www map wil installeren, is dit lichtjes anders. Het index.php moet je uploaden naar de www map, of een submap hiervan. Het komt er op neer dat het index.php bestand bereikbaar moet zijn voor bezoekers. Dit is het punt vanwaar de bezoekers de applicatie gebruiken, de voordeur zeg maar.

De system map moet je buiten de www map plaatsen. Bezoekers krijgen toegang tot deze bestanden via het index.php bestand, maar kunnen niet rechtstreeks bestanden in de system map aanroepen. Om even terug te komen op het huis waarvan ik de voordeur al vernoemde, mensen kunnen via de voordeur naar de keuken, maar kunnen niet meteen de koelkast komen plunderen.

Je kan best ook de naam van de system map wijzigen. Dit maakt de applicatie niet veiliger (want bezoekers kunnen er toch niet aan), maar zorgt er wel voor dat je zelf de structuur beter kan zien. Ik geef de system map altijd de naam van de applicatie die ik zal maken, maar je verzint wel iets creatief. Zo heb ik de system map van degrillmobiel.be simpelweg ‘grill’ genoemd.

Het index.php bestand aanpassen

Wanneer je nu echter een bezoekje brengt aan het index.php bestand met je favoriete browser, zal het geheel niet werken. Dit komt omdat de verwijzingen in het bestand nog niet juist zijn. In het index.php bestand staat de volgende lijn code (regel 26):

$system_folder = "system";

Dit is de locatie waar CodeIgniter gaat zoeken naar alle bestanden. Wanneer index.php bestand staat op www.host.com/submap/index.php zal CodeIgniter zoeken naar www.host.com/submap/system/ en deze niet vinden. Wanneer je het index.php bestand los in de www map hebt staan, moet je de regel als volgt aanpassen:

$system_folder = "../system";

Per submap moet je vooraan nog een extra ‘../’ toevoegen. Indien je index.php bestand dus te bereiken is op www.host.com/submap/index.php moet de $system_folder variabele ‘../../system’ zijn. Indien je de naam van de system map hebt gewijzigd, moet je hier natuurlijk ook rekening mee houden.

Enkele regels lager in het bestand staat nog een andere variabele, namelijk $application_folder. Je kan, net als de system map, ook de application map van naam veranderen. Dit is handig wanneer je meerdere applicaties op één CodeIgniter installatie wil draaien, maar daar kom ik in een latere blogpost nog uitgebreid op terug.

De gebruikelijke instellingen

Na het uploaden van CodeIgniter moet je natuurlijk nog wel de nodige instellingen aanpassen alvorens je een werkende website hebt. Het bestand dat je zeker moet aanpassen is config.php, te vinden in de map system/application/config/. In dit bestand moet je de volgende regel aanpassen:

$config['base_url'] = "http://example.com/";

In het voorbeeld waarbij onze site op www.host.com/submap/index.php staat, moet de regel als volgt veranderd worden:

$config['base_url'] = "http://www.host.com/submap/";

Werkt het?

Wanneer je nu een bezoekje brengt aan www.host.com/submap/ zou je de standaard pagina van CodeIgniter moeten te zien krijgen.

Voila, je hebt met succes CodeIgniter buiten de www map geïnstalleerd en afgeschermd van al die kwaadaardige gebruikers.

Er zijn nog enkele punten die beter kunnen. Zo kan je bijvoorbeeld met behulp van een .htaccess bestand makkelijk de /index.php/ uit de url halen. Dit ziet er niet alleen mooier uit, maar is ook beter vanuit een SEO (Search Engine Optimalisation) standpunt. In een latere blogpost kom ik hier zeker nog op terug.

Indien je na deze (heel uitgebreide) blogpost nog met vragen of problemen zit hoor ik het graag.

Wegwerp-e-mail adressen

Er zijn op het internet heel wat websites te vinden die e-mail adressen aanbieden die maar een tijdje blijven bestaan. Sommige onder jullie zullen misschien mailinator.com wel kennen. Op die website kan je elke mailbox raadplegen die onder dat domein valt. Wanneer je bijvoorbeeld op een website een registratieformulier moet invullen, kan je simpelweg piet@mailinator.com gebruiken. Achteraf ga je dan naar mailinator.com en raadpleeg je de mailbox van piet en klaar is kees… of piet in dit geval.

De uitbreiding

De oplossing is uiteraard een uitbreiding op de Email helper van CodeIgniter. We voegen een extra functie toe (is_valid_email) die controleert of het ingevoerde e-mail adres niet voorkomt in een lijst van geblokkeerde hosts. Uiteraard gebruiken we ook nog de standaard functie van CodeIgniter om het formaat te controleren.

Het enige dat je moet doen is in de system/application/helpers map een nieuw bestandje aan te maken met als naam MY_email_helper.php en de volgende code er in plaatsen:

<?php
function is_valid_email($address)
{
    // Blocked hosts
    $illegalHosts = array(
        '10x9.com',
        'blockfilter.com',
        'dandikmail.com',
        'deadaddress.com',
        'deadfake.com',
        'despam.it',
        'disposeamail.com',
        'dodgit.com',
        'dodgeit.com',
        'emailias.com',
        'gishpuppy.com',
        'greensloth.com',
        'guerrillamail.org',
        'haltospam.com',
        'hidzz.com',
        'incognitomail.net',
        'jetable.com',
        'kasmail.com',
        'litedrop.com',
        'mailcatch.com',
        'maileater.com',
        'mailexpire.com',
        'mailinator.com',
        'mailnull.com',
        'mailzilla.com',
        'makemoneytradingstocks.org',
        'mint.us.to',
        'mt2009.com',
        'mytempemail.com',
        'mytrashmail.com',
        'nospam4.us',
        'nospamfor.us',
        'pookmail.com',
        'pourri.fr',
        'shieldemail.com',
        'shortmail.com',
        'signed-first-edition.com',
        'skeefmail.com',
        'slopsbox.com',
        'sneakemail.com',
        'spam.su',
        'spambox.com',
        'spambox.us',
        'spamcero.com',
        'spamcorptastic.com',
        'spamex.com',
        'spamfree24.com',
        'spamfree24.eu',
        'spamfree24.de',
        'spamfree24.info',
        'spemfree24.net',
        'spamfree24.org',
        'spamgourmet.com',
        'spamhole.com',
        'spamla.com',
        'spammotel.com',
        'spam.la',
        'tempemail.net',
        'tempinbox.com',
        'trashymail.com',
        'wh4f.org',
        'yopmail.com'
    );
 
    // Check the format with the CodeIgniter function
    if (valid_email($address) === false)
    {
        return false;
    }
 
    // Check the illegal hosts
    foreach ($illegalHosts as &$illegalHost)
    {
        if (stripos($address, $illegalHost, strpos($address, '@')))
        {
            return false;
        }
    }
 
    // The address is valid
    return true;
}

Wanneer je nu op je website een e-mail adres wil controleren, kan je gewoon deze functie gebruiken als volgt:

is_valid_email('massimo@finalfrag.be'); // Zal true teruggeven
is_valid_email('piet@mailinator.com'); // Zal false teruggeven

Aangezien we ons bestand MY_email_helper.php hebben genoemd, wordt dit bestand automatisch geladen door CodeIgniter wanneer je de Email helper inlaad. Om deze functie te kunnen gebruiken hoef je dus enkel het volgende te doen:

$this->load->helper('email');

Nog meer hosts

Indien je zelf nog meer hosts weet die wegwerp-e-mail adressen aanbieden, mag je mij gerust een lijstje bezorgen per e-mail, dan pas ik de functie aan. Ik hoop dat jullie er iets aan hebben.

Zou het niet veel leuker zijn als je automatisch een e-mail kon ontvangen wanneer er iets fout gaat op een van je projecten. Wanneer dan de mensen naar je toe komen met hun probleem kan je trots zeggen: ‘ja, dat heb ik gisteren al opgelost, dat werkt terug zoals het hoort’. Mits een kleine extensie te schrijven voor het CodeIgniter framework is dit zo simpel als 1, 2, 3. Of zelfs nog makkelijker, want je moet helemaal niet kunnen tellen.

My_Log

Om deze extensie te kunnen schrijven, moeten we eerst op zoek naar de library die instaat voor het opvangen van alle foutmeldingen. In het CodeIgniter framework is dit de Log klasse. We maken een nieuw bestand aan in de map system/application/libraries/ en noemen dit MY_Log.php. In dit bestand zetten we het volgende:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

<?php
class MY_Log extends CI_Log
{
    var $levels = array('ERROR' => '1', 'DEBUG' => '2',  'INFO' => '3', 'ALL' => '4');
 
    function write_log($level = 'error', $msg, $php_error = FALSE)
    {
        $config =& get_config();
 
        if ($config['write_log'] === TRUE)
        {
            parent::write_log($level, $msg, $php_error);
        }
 
        $level = strtoupper($level);
 
        if ($config['email_log'] === TRUE && isset($this->levels[$level]) && $this->levels[$level] <= $config['log_threshold'])
        {
            $report = "<html><head><title>" . $config['log_email_title'] . "</title></head><body>";
            $report .= "<strong>Requested URI:</strong><br />http://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] . "<br /><br />";
 
            if (isset($_SERVER['HTTP_REFERER'])) {
                $report .= "Referer:</strong><br />" . $_SERVER['HTTP_REFERER'] . "<br /><br />";
            }
 
            $report .= "<strong>User host:</strong><br />" . gethostbyaddr($_SERVER['REMOTE_ADDR']) . "<br /><br />";
            $report .= "<strong>Date:</strong><br />" . date('d-m-Y H:i:s') . "<br /><br />";
            $report .= "<strong>Error:</strong><br />" . $msg . "<br /><br />";
            $report .= "</body></html>";
 
            $headers  = 'MIME-Version: 1.0' . "\r\n";
            $headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
            $headers .= 'From: ' . $config['log_email_from'] . "\r\n";
 
            mail($config['log_email_address'], $config['log_email_title'], $report, $headers);
        }
    }
}

Als je de broncode goed naleest zie je dat we enkele variabelen uit het config bestand van CodeIgniter uitlezen. We kunnen uiteraard niets uitlezen dat niet bestaat. Het is dan ook nodig de variabelen in kwestie aan te maken in het config bestand.

De fervente CodeIgniter gebruikers, waaronder ikzelf, willen uiteraard de Email klasse van CI gebruiken om de e-mail te versturen. Ik heb dit proberen te implementeren, maar dat is me niet gelukt. Om in een library aan het CI object te komen, moet je de get_instance() functie gebruiken. Deze functie wordt gedeclareerd nadat de Log klasse wordt geladen. Daardoor is het dus niet mogelijk op het CI object te verkrijgen in MY_Log, en is het dus ook niet mogelijk om de Email klasse te laden. Jammer, maar gelukkig doet de mail() functie van PHP het ook helemaal goed.

Het config bestand

In config.php (te vinden in system/application/config/) moeten de volgende items worden toegevoegd:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// Vanaf welk niveau moeten er fouten gerapporteerd worden (deze variabele staat al in het config bestand)
$config['log_threshold'] = 1;
 
// True als je wil dat er effectief naar het logbestand geschreven wordt
$config['write_log'] = FALSE;
 
// True als je een e-mail wil ontvangen wanneer er een fout optreedt
$config['email_log'] = TRUE;
 
// Het e-mail adres naar welk de e-mail wordt verstuurd
$config['log_email_address'] = 'massimo@finalfrag.be';
 
// Het onderwerp van het e-mail bericht
$config['log_email_title'] = 'Project x foutmelding';
 
// De afzender van de e-mail
$config['log_email_from'] = 'Project x';

Het resultaat

Elke keer wanneer er nu een foutmelding op de website komt, bijvoorbeeld wanneer een PHP variabele niet kan worden gevonden of wanneer er een pagina niet werd gevonden, krijgen we een e-mail waarin meer info staat over de foutmelding. Een foutmelding ziet er als volgt uit:

1
2
3
4
5
6
7
8
9
10
11
12

REQUESTED URI:
http://www.finalfrag.be/blog/
 
USER HOST:
213.219.133.127.adsl.dyn.edpnet.net
 
DATE:
06-05-2009 19:37:29
 
ERROR:
Severity: Warning --> Cannot modify header information - headers already sent by (output started at /home/finalfrag.be/public_html/libraries/Exceptions.php:164)
/home/finalfrag.be/public_html/libraries/Smarty.php 99

Uit deze voorbeeldfoutmelding kunnen we afleiden dat er op http://www.finalfrag.be/blog/ al iets op het scherm getoond wordt voordat de sessie geladen wordt door CodeIgniter. Ook krijgen we meer informatie over de gebruiker die de foutmelding heeft veroorzaakt en wanneer.

Ik hoop dat deze blogpost je weer wat verder helpt in de mooie wereld van webontwikkeling. Vragen of opmerkingen passen zoals gewoonlijk mooi in het vakje hieronder.

Deze tag is optioneel voor de parser die PHP verwerkt. Dit wil zeggen dat de volgende 2 scripts exact hetzelfde doen:

1
2
3
4

<?php
$tekst = 'Ik ben een voorbeeldtekst.';
echo $tekst;
?>

1
2
3

<?php
$tekst = 'Ik ben een voorbeeldtekst.';
echo $tekst;

En dan?

Op zich is dit geen geweldig nieuws, maar als je even verder nadenkt kan de sluittag weglaten je wel veel frustratie helpen voorkomen. Wanneer je bijvoorbeeld de sluittag wel typt en er per ongeluk nog een spatie achter zet, zal deze niet verwerkt worden door de PHP parser, maar gewoon als HTML aanzien worden. Dat zal op zijn beurt resulteren in een extra spatie op de genereerde pagina, wat in sommige gevallen kan leiden tot onverwachte fouten in de layout van je pagina’s.

Een spatie of een witregel op het einde van een bestand kan ook gegeneerd worden door de FTP applicatie die je gebruikt. Wanneer de error_reporting functie van PHP wordt gebruikt om fouten niet te tonen aan de eindgebruiker, kan deze spatie het tonen van een lege pagina tot gevolg hebben.

Het is zo dat de PHP parser sowieso stopt met het verwerken van een bepaald script wanneer het einde van dat bestand bereikt is. De parser doet dit helemaal op het einde van het bestand. Zo ben je er zeker van dat er niets meer na deze ’sluittag’ komt te staan.

Een mogelijk probleem

Soms kan het gebeuren dat er door een fout in je IDE of een verbinding die plots wegvalt maar een deel van je bestand wordt ingeladen. Door de sluittag weg te laten, kan je niet meer zien of het einde van het geopende bestand effectief het einde is van het bestand in kwestie. Om dit te voorkomen kan je altijd een regel commentaar op het einde van elk bestand zetten, bijvoorbeeld:

1
2
3
4
5

<?php
$tekst = 'Ik ben een voorbeeldtekst.';
echo $tekst;
 
/* EOF: voorbeeld.php */

Voila, zo heb je weer iets bijgeleerd over PHP. Laat gerust een reactie achter als je een vraag of een opmerking hebt.

Als fervente PHPer kon ik me natuurlijk niet inhouden om die uitbreidingen zelf ook eens te maken, al was het maar om de uitdaging aan te gaan. Bovendien heb ik van elke mensen al vragen gehad over hoe ze eraan moeten beginnen. Daarom heb ik besloten om dit vervolg te schrijven en een woordje uitleg te geven bij deze uitbreidingen.

Meerdimensionale arrays

De uitbreiding die ik heb geschreven ziet er als volgt uit:

function line ($keys, $vals = array())
{
    $return = '';
 
    if (count($vals) === 0)
    {
        // Er zijn geen waardes opgegeven
        // We gebruiken dan een echo
        $return .= 'return $this->language';
    }
    else
    {
        // Er zijn wel waardes opgegeven
        // We gebruiken dan een sprintf
        $return .= 'return sprintf($this->language';
    }
 
    // De volledige key samenstellen aan de hand van de array
    // Dit wordt iets als ['error']['username']['minLength']
    if (is_array($keys) === true)
    {
        // Als $keys een array is halen we alle delen op
        foreach ($keys as &$key)
        {
            $return .= '[\'' . $key . '\']';
        }
    }
    else
    {
        // Anders is er maar één key meegegeven aan de functie
        $return .= '[\'' . $keys . '\']';
    }
 
    // Daarna doen we ongeveer hetzelfde voor de waardes
    // Als die er zijn, maken we gebruik van een sprintf (zie bovenaan)
    if (is_array($vals) === true)
    {
        // Als er een array werd meegegeven, doorlopen we deze
        foreach ($vals as &$val)
        {
            $return .= ', \'' . $val . '\'';
        }
    }
    else
    {
        // Anders is er maar één waarde
        $return .= ', \'' . $vals . '\'';
    }
 
    // Op het einde nog even de functie (echo of sprint) juist afsluiten
    if (count($vals) === 0)
    {
        $return .= ';';
    }
    else
    {
        $return .= ');';
    }
 
    // En het geheel teruggeven
    return eval($return);
}

Deze functie staat uiteraard in het MY_Language.php bestand. Aangezien de naam van de functie die hierboven staat ‘line’ is, zal de functie van CI_Language overschreven worden. Dit is echter geen probleem, omdat onze eigen functie dezelfde en meer functionaliteiten biedt dan de originele. Om dit even te demonstreren, maak ik gebruik van dutch_lang.php in de map language/dutch/:

<?php
$lang['een'] = 'Dit is een voorbeeld';
$lang['twee'] = 'Dit is voorbeeld %s';
$lang['drie']['a'] = 'Dit is voorbeeld a';
$lang['drie']['b'] = 'Dit is voorbeeld b met als gegevens: %s en %s';

De code om dit te testen is redelijk makkelijk te schrijven. Dit zijn enkele van de tests, maar er zijn er natuurlijk nog meer mogelijk. Zo is er bijvoorbeeld geen test voorzien voor een array van keys met één waarde.

<?php
class Home extends Controller
{
    function index()
    {
        $this->lang->load('dutch', 'dutch');
 
        echo $this->lang->line(
            'een'
        );
 
        echo '<br />';
 
        echo $this->lang->line(
            'twee',
            2
        );
 
        echo '<br />';
 
        echo $this->lang->line(
            array('drie', 'a')
        );
 
        echo '<br />';
 
        echo $this->lang->line(
            array('drie', 'b'),
            array('1', '2')
        );
    }
}

Bovenstaande code geeft als resultaat:

Dit is een voorbeeld
Dit is voorbeeld 2
Dit is voorbeeld a
Dit is voorbeeld b met als gegevens: 1 en 2

Dat werkt allemaal heel mooi, maar er is nog een tweede uitdaging.

Alle language file rechtstreeks in de language/ map

Nu staat alle taalbestanden nog in mappen. Zo staat dutch_lang.php in language/dutch/ en english_lang.php in language/english/. Dit heeft als gevolg dat we steeds deze map moeten meegeven met de $this->lang->load functie.

De enige manier om dit op te lossen is om de load functie van CI_Language te overschrijven. Dit kan door de load functie te kopiëren vanuit Language.php (te vinden in system/libraries/) en te plakken in MY_Language.php. Het enige dat je nu nog moet doen is een stuk code in commentaar zetten, of volledig te verwijderen als je dat liever doet. Het gaat om de if structuur die begint op regel 8 van de functie:

if ($idiom == '')
{
    $CI =& get_instance();
    $deft_lang = $CI->config->item('language');
    $idiom = ($deft_lang == '') ? 'english' : $deft_lang;
}

Wanneer je bovenstaande code in commentaar zet kan je in je controllers

$this->lang->load('dutch', 'dutch');

vervangen door

$this->lang->load('dutch');

Je moet natuurlijk ook dutch_lang.php verplaatsen van language/dutch/ naar language/.

En klaar is kees

Voila, beide ideeën die ik en de vorige post voorstelde zijn bij deze gemaakt. Als er nog vrage zijn, je weet ondertussen wel waar je ze kan zetten…

De situatie nu

Wanneer je CodeIgniter download van de website en upload naar je eigen webspace, ben je gebonden aan de 1-dimensionale arrays in language files. Concreet houdt dit in dat je je vertalingen niet kan bundelen. Een kleine language file ziet er bijvoorbeeld zo uit:

1
2
3
4

<?php
$lang['usernameMinLength'] = 'Je gebruikersnaam is niet lang genoeg.';
$lang['usernameMaxLength'] = 'Je gebruikersnaam is te lang.';
$lang['usernameInvalid'] = 'Je gebruikersnaam bevat ongeldige tekens.';

Voor simpele applicaties is dit goed genoeg, maar wanneer je veel teksten hebt die moeten vertaald worden is dit onbegonnen werk. Denk maar eens aan het feit dat je teksten in categorieën wil indelen. Zo wil ik bijvoorbeeld alle foutmeldingen, alle waarschuwingen en alle informatieteksten bij elkaar groeperen. De handleiding van CodeIgniter raad in dat geval het volgende aan:

It’s a good practice to use a common prefix for all messages in a given file to avoid collisions with similarly named items in other files. For example, if you are creating error messages you might prefix them with error_

Dit is weer een leuke oplossing, maar ook niet goed genoeg voor hele grote websites. Een andere oplossing zou zijn om meerdere language files te maken per taal. Zo kan je bijvoorbeeld voor nederlands 3 bestanden aanmaken: nl_foutmeldingen_lang.php, nl_waarschuwingen_lang.php en nl_informatie_lang.php. Ook weer een tof alternatief, maar een oplossing die bijna niet onderhouden is.

Het mag dus wel duidelijk zijn dat er nood is aan een beter oplossing, en die gaan we nu maken.

Hoe het zou moeten

De ideale oplossing zou één bestand per taal zijn, waarin een meerdimensionale array staat die de teksten in categorieën onderverdeeld. Een klein voorbeeldje, in nl_lang.php staat het volgende:

1
2
3
4
5
6
7
8
9

<?php
$lang['error']['usernameMinLength'] = 'Je gebruikersnaam is niet lang genoeg.';
$lang['error']['usernameMaxLength'] = 'Je gebruikersnaam is te lang.';
$lang['error']['usernameInvalid'] = 'Je gebruikersnaam bevat ongeldige tekens.';
 
$lang['warning']['passwordMinLength'] = 'Je wachtwoord is niet lang genoeg.';
$lang['warning']['passwordMinLength'] = 'Je gebruikersnaam is te lang.';
 
$lang['info']['welcome'] = 'Welkom op mijn blog';

Het spreekt voor zich dat in en_lang.php exact hetzelfde staat, maar dan in het engels. Voor de_lang.php, fr_lang.php, etc. is dit uiteraard ook zo. Zoals je kan zien in bovenstaande code, zijn de teksten gegroepeerd. Een array voor alle foutmeldingen, een voor alle waarschuwingen en een voor alle informatieteksten.

Er rest nu nog één probleem. CodeIgniter kan standaard niet om met meerdimensionale arrays in de language files. We moeten dus de language class uitbreiden met een functie die de array wel kan uitlezen.

De oplossing

Wie al een beetje ervaring heeft met CodeIgniter, weet meteen dat voor problemen als deze de ideale oplossing al aanwezig is. Je kan in CI namelijk heel makkelijk bestaande klassen (of libraries in dit geval) overschrijven. Eerst maken we een nieuw bestand aan in /system/application/libraries en we noemen dit MY_Language.php. De inhoud van dit bestand is als volgt:

1
2
3
4
5
6
7
8
9

<?php
class MY_Language extends CI_Language
{
    function line2($array, $line)
    {
        $line = ($line === '' OR $array === '' OR ! isset($this->language[$array][$line])) ? FALSE : $this->language[$array][$line];
        return $line;
    }
}

Aangezien de naam van het bestand MY_ + een_bestaande_klasse is, zal deze automatisch worden geladen door CodeIgniter en moeten we ons hier verder geen zorgen meer om maken. We hebben nu een functie toegevoegd aan de Language klasse van CI, namelijk line2. We geven 2 parameters mee aan deze functie, de array waarin we willen zoeken en de regel die we willen ophalen. Ik heb voor dit voorbeeld deze functie line2 genoemd. In een realistische omgeving zou ik deze functie een kortere naam geven, bijvoorbeeld l2. Zo besparen we onszelf elke keer we deze functie aanroepen weer een beetje werk.

De functie gebruiken kan nu als volgt:

1
2
3
4
5
6
7
8
9
10
11
12

<?php
class Home extends Controller
{
    function index()
    {
        // Eerst laden we het bestand in ('mapnaam', 'bestandsnaam zonder _lang')
        $this->lang->load('dutch', 'dutch');
 
        // Daarna printen we de regel 'usernameMinLength' uit de array 'error'
        echo $this->lang->line2('error', 'usernameMinLength');
    }
}

Wanneer we dan een bezoekje brengen aan home/index krijgen we het volgende resultaat:

1

Je gebruikersnaam is niet lang genoeg.

Exact wat we wilden bereiken. Missie geslaagd.

Noot

De code hierboven is bedoeld als voorbeeld en kan nog heel wat beter geschreven worden. Nu moeten we bijvoorbeeld nog steeds als onze language files in een aparte map plaatsen. dutch_lang.php in language/dutch/, english_lang.php in language/english/. Volgens de zelfde manier als hierboven kan de load functie van de Language klasse overschreven worden zodat we de language files rechtstreeks in language/ mogen plaatsen.

Ook kan de code hierboven worden uitgebreid om ondersteuning te bieden voor meerdimensionale array zodat je nog meer vrijheid krijgt. Beide ideeën laat ik als oefening voor de lezer

Wat is een tagcloud?

Een tagcloud is een verzameling van kernwoorden op een blog. Door het grote succes van tagclouds, worden ze ondertussen ook voor andere doeleinden gebruikt.In mijn stageproject gebruik ik een ‘product-cloud’, een tagcloud die de producten bevat waarover de meeste reviews werden geschreven.

Een tagcloud kan je makkelijk herkennen doordat er grote en kleine woorden instaan. De grote woorden zijn belangrijker en worden dus groter getoond zodat ze beter opvallen. Een voorbeeld van een tagcloud kan je op deze blog in het rechter menu zien. Kernwoorden waarover ik het dikwijls heb in mijn posts worden groter getoond, terwijl minder vaak voorkomende tags kleiner worden afgebeeld.

Een tagcloud maken

Het makkelijkste deel van een tagcloud is de CSS. In dit voorbeeld zullen we gebruik maken van vier verschillende groottes. De CSS bevat dus vier klassen, één voor elke grootte.

1
2
3
4

.size1 { font-size: 12px; }
.size2 { font-size: 24px; }
.size3 { font-size: 36px; }
.size4 { font-size: 48px; }

Om dit voorbeeld zo simpel mogelijk te houden, zal ik de tags niet ophalen uit een database, maar zelf een array declareren. In een realistische situatie moet dit uiteraard wel gebeuren. Om een tagcloud samen te stellen hebben we nood aan twee gegevens. In mijn stageproject waren dit de naam van een product en het aantal reviews dat erover zijn geschreven. De naamgeving hangt af van het doel van de cloud. Om dit voorbeeld zo duidelijk mogelijk te maken, zullen we gegevens ‘naam’ en ‘aantal’ noemen. De gebruikte array ziet er dus als volgt uit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

$tags = array (
    array (
        'naam' => 'Massimo',
        'aantal' => 5
    ),
    array (
        'naam' => 'Mertens',
        'aantal' => 9
    ),
    array (
        'naam' => 'FinalFrag',
        'aantal' => 2
    ),
    array (
        'naam' => 'Website',
        'aantal' => 7
    ),
    array (
        'naam' => 'Blog',
        'aantal' => 1
    ),
    array (
        'naam' => 'Tagcloud',
        'aantal' => 8
    )
);

Uit deze array kunnen we al afleiden dat ‘Tagcloud’ en ‘Mertens’ het grootst gaan getoond worden met respectievelijk 8 en 9 als aantal. ‘Blog’ en ‘FinalFrag’ zullen klein worden getoond omdat ze maar 1 en 2 als aantal hebben.

De verwerking van deze array gaat in mensentaal als volgt. Eerst bepalen we het grootste en het kleinste aantal. Zo komen we te weten welke klein moeten getoond worden en welke groot. Uiteraard moeten ook de tussenliggende tags onderverdeeld worden in de vier CSS klassen die we eerder al hebben aangemaakt. In PHP ziet dit er als volgt uit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

// Eerst initialiseren we de variabelen
// die het kleinste en grootste aantal bevatten
$min = null;
$max = null;
 
// Daarna overlopen we de array (by reference)
// om het kleinste en grootste aantal op te slaan
foreach ($tags as &$tag)
{
    // Indien er nog geen kleinste waarde is opgeslagen,
    // is de eerste de kleinste
    if ($min === null)
    {
        $min = $tag['aantal'];
    }
 
    // Hetzelfde voor de maximumwaarde
    if ($max === null)
    {
        $max = $tag['aantal'];
    }
 
    // Als het huidige aantal kleiner is dan de opgeslagen
    // minimumwaarde is dit de nieuwe minimumwaarde
    if ($tag['aantal'] < $min)
    {
        $min = $tag['aantal'];
    }
 
    // En weer hetzelfde voor de maximumwaarde
    if ($tag['aantal'] > $max)
    {
        $max = $tag['aantal'];
    }
}
 
// De volgende stap is om de tags te verdelen over de vier klassen
// Eerst moeten we de range bepalen waarin de tags zich bevinden
$range = $max - $min;
 
// Daarna bepalen we de grootte van elk van de vier delen
$partSize = $range / 4;
 
// Aan de hand van de grootte van elk deel,
// kunnen we de maximumwaarde van elk deel bepalen
$part1Max = $min + $partSize;
$part2Max = $min + 2 * $partSize;
$part3Max = $min + 3 * $partSize;
$part4Max = $max;

Wanneer we bovenstaande code uitvoeren op de array die we hoger hebben aangemaakt, krijgen we volgend resultaat:

1
2
3
4
5
6
7
8
9
10

$min = 1
$max = 9
 
$range = 8 (9 – 1)
$partSize = 2 (8 / 4)
 
$part1Max = 3 (1 + 2)
$part2Max = 5 (1 + 2 * 2)
$part3Max = 7 (1 + 3 * 2)
$part4Max = 9 ($max)

Het enige dat ons nu nog rest is om de array opnieuw te overlopen en de tags te verdelen over de aangemaakt klassen. Dit is makkelijk te realiseren als volgt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

foreach ($tags as &$tag)
{
    if ($tag['aantal'] <= $part1Max)
    {
        // Het aantal ligt tussen 1 en 3
        $tag['klasse'] = 1;
    }
    else if ($tag['aantal'] <= $part2Max)
    {
        // Het aantal ligt tussen 3 en 5
        $tag['klasse'] = 2;
    }
    else if ($tag['aantal'] <= $part3Max)
    {
        // Het aantal ligt tussen 5 en 7
        $tag['klasse'] = 3;
    }
    else
    {
        // Het aantal ligt tussen 7 en 9
        $tag['klasse'] = 4;
    }
}

Nu is de array die we in het begin aangemaakt hebben uitgebreid met een extra veld, namelijk ‘klasse’. In deze variabele staat de CSS klasse waartoe die bepaalde tag hoort. Met behulp van Smarty (onze favoriete template engine) kunnen we deze array makkelijk omzetten in HTML zodat deze op de website kan getoond worden. Allereerst moeten we de array doorgeven aan Smarty en de juiste template aanroepen:

1
2
3
4
5

// Eerst geven we de tags array door aan Smarty
$smarty->assign('tags', $tags);
 
// En daarna tonen we de tagcloud template
$smarty->display('tagcloud.tpl');

Deze template ziet er als volgt uit:

1
2
3
4
5

<div id="tagcloud">
    {foreach from=$tags item=tag}
        <span class="size{$tag.klasse}">{$tag.naam}</span>
    {/foreach}
</div>

Het resultaat

Als je alle code die hierboven staat zou samenvoegen en uitvoeren, krijg je een 'mooie' tagcloud. Uiteraard kan dit met behulp van de juiste CSS regels veel beter gemaakt worden, maar daar gaat deze post niet over. Bepaalde stukken PHP code kunnen op een betere manier geschreven worden, bijvoorbeeld het deel dat beslist in welk deel een bepaalde tag hoort. In een productieomgeving moet dit gedaan worden met een switch. Het is dan ook niet aangeraden de code gewoon over te nemen wanneer je zelf een tagcloud wil maken. Er zijn op het internet heel wat voorbeelden te vinden van tagclouds met een mooie stijling.