Een test die altijd mogelijk wat inzicht kan opleveren is simpelweg de foutmelding "TLS not available: connect failed: error:140770FC:SSL" in Ome Goegel gooien. Als ik de eerste twee resultaten mag geloven ligt dit waarschijnlijk aan de verzendkant een andere partij (te oude client die een niet langer ondersteund SSL-protocol (vanwege security) probeert te gebruiken, of andere servers die dit doen?).

Als dit het geval is dan kun jij dit niet direct oplossen maar kun je enkel de klant verzoeken een modernere mailclient te gebruiken... of ergens iets in de communicatie tussen mailservers aanpassen? Het wordt volgens mij niet aangeraden om de oude protocollen weer retroactief te gaan ondersteunen.

Zo was in een van de resultaten een smtp daemon gepatched om deze oude protocollen weer te ondersteunen, al ontgaat mij de logica daarvan een beetje:

Citaat

The problem is that apparently, some servers try to use SSLv3 to send their emails. This is not a bad thing as it's always much better than clear text. We want to forbid users to authenticate using weak SSLv2/v3 but it's OK for external server to use those.

Waarom is het wel OK voor externe servers? Of misschien gaat het meer over authenticeren versus verzenden, geen idee.

Misschien inmiddels alweer achterhaald, maar wil wel zeggen dat er ergens in de pijplijn ontzettend oud (of ongeldig, zie hieronder) spul wordt gebruikt?

EDIT: mogelijk gerelateerd: er was (zeer) recent iets te doen met LetsEncrypt certificaten. Weet niet hoe lang het probleem al speelt?

En inderdaad, hoe probeer je dingen je database in te duwen? Het uploaden van een mysql-bestand van honderden megabytes via HTTP in PHPMyAdmin ofzo gaat doorgaans niet zo soepel.

Het is waarschijnlijk het makkelijkste om dit "via de prompt" te doen, als je hier toegang toe hebt.

Of je Googled eens op de errorcode.

Gebruik je toevallig een tool om deze SVG te ontwerpen/animeren?

Citaat van tkzone

Het werkt helaas niet, blijft nog steeds de bericht versturen in de taal van verzender.

"Het werkt niet". WAT werkt er niet? Het resultaat is duidelijk, maar wat is de oorzaak hiervan?

Misschien is het ook handig om een stramien voor ontwikkeling en debugging te hebben?

Bijvoorbeeld een "flag" voor een debug/developer modus. Gooi dit ergens in een config:

<?php
define('DEBUG_MODE', true);
?>

De waarde (true of false) zou je van diverse dingen af kunnen laten hangen zoals host, user, of wat dan ook.

En zet vervolgens aan het begin van je code het volgende:

<?php
if (DEBUG_MODE) {
    // developer mode
    error_reporting(E_ALL);
    ini_set('display_startup_errors', true);
    // dump errors to screen
    ini_set('display_errors', 'stdout');
} else {
    // live mode
    error_reporting(E_ALL);
    ini_set('display_startup_errors', false);
    ini_set('display_errors', false);
    // write errors to log
    ini_set('log_errors', true);
    ini_set('error_log', '/path/to/logs/error.log');
}
?>

Zo heb je één schakelaar (DEBUG_MODE) die bepaalt wat er met je errors gebeurt.

Naarmate je code langer wordt moet je echt meer en meer gaan nadenken over een goede architectuur. Dit vormt het fundament van je applicatie. Als dit fundament al gammel is dan stort het geheel op den duur in als je alleen maar dingen blijft bijmetselen.

Overigens, de beste manier om te leren programmeren is de fouten bestuderen en vervolgens uitzoeken hoe dingen in elkaar zitten. Anders blijf je tegen een "black box" aanturen zonder dat je begrijpt wat er gebeurt. Maar je moet dan om te beginnen van je code signalen ontvangen (en vervolgens kunnen interpreteren) over wat er misgaat. Hiervoor zijn de bovenstaande settings.

NB: een include genereert geen foutmelding, enkel een "warning". Het kan dus best zo zijn dat jouw (include) paden niet goed zijn, niet goed staan ingesteld, of beide.

Het bovenstaande werkt waarschijnlijk prima, maar de vraag is of je zo alle taalgerelateerde zaken wilt aanvliegen. Als je een volledig meertalige site / applicatie wilt maken is het misschien handiger/verstandiger om een wat generiekere aanpak te hanteren.

Mja als $lang de file is die voor de huidige gebruiker is ingeladen dan is dat niet noodzakelijkerwijs de taal van de ontvanger?
Je zult dus -op zijn minst- (tijdelijk) naar een andere taal moeten schakelen. En dat zou het laden van een nieuwe set vertalingen moeten triggeren ofzo, of je moet daar op een of andere manier de beschikking over hebben.

Snap je op een functioneel niveau wat er moet gebeuren? Verwoord het eens voor jezelf. Dit is dan meteen een specificatie van de code die je moet schrijven om dit te bereiken. Hoe je dat dan precies doet maakt in beginsel niet zoveel uit, maar ik zou je wel aanraden om hier op den duur een soort van generieke oplossing voor te verzinnen, en niet al deze taalgerelateerde problemen ad hoc op te lossen anders wordt je code in een mum van tijd een (nog) grote(re) brei.

Overigens:

$tmp=$sql->fetch_assoc();
$taalOntvanger=$tmp->lang;

Ga eens goed na wat je hier doet? Je haalt $tmp op als een associatief array. $tmp is dus een array, geen object. $tmp vervolgens behandelen als een object ($tmp->lang) gaat dus sowieso niet werken.

Het is waarschijnlijk niet zo simpel als een kwestie van de taal checken. Als [messages] een tabel is waarin standaard (systeem)berichten staan opgeslagen dan ligt in principe de inhoud, op een aantal variabelen na, vast.

Het probleem van "taalafhankelijkheid" blijft bij de bovenstaande opzet ook bestaan. Immers, het bericht wordt opgeslagen in een specifieke taal. Wat als de gebruiker nu overstapt van nederlands naar engels of andersom? De berichten staan dan nog steeds in de eerder geselecteerde taal?

Taal is ook een beetje weerbarstig. Lang niet altijd hebben de variabele onderdelen dezelfde volgorde. De "placeholders" voor de variabele delen van zo'n bericht staan dus mogelijk op verschillende plaatsen in verschillende talen. Een volgorde staat dus niet op voorhand vast.

Wat ik waarschijnlijk zou doen, als je het goed wilt aanpakken, is taalafhankelijke templates maken die horen bij eenzelfde bericht. Vervolgens heb je een lijst van placeholders/variabelen met specifieke waarden die je hier in kunt plakken. Dit zijn dan die $breakout, $breakout1, $breakout2 etc.. Deze zou ik dan wel fatsoenlijke namen geven die identificeren waar ze voor staan.

In je messages tabel zou je dan bijvoorbeeld (ben hier niet helemaal over uit) kunnen refereren aan het bericht en de variabelen sla je dan bijvoorbeeld geserialiseerd op. En afhankelijk van de dan geselecteerde taal geef je het bericht weer wat hoort bij die taal. Eventueel zou je dat bericht dan ook kunnen cachen in de juiste taal ofzo, zodat deze niet elke keer helemaal on-the-fly opgebouwd hoeft te worden.

Mijn algemene advies is eigenlijk: denk wat meer/beter na over hoe je omgaat met meertaligheid in een applicatie.

Je bent nu namelijk al een tabel aan het gebruiken/vullen (en waarschijnlijk zijn er meer van dit soort situaties) en nu merk je dat de schoen niet (meer) past. Dat is dan een indicatie dat je terug moet naar de tekentafel en een slimmere aanpak zou moeten verzinnen. En liefst eentje die meteen al dit soort taalgerelateerde problemen plat slaat.

Hoort dit niet op een marktplaats subforum thuis?

Waarom zou je trouwens het resultaat willen mailen?

Dan zijn er waarschijnlijk een aantal verschillen tussen een (platte) vragenlijst, een enquete (waar het antwoord op een vraag mogelijk het verdere verloop van de enquete bepaalt), en een soort van poll waar je in het laatste puntje op doelt? Of mogelijk zijn dit statistieken van vragenlijsten/enquetes/polls? Maar dat is dus meer statistiek-functionaliteit. Daarbij, het lijkt mij lang niet altijd de bedoeling dat de resultaten publiekelijk in te zien zijn in verband met privacy.

Ook zie ik niet helemaal hoe je dit zonder admin doet? Je moet dit alles toch op een of andere manier vormgeven: de vragen opzetten, de antwoorden definiëren, eventuele routes door de lijst, en nog allerlei andere instellingen zoals publiek/prive, resultaten publiek/prive, mogelijk extra statistiek (denk aan een soort van kennissysteem om op grond hiervan beslissingen te nemen). En hoe regel je de toegang? Dan heb je waarschijnlijk maillijsten met toegangscodes, denk ook aan de levensduur van een enquete (wanneer gaat deze open, wanneer sluit deze?).

Dus je hebt sowieso een (mogelijk zeer uitgebreide) backend voor het bouwen en beheren van de enquetes en eventuele rapportages en ledenbeheer, en een frontend voor het weergeven van dit alles.

et cetera, et cetera, et cetera.

Dit is alles behalve "simpel" of "basic" en ik zou het eenieder afraden om dit in een enkel "script" te vangen. Dit is een complete applicatie. Daarbij zou dit uiteraard zeer nauwkeurig+veilig geprogrammeerd moeten worden. Vraag is ook of je dit wilt integreren in iets anders.

Maareh, waar heb je het voor nodig? En er zijn genoeg (gratis?) sites die je kunt gebruiken om een poll uit te voeren, dus waarom zou je dit zelf allemaal willen bouwen?

De vraag is ook, waarom zou je dit willen? Als je iets probeert te includen wil je het toch ook gaan gebruiken? En blijkbaar kun je niet verder op het moment dat je dit bestand mist? Dus wat dat betreft zou een require, of wellicht beter, een require_once meer op zijn plaats zijn? Ik zou niet aansturen op een ontwerp waarin je allerlei meldingen over fouten faciliteert of fouten op deze manier probeert af te vangen. Laat dingen die fout gaan gewoon fout gaan.*

En dan nog het volgende: voor een ontwikkelomgeving is het handig dat je gretig bent met foutmeldingen en andere mededelingen als zoals waarschuwingen (warnings) en uitzonderingen (exceptions), dit is handig voor het vroegtijdig detecteren en oplossen van (potentiële) bugs, maar een live omgeving zou hier eigenlijk nooit (op deze manier, publiekelijk) mededelingen over moeten doen. Dit omdat je hiermee potentieel zwakheden in je systeem blootgeeft.

Je zou foutmeldingen etc. wel intern moeten loggen en af en toe je errorlog eens door moeten spitten om na te gaan of er (ernstige) dingen foutgaan, maar naar buiten toe zou je eigenlijk alleen een generieke "500 Internal Server Error" pagina moeten retourneren op het moment dat er iets fout gaat, zonder enige details over wat er onder de motorkap fout ging. En als je website dan zo op zijn bek gaat, dan zou je dit als "kritieke" error apart kunnen loggen.

Een controle met file_exists() is in dit geval geen oplossing (zie EDIT #2 hieronder), en realiseer je ook dat dit een van de "duurdere" operaties is. Ik zou gewoon wegsturen van een ontwerp waarbij het onzeker is of bestanden wel bestaan... Creëer een zodanig stramien dat dit geen twistpunt is, en ga er vervolgens vanuit dat de benodigde bestanden gewoon aanwezig zijn.

* Zoals in de voorlaatste paragraaf aangehaald: een soort van algemeen vangnet (generieke foutpagina) is mogelijk wel een goed idee.

EDIT: misschien is het ook handig om een toelichting te geven hoe jij dit denkt in te zetten in jouw website. Onder bepaalde omstandigheden is het namelijk ook mogelijk om externe bestanden te includen. En dat is nogal gevaarlijk.

EDIT 2: en blijkbaar inspecteert file_exists de include paden niet, dus dat gaat je ook niet echt helpen bij de bovenstaande foutmelding.

Of je ontwikkelt je website eerst op je eigen (locale) PC of laptop. Kost je niets. Download WAMP/XAMP of ga aan de slag met nginx en mysql.

"Live ontwikkelen" lijkt mij geen goed plan, vooral niet als je je skills (weer) aan het (op)poetsen bent.

Of je zou kunnen afspreken met de klant dat, op het moment dat je van Wordpress gebruik maakt, je enkel gebruik maakt van de beschikbare bouwstenen: dus de standaard functionaliteit en eventueel plugins/modules/etc van andere partijen die hun waarde hebben bewezen. Hier kunnen gewoon afspraken over worden gemaakt: kies je voor een pakket, dan krijg je enkel de prefab bouwstenen bij dat pakket en daar zal men het dus mee moeten doen. Hierbij doe je dus de concessie dat mogelijk niet alles 100% past bij de (specifieke functionaliteits)wensen van de klant.

Citaat van djordyh

een hele kleine CMS bouwen die eigenlijk puur en alleen pagina management bevat

Je begeeft je hiermee al heel snel op een hellend vlak:
- moeten de pagina's zoekmachinevriendelijk/responsive/etc zijn
- zitten er zaken als een sitemap, contactformulier of zoekfunctionaliteit in
- zijn het alleen teksten, of ook tabellen, afbeeldingen, filmpjes et cetera, dan moet je al gaan denken aan een WYSIWYG-editor en de opslag van media enzo

Je bent dan al snel het wiel opnieuw aan het uitvinden.

Ik denk dat het belangrijk is dat je eerst uitzoekt:
- wat men met een site wil kunnen doen (wat moet er functioneel allemaal mogelijk zijn)
- wie de doelgroep van de site is (wie bezoekt de site en met welk doel)

Het is nogal een verschil als de site bijvoorbeeld bedoeld is voor de promotie van, ik noem maar wat, een buurthuis, of dat deze bedoeld is om interne procedures van een bedrijf vast te leggen, in welk geval een soort van intranet-wiki misschien geschikter is. Dus over wat voor typen websites hebben we het?

Als de beheerders van de site niet technisch onderlegd zijn dan is Wordpress mogelijk een brug te ver, maar misschien bestaat er een simplistische view voor contentschrijvers?

Ik heb er al een hele tijd niet mee gewerkt en vond het zelf (als programmeur) ook niet fijn, maar een ding wat het (destijds) wel was was dat het simpel was: misschien is Joomla een optie?

En als je dan zelf iets breit dan zul je dit ook robuust moeten maken, dus bijvoorbeeld een versiebeheer hebben op het moment dat iemand per ongeluk een tekst "verwijdert" ofzo.

$login = $_GET['login'];
$userselect = $connection->query("SELECT * FROM `users` WHERE `login`='$login'");

Uh oh...

En ook:

Citaat van tigermaffia

ik heb een maffiagame zo goed als af alleen werkt de activation niet goed

???
Err, je zou verwachten dat je daarmee begint en dat als een zonnetje loopt?

Citaat van tigermaffia

ja bij de meeste wel en bij een paar niet

Waar rook is is vuur. Misschien heeft dat iets te maken met het feit dat je geen enkele waarde in queries lijkt te escapen. Dat is gewoon vragen om problemen.

Dit is prima mogelijk en wordt ook vrij veel gebruikt. Dit is een zogenaamde "dynamische select box" of hoe je het ook wilt noemen waar de opties van dropdown B afhankelijk zijn van de geselecteerde optie van een vorige dropdown A.

Dit is (wederom) niet echt een CI-specifiek probleem en kan in afzondering opgelost worden. Hierbij is het waarschijnlijk handig als je JavaScript gebruikt. Er zijn vele implementaties mogelijk.

Ook zijn dit soort vraagstukken zelden uniek dus je zou eens kunnen Googlen hoe, bij gebrek aan eigen inspiratie, anderen dit hebben aangepakt, en dat zou je dan als opzet voor een eigen oplossing kunnen gebruiken.

#1
Je zult op een of andere manier de informatie moeten doorgeven. Je doet bijvoorbeeld een pagerefresh waarin de naam (of beter, het id) van de chauffeur wordt doorgegeven op het moment dat je op een tab klikt, of je doet op het moment klikken een AJAX-call met info uit de geselecteerde tab. Dit is niet echt een codeigniter specifiek probleem denk ik?

#2
Als je je hebt aangemeld als chauffeur dan weet het systeem toch al dat jij chauffeur X bent? Ik zou zeggen, je hoeft dat niet eens aan het systeem te vertellen en dat hoef je ook niet in te vullen - dit staat immers al vast? Dit zou ik dus om te beginnen in het geheel niet opnemen in het formulier. Het lijkt mij ook zaak dat chauffeur X geen ritten kan invullen voor chauffeur Y? Ook dit lijkt mij niet echt een CI-specifiek probleem. Het hangt er natuurlijk vanaf hoe jij je systeem hebt ingericht met verschillende gebruikers/rollen et cetera.

Sidenotes:
$chauffeur->beschikbaar "Ja" / "Nee". Zijn er nog andere smaken? Zonee, dan hoef je dit ook niet op te nemen in je else-conditie. En het is wellicht beter om dit als een Boolse waarde (true of false, 0 of 1) op te slaan in plaats van een letterlijke (case sensitive?) string. Hoe je dit vervolgens weergeeft (bijvoorbeeld 0 als Nee en 1 als Ja) is een tweede en kan apart geregeld worden. Je code wordt dan ook een stuk korter en wat mij betreft ook een stuk intuïtiever:

if ($driver->available) {
    // driver available
} else {
    // driver unavailable
}

Hierbij loont het waarschijnlijk ook de moeite om je consequent te bedienen van dezelfde taal, bij voorkeur overal in het engels.

Wordt een chauffeur ook echt geïdentificeerd met zijn/haar (voor)naam? Dat lijkt mij geen goede zaak? Wat als er straks twee chauffeurs zijn die "Henk" heten? Lijkt mij beter om deze te identificeren met een uniek nummer of een unieke code.

Citaat van Twan025

duidelijk bewijzen aangeleverd

Aan wie, en wat hoopte je daarmee te bereiken? Het enige wat je op deze site -met enig fatsoen- kan doen is een reactie plaatsen op iemand zijn "muur", waarbij je aangeeft hoe je ervaringen waren. Dit kan anderen dan aanzetten om wel/geen zaken met zo iemand te doen. Dit "platvorm" is slechts een medium. Het staat zelfs in de disclaimer, misschien wel een puntje voor ICTScripters om akkoord met de regels expliciet op te nemen bij registratie, maar als je op deze site zit en hier gebruik van maakt dan zijn in zekere zin de regels van toepassing lijkt mij zo. Dus, helaas pindakaas?

Citaat van Twan025

Word niets mee gedaan.

Dan was het blijkbaar het verkeerde loket?

Als je zo stellig overtuigd bent van de rechtsgeldigheid van jouw bewijs, waarom doe je dan niet gewoon aangifte? Vervolgens PM je een admin met een bewijs van je gelijk en dan kan deze site overgaan tot sancties tegen een lid die zich heeft misdragen.

Je kunt je afvragen wat het nut is van (het proberen om) iemand hier publiekelijk aan de schandpaal te nagelen. Wat probeer je hiermee te bereiken? Je huidige aanpak heeft overduidelijk niet geresulteerd in het gewenste resultaat. Je voelt je zelfs genoodzaakt dan maar zelf op te stappen. Maar ook daar bereik je waarschijnlijk niets mee.

"Bewijs" is niet hetzelfde als "wat voor jou overduidelijk is".

Als je er onderling niet uitkomt, dan is de meest logische stap dat je het hogerop speelt.

Of je pakt je verliezen en dan ben je een ervaring rijker en een illusie armer :p.

Na name="KO" mist een sluitingshaak >. Als je HTML niet klopt kun je er sowieso niet vanuit gaan dat dingen altijd naar behoren werken.

En weet je zeker dat je de borg uit $_POST wilt halen? Als iemand zijn/haar formulier inhoudelijk aanpast dan kun je de borg op die manier aanpassen?

Het is toch allemaal niet zo zwart-wit als hier wordt voorgesteld denk ik.

Als wat @Luc in een ander draadje zegt klopt, dan mag je niet zomaar allerlei dingen roepen, ook al heb je slechte ervaringen met @Ferhat.Remory. Als je/er aangifte hebt/is gedaan of als er een veroordeling is wordt dit misschien anders.

Dan, hoe heb je afspraken vastgelegd en hoe vaak heb je zaken met hem gedaan? Als dit allemaal mondeling is, dan hangen hier blijkbaar ook allemaal regels aan vast.

Het kan dus prima zijn dat je daadwerkelijk benadeeld bent, maar zonder enige "bewijslast" kunnen wij je niet helpen en daarnaast is deze site waarschijnlijk ook niet de juiste plek hiervoor.

Beschouw het eens vanuit het perspectief van deze site. Je bent hier op hun "turf" een conflict aan het uitvechten. Is dit echt de juiste plaats voor zoiets? Je plaatst de moderators op deze manier voor een blok want ze kunnen moeilijk partij kiezen voor iemand omdat ze simpelweg niet weten wat er daadwerkelijk is gebeurd.

Het feit dat @Ferhat.Remory zich hier ogenschijnlijk niet meer vertoont spreekt misschien niet in zijn voordeel, maar aan de andere kant kan ik mij best voorstellen dat hij gewoon geen zin heeft om mee te gaan in deze potentiële "flauwekul".

Jammer dat je je zo voelt/dat het zo is gelopen, maar deze site kan hier verder weinig aan doen denk ik. Wat dat betreft wordt misschien de verkeerde partij gestraft door deze actie?

NB

Bovenstaande query maakt (waarschijnlijk) gebruik van prepared statements. Een van de doelen hiervan is om indirect DATA in de SQL op te nemen, op een zodanige wijze dat deze niet als SQL geïnterpreteerd kan worden. Dit maakt queries veilig(er) en beschermt ze op deze manier tegen SQL-injectie.

Echter, op het moment dat je rechtstreeks variabelen gaat invoegen in de SQL-string ontstaat het gevaar van SQL-injectie. Je schendt hiermee in wezen de spelregels van prepared statements waarbij je alle DATA apart zou moeten verwerken.

Nu zou je zeggen "ja maar $ulevel, $time en $userip zijn onschadelijk dus hier kan niets mee misgaan." Dat kan misschien wel zo zijn, maar elke keer dat je deze code ziet dat zou je misschien de neiging hebben om dat (nogmaals) te verifiëren. Oftewel, deze code zet je elke keer aan tot denken (of zou dit moeten doen).

Ook zie je nog een ander aspect in het bovenstaande fragment: wanneer gebruik je quotes, wanneer niet? Houdt de afwezigheid van quotes in dat deze bewust zijn weggelaten of toch per ongeluk zijn vergeten? Wat voor implicatie kan dit in sommige gevallen hebben? Kan de query daardoor in bepaalde randgevallen mislopen?

Al deze bovenstaande problemen heb je niet als je simpelweg de spelregels van prepared statements zou volgen. Het lijkt mij een goed ontwerpprincipe om op een zodanige manier code te schrijven dat deze vanwege een bepaalde aanpak al ondubbelzinnig is, maar dan moet je dus wel de regels van deze aanpak aanhouden.

Mijn voorstel zou dan ook zijn om alle variabelen uitsluitend via placeholders in de SQL in te voegen, en niet in een soort van hybride vorm zoals hierboven gebeurt. Dit resulteert in hoofdpijncode die potentieel voor problemen kan zorgen.

En dan nog het volgende: bovenstaand fragment bevat drie queries. Als het de bedoeling is dat deze query-batch in het geheel, of in het geheel niet in de database ingevoegd dient te worden, dan wordt het tijd om (database-)transacties te gaan gebruiken.

Vooral als het uitgebreide "administratieve" systemen betreft, dan is het belangrijk dat de informatie onderling consistent blijft. Transacties garanderen dit.

Als er in een batch queries (bijvoorbeeld A, B, C, D) er in B iets misgaat, dan worden C en D normaal gesproken (zonder gebruikmaking van transacties) mogelijk alsnog uitgevoerd. Dit kan resulteren in ontkoppelde, foutieve of tegenstrijdige informatie in de database.

Als deze serie echter in een transactie zou zitten, en er gaat iets mis in B, dan zou A worden teruggedraaid, en C en D zouden dan nooit worden uitgevoerd.

Uiteraard hangt het er natuurlijk ook vanaf hoe $this->query() intern werkt, mogelijk wordt verdere verwerking dan al afgebroken, maar A zit dan waarschijnlijk permanent in je database.

Misschien mislukt dan als resultaat van het mislukken van B een operatie in het systeem (waarvan een terugkoppeling en melding gegeven zou moeten worden), maar dit heeft dan in ieder geval niet tot gevolg dat je database vervuild raakt met niet-kloppende gegevens.

Dit soort (simpele?) voorzieningen (een juist gebruik van prepared statements, transacties) zou je gewoon moeten volgen. Maar misschien moet dit eerst een keer vreselijk misgaan zodat je echt met de neus op de feiten wordt gedrukt, een gebrande hand is immers de beste leermeester.

Deze reactie was wat voorbarig en betrof een misverstand dat inmiddels is opgehelderd :).