Lijkt mij stukken slechter leesbaar, maar to each his own I guess. Probeer het allemaal uit en kijk wat je het fijnste vindt werken.

var_dump() escaped trouwens geen output en dat is uit oogpunt van veiligheid / makkelijk debuggen wellicht wel niet bepaald handig.

Vergelijk:

<?php
// Force UTF-8.
header('Content-Type: text/html; charset=UTF-8');


$test = array('<script>while(1) alert(\'irritant he\')</script>');


function dd($data) {
    var_dump($data);
    die();
}
dd($test);
?>

Met:

<?php
// Force UTF-8.
header('Content-Type: text/html; charset=UTF-8');


$test = array('<script>while(1) alert(\'irritant he\')</script>');


function dump($a) {
 echo '<pre>'.htmlspecialchars(print_r($a, true), ENT_QUOTES, 'UTF-8').'</pre>';
}


dump($test);
?>

Citaat van D.Oomens

Iedereen die OOP wil leren programmeren en niet te veel wil omkijken naar veilig omgaan met SQL, PDO, etc, etc zal ik aanraden om deze package te gebruiken

Iemand die niet teveel wil omkijken naar veilig omgaan met X kan beter een ander vakgebied kiezen. Elke serieuze ontwikkelaar zou zich bewust moeten zijn van gevaren, risico's en pitfalls. Hoe vaak het voorkomt dat iemand PDO gebruikt omdat 'ie gehoord heeft dat dit veilig zou zijn, en vervolgens querystrings in elkaar gaat metselen waarin niet ge-escapete userdata zit... Indien je de spelregels van een techniek niet kent noch toepast, waarom gebruik je dan die techniek? Dit heet in de volksmond ook wel "prutsen".

Citaat van D.Oomens

Een framework bespaart je enorm veel tijd, de klus is veel sneller geklaard. Dat is een FEIT.

Hangt er vanaf wat je uitganspunt en je uitgangspositie is.

Indien je net bent begonnen met de beginselen van OOP dan denk ik niet dat het er tussenknallen van allerlei technieken en abstractielagen echt bevorderlijk werkt qua ontwikkeling. Je zult je (enigszins) moeten bekwamen in de tools waarmee je werkt.

Daarnaast is het de vraag of je al deze flexibiliteit (en ook abstractie en complexiteit) nodig hebt. Dit hangt af van de te klaren klus. Mijn uitgangspunt is use the best tool for the job. Zolang je niet weet wat de klus omvat is het nogal voorbarig om alvast je gereedschap te kiezen. Ook zou je zo'n keuze moeten kunnen onderbouwen en niet simpelweg methode X of technologie Y kiezen toevallig omdat jij die fijn vindt werken. Mogelijk kunnen dingen veel simpeler opgelost worden.

Plus als je iets verkeerd toepast is het eindresultaat nog steeds... onbruikbaar (zie codefragment). Uiteindelijk zijn het dan alleen maar dure woorden met 0,0 toegevoegde waarde. Maar goed, doe je ding.

Ok, installeer Laravel (ook nodig?) en Eloquent en alles gaat vanzelf! Je hoeft niet eens meer na te denken over wat je doet. Handig.

<?php
/**
* Get the value of an field.
*
* @param $id
* @param null $field
* @return mixed|null
*/
public function get($id, $field = null)
{
    $data = $this->getAll($id);
    if (array_key_exists($field, $data)) {
        return $data[$field];
    }
    return null;
}
?>

Euh, dit retourneert niets als je enkel een id invult? En als het echt de bedoeling is dat je enkel een kolom(waarde) retourneert dan zou ik de methode getField oid noemen en $field verplicht maken.

@MBCompany omdat je nog enigzins zoekende lijkt en nog niet al te lang bezig met met OOP zou ik gewoon simpel beginnen en niet direct allerlei abstractielagen in je code aanbrengen. Dit is misschien ook helemaal niet nodig voor hetgeen je probeert te bereiken.

Wat mij weer terug brengt bij mijn eerdere vraag: wat wil je met deze class kunnen doen? Zoals eerder aangegeven: je kunt met één of enkele queries bij creatie van een User object alle data van een user wel binnenharken, je hoeft hier niet per kolom een methode voor te gebruiken.

Wel moet je je bewust zijn van het feit dat je daarmee in principe een kopie trekt van de overeenkomstige gegevens in de database, en deze gegevens kunnen mogelijk in de "tussentijd" veranderen. In je User object zitten dan dus potentieel verouderde gegevens. Vooral als je met "geld" tussen users gaat schuiven (is dit een criminals spel ofzo?) moet je goed op gaan letten. Wat je hebt geschreven is niet per definitie goed of fout, maar naar aanleiding van wat ik voorbij zie komen zie ik wel wat verkeersborden opdoemen.

Citaat van M.Beers

De ORM regelt de connectie en de queries...

Maar die implementeer je toch voor een groot deel zelf? Dan moet je toch ook (zelf?) rekening houden met locking van tabellen/kolommen? Los daarvan lijkt dit mij niet iets waar een startende OOP programmeur headfirst in moet duiken. Verder is een ORM niet noodzakelijk. Dus waarom zou je een applicatie standaard uitrusten met zo'n abstractielaag? Dit alles kan ook gewoon in native (OOP) PHP. Dat lijkt mij in dit geval een beter startpunt.

Mja, iets met iemand met een kluitje het riet insturen.

Of iets met het paard achter de wagen spannen.

Het is wel erg makkelijk om zo te reageren.

Je advies is gebaseerd op aanames / eigen ervaring. Stap 1 lijkt mij het toetsen van die aannames, om er verzekerd van te zijn dat je het juiste gereedschap gebruikt om de klus te klaren.

Hier zou nog user input in kunnen zitten.

Met bijvoorbeeld JavaScript. Met AJAX calls.

De bovenstaande functie vervult zijn rol wel, maar is NIET VEILIG.

ESCAPE ALTIJD OUTPUT, tenzij je hier een speciale - en gedocumenteerde - reden voor hebt.

Een veilig alternatief zou dus zoiets zijn (aanname: character encoding UTF-8):

<?php
function dump($a) {
    echo '<pre>'.htmlspecialchars(print_r($a, true), ENT_QUOTES, 'UTF-8').'</pre>';
}
?>

Maar als jij niet weet wat zijn eindbestemming is, hoe kun je dan zeggen hoe jij zijn reis (waar naartoe?) zou moeten plannen?

Metafoor: jij stopt jouw lievelingskleding in zijn koffer, maar die is mogelijk helemaal niet geschikt voor het klimaat van het land van bestemming.

De eerste vraag aan de topicstarter zou eigenlijk moeten zijn: "wat probeer je bereiken" of "wat wil je (kunnen) doen"?

Verder zou je inderdaad praktische tips kunnen geven over het gebruik van PDO, maar los van een specifieke oplossingsrichting omdat je simpelweg niet weet of de gekozen techniek dan wel geschikt is. De topicstarter verschaft op dit gebied in wezen onvoldoende informatie. Het is niet onze plaats om daar dan vervolgens aannames over te doen.

Hoe los je hiermee het eerder aangekaarte (potentiële) probleem op?

Het kiezen van een technische oplossing / implementatie voordat je weet wat iemand probeert te bereiken lijkt mij niet verstandig.

"Kies een stuk gereedschap"
- "Ok" (pakt schroevendraaier)
"Mooi, gaan we nu de heg snoeien"

Indien dit niet je afstudeerstage is zou ik je aanraden wel je studie af te ronden als dit op een laag pitje komt te staan of komt te vervallen met je indiensttreding.

Mochten jullie wegen ooit nog scheiden dan heb je in ieder geval nog je papiertje.

Dat gezegd hebbende, "stagiaire" is de vrouwelijke vorm van het woord "stagiair". Zijn jullie expliciet op zoek naar een vrouwelijke stagiair? Maak hier anders stagiair (m/v) van ofzo. Dit is nu onduidelijk.

Wat @wimmpie ook zegt: enerzijds gebruik je "users" (wat mij een tabel lijkt) en vervolgens "users.data". Heb je echt een (aparte?) database genaamd "users" en vervolgens een tabel genaamd "data"?

Als je veelvuldig verschillende gegevens van eenzelfde gebruiker opvraagt zou ik hier niet allemaal aparte queries voor schrijven, je kunt in één query prima alle (relevante) data ophalen van een gebruiker, zelfs als deze verspreid is over meerdere tabellen. En deze dan bijvoorbeeld in een hulp-array of User-object opslaan zodat je hier vervolgens aan kunt refereren.

Maar hoe je dit precies doet hangt ook af van:
- hoe deze data er uitziet (structuur)
- en wat je er mee wilt doen

Ik zie daar dingen als "bank" en "cash" voorbij vliegen. Wanneer je informatie opvraagt met als doel deze te veranderen dan is het belangrijk dat de informatie na opvragen (tijdelijk) read-only wordt tot (en na) het moment van het bijwerken van deze data. Als je dat niet doet dan kunnen er dingen fout lopen.

Stel bijvoorbeeld dat er 2 operaties bestaan in jouw applicatie die het volgende doen:
- geld storten
- geld opnemen

Stel dat jouw saldo 200 is.
Vervolgens worden er tegelijkertijd twee operaties uitgevoerd:
- 200 opnemen
- 50 storten

Wat is dan volgens jou het eindsaldo? 50 toch he?
Nou niet dus :). Althans niet als je je startsaldo eerst overhevelt naar een hulpvariabele en dan pas de bewerkingen uitvoert. Er kunnen dan -zonder speciale voorzieningen- meerdere eindantwoorden mogelijk zijn afhankelijk van de volgorde waarin de acties worden uitgevoerd. Het is mogelijk dat de einduitkomst een van de volgende waarden heeft:
50 (dit is wat we willen)
250 (dit is wat we niet willen)

Hoe komen we tot 250?
Noem 200 opnemen A
Noem 50 storten B

Dit is wat er achtereenvolgens zou kunnen gebeuren (A en B vinden "tegelijkertijd" plaats):
A vraagt saldo op: 200
B vraagt saldo op: 200
A neemt 200 op, eindsaldo volgens A: 0
B stort 50, eindsaldo volgens B: 250

Wanneer B voor de opname van A het saldo opvraagt en na het wegschrijven van het eindsaldo van A dit zelf doet heb je een niet-kloppend eindantwoord. Dit was mogelijk omdat er geen "lock" is op de waarde van het saldo. Normaal regel je dit met een voorziening in de database waarmee je gegevens tijdelijk kunt vergrendelen zodat slechts één proces deze data kan aanpassen. Beter bekend als een database-transactie. Net zoals een monetaire actie eigenlijk: alle stappen vormen tezamen één ondeelbare actie. Anders gebeuren er mogelijk rare dingen, zoals hierboven omschreven.

Daarom kan ik niet op voorhand zeggen hoe jij je data in PHP moet organiseren omdat ik niet weet hoe je hier in je database mee omgaat.

Mogelijk staat het niet op voorhand vast dat er resultaten zijn. Het fetchen voordat je dit hebt vastgesteld is misschien voorbarig.

Ook weet ik niet precies hoe je fouten afhandelt? Als dit met exceptions gebeurt moet je wellicht in de methoden van de User class, of waar je deze methoden in een andere class aanroept een try-catch blok gebruiken?

Daarnaast zou je volgens mij ook te allen tijde een try-catch blok moeten gebruiken wanneer je een connectie maakt via PDO want als deze om wat voor reden mislukt (zelfs als je database-credentials kloppen kan dit gebeuren) wordt een exception gethrowd. Een exception die niet gecatched wordt produceert een fatal error. En in die exception-boodschap (die ook in je fatal error wordt getoond) staan je database-credentials (don't ask lol).

Dan nog een observatie: je hebt nu twee methoden geschreven waarin je achtereenvolgens hetzelfde doet: prepare, execute, fetch. Wanneer je twee of meer keren een of meer van dezelfde handelingen uitvoert moet je je af gaan vragen of dit niet wat eenvoudiger kan. Een goed ontwerpprincipe is Don't Repeat Yourself (DRY). En tevens: prepare, execute, fetch over and over again: aint nobody got time for dat! Je zou kunnen overwegen om een kleine wrapper om PDO te schrijven zodat dit soort database-interacties minder regels code omvatten.

En dan nog het volgende: waarom gebruik je PDO en niet MySQLi? Als je toch enkel een MySQL-database gebruikt heb je niet per se PDO nodig, noch prepared statements. Laat de keuze voor de driver die je gebruikt (PDO(_MYSQL) of MySQLi) alsmede het gebruik van prepared statements (in PDO is dit een verplichting, in MySQLi is deze optioneel) een bewuste keuze zijn.

Dat is wat ik in de gauwigheid zo kan verzinnen.

Binnenkort is mogelijk mijn artikel over routing klaar, de volgende in een reeks van artikelen over het maken van webapplicaties / frameworks.

TL;DR controleer eerst of je een bestaand bestand/directory aanroept, en voer daarna (als het voorgaande niet het geval was) een rewrite uit.

Ik denk dat je in je voorbeeld de externe aanroep en de interne vertaling door elkaar haalt?

De syntax van rewrite staat waarschijnlijk wel in de goede volgorde. Ik ken deze verder niet (ben Apache gewend) maar ik kan mij zo voorstellen dat er ook in nginx een commando is voor het skippen van bestaande bestanden (en directories). Hier zou je dan eerst op kunnen controleren, daarna heb je je fallback naar index.php.

Je zou dit trouwens nog kunnen vereenvoudigen: je zou ook ALLES wat niet refereert aan een bestaand bestand (of directory) simpelweg door kunnen sturen naar index.php. Vervolgens controleer je $_SERVER['REQUEST_URI'], ontleed je het (relatieve applicatie-)pad dat is aangeroepen en bekijk je of dit een valide aanroep was. Dit principe heb ik ook in een artikel beschreven.

Wat ik niet begrijp is dat mensen voor dit doel pertinent een querystring-variabele (?page=, ?q=, ?whatever=) reserveren. Dit is namelijk helemaal niet nodig en vervuilt in zekere zin je querystring-scope.

EDIT deze oplossing biedt mogelijk soelaas (2 minuten googlen). Je zult dan wel zelf de rest van je URL moeten ontleden maar het probleem verplaatsen naar PHP heeft zo zijn voordelen, je kunt daar dan het request verder afhandelen, in plaats van worstelen met hardcoded zut in een nginx configuratie-bestand.

@Jesse Maar waarom zou je continu data willen aanpassen? De start- en einddatum liggen toch vast. Controleren of je de einddatum nadert kan vrij simpel met native MySQL functies zoals DATEDDIFF().

Citaat van MOnkNL

Hij vergelijkt nu namelijk 2 strings met elkaar en dat lukt niet.

Dat werkt prima zolang je maar een juiste lexicografische (alfabetische) vergelijking doet. Laten timestamps (met een jaar-maand-dag format (in die volgorde)) dat principe nu prima volgen.

Vergelijk:

mysql> SELECT 5 < 14;
+--------+
| 5 < 14 |
+--------+
|      1 |
+--------+
1 row in set (0.00 sec)


mysql> SELECT '5' < '14';
+------------+
| '5' < '14' |
+------------+
|          0 |
+------------+
1 row in set (0.00 sec)

Oftewel: het cijfer 5 komt numeriek voor het getal 14, maar de string '5' komt alfabetisch na de string '14'.

Indien je timestamps (die strings zijn) een alfabetische opbouw volgen (van hoog naar laag, van grote tijdseenheid (jaar) naar kleine (dag)) dan kun je prima datum-strings met elkaar vergelijken. Als je echter een of ander lijp custom datum format gebruikt dan ben je nat omdat je hiermee niet fatsoenlijk kunt filteren of sorteren.

Zou het niet handiger zijn dat je X dagen voor het verlopen van een abonnement hier iemand over bericht?

Je hebt het over abonnementen, maar ik zie nergens een abonnementen-tabel? Als je die nou eens een maakt met:
- klant-id
- begindatum
- einddatum
- wellicht andere informatie zoals abonnementstype
- een indicatie of er een reminder voor verlenging is verstuurd

Dan heb je meteen een historie van iemand zijn fitness-verleden.

Tevens zou je dan in je klantentabel een abonnements-id van het actieve abonnement kunnen bijhouden.

Ik zou eerst eens goed nadenken over de organisatie van je data in de database, dit vormt namelijk het fundament van je applicatie.

Ik heb hier geen ervaring mee maar het lijkt mij dat je een macro zou moeten kunnen maken/programmeren die dat kan. Als het definieerbaar is, is het programmeerbaar. Meestal.

Ja, dat is toch een linkje bouwen conform de regels waarmee Google zoekt? Al de informatie zit in de URL.

Hoe dit er uit ziet:
1. ga naar google.nl
2. type een zoekopdracht in in de normale of geavanceerde zoekfunctionaliteit
3. kijk naar de URL
4. neem dit format over in je eigen applicatie

?

Wat probeer je uiteindelijk te bereiken? Moeten alleen de zoekopdrachten gegenereerd worden? Moet de functionaliteit automatisch kunnen zoeken? Moeten de resultaten ook gecached worden? Ben je een kennissysteem aan het bouwen of informatie aan het vergaren? Hoe ver voert dit alles door?

Een programmeertaal kan prima plakken tekst aan elkaar fietsen als je dat bedoelt. Dan zul je even moeten kijken hoe (in welke vorm) je deze als zoekopdracht aan Google moet voeren.

Indien je een specifieker antwoord wilt hebben zul je een specifiekere vraag moeten stellen.

Ja?

Google heeft een zoek-syntax waarin het volgens mij mogelijk is om bepaalde woorden verplicht te laten zijn zodat je relevante(re) zoekresultaten krijgt.

Zo zou je bijvoorbeeld alle relevante woorden tussen "dubbele quotes" kunnen zetten, dus zowel de bloem alsmede de speciale naam zodat dit als een woordgroep beschouwd wordt.

En/of je zoekt deze resultaten via de advanced search.

Hm, weet niet of dit het is maar als dit het aantal "the connection was reset" mededelingen doet afnemen dan heeft dit blijkbaar een positief effect (al zie ik niet direct hoe).

Je zou regel 7 t/m 9 kunnen vervangen door:

<?php
if (in_array(strtolower(substr($file, strrpos($file, '.') + 1)), $extensions)) {
    // ...
?>

Dat is sneller dan er eerst een array van maken lijkt mij.

Specifiek:

<?php
substr($file, strrpos($file, '.') + 1);
?>

retourneert de extensie van $file.

EDIT: ook weet ik niet of die expliciete is_file() controle nodig is? Je controleert toch op extensie? Het aanroepen van clearstatcache() voor de aanroep van scandir() is mogelijk een betere strategie, anders lees je misschien een verouderde bestandshistorie uit - is_file() gaat je dan waarschijnlijk ook niet redden omdat je dan waarschijnlijk dezelfde (verouderde) historie raadpleegt :p.