POO : Blog + commentaires

Trop long le code, et trop la flemme de le lire en détail x) ( le meilleur code est toujours le plus simple et le plus facile à lire, petite astuce ).

Le MVC : il se passe les trucs suivants dans la vie d'Internet, des gens demandent des pages à des ordinateurs quelque part et ces ordinateurs renvoient ces pages.
Le design pattern Modèle Vue Controlleur, un grand classique, est une façon possible de faire en sorte que cette magie opère. C'est très simple ( si on reste en surface ) : le Controlleur chapotte tout le merdier, quand tu demande une page, c'est lui qui sait quelle page il faut construire et comment il faut la construire. Pour ça, il va faire deux choses : aller chercher les données que tu veux voir, et les mettre dans une belle mise en forme canon pour que ça te pique pas les yeux et parce que t'es pas une machine. Les données, il va les demander au Modèle, qui se charge de tout ce qui est données. Quand il les a, il les injecte dans la vue, et le Sacro Saint FrameWork renvoie tout ça dans ton navigateur.
Une recommendation fréquente dans l'industrie est la suivante : "Fat Models, Skinny Controllers".
En substance, tes controlleurs ne devraient jamais être très développé ( pour des applications "simple" ). Tes modèles par contre, seront bien chargés. Tout ce qui est requête est écrit à l'intérieur du Modèle, dans des méthodes qui sont appelées par l'extérieur. C'est très important, parce que des requêtes d'après le MVC n'ont pas du tout leur place en dehors du Modèle. Si tel était le cas, on ne serait plus dans un environnement MVC strict, ce qui implique qu'on a moins d'emprise sur le code et qu'on contrôle moins l'application.

Tu peux aussi voir le Modèle comme la représentation en langage serveur de la structure de tes données et de ses interactions, telles qu'elles sont décrites par les possibilités de ton moteur de bdd ( Mysql en l'occurence).

"Le problème vient peut être du fait que si je var_dump($statement), j'objtiens 2 $statement :"

Et tu devrais clairement pas.
Fais l'essai sur une page isolée avec comme seul code de quoi exécuter une requête PDO avec double statement, tu verras bien le résultat.

Tu répète la condition :
"if(
strpos($statement, 'UPDATE') === 0 ||
strpos($statement, 'INSERT') === 0 ||
strpos($statement, 'DELETE') === 0
)"

Pour commencer, la répétition, c'est mal ( l'intérêt du code c'est de ne rien répéter ). Ensuite, en gros ta condition a pour but de vérifier qu'on est forcément dans une requête SELECT. Donc autant être direct ;).

"Premièrement j'ai du changer if($req->rowCount() <= 0) en if(!$req) car sinon j'avais une erreur, le resultat semble le même mais je le précise on sait jamais."
Ces conditions ne sont pas strictement équivalentes. Pour vraiment en finir avec tes bugs, il faut que tu sois rigoureux dans ton nettoyage, ton remplacement ici c'est un pansement, pas une résolution. Il faut que tu comprennes pourquoi la première condition générait une erreur.

Quant à ton erreur fatale, ça nous dit que le statement de la requête sql est archi pourri. Pdo te permet de récupérer des détails sur les erreurs, ça serait bien que tu les partage.

Et suggestion qui tue :

// Choix du fetch
if($one == false){ $data = $req->fetchAll(); }
else{ $data = $req->fetch(); }

Devient :

$data = ( ! $one ) ? $req -> fetchAll() : $req -> fetch();

C'est un ternaire, seuls les élus se servent de ce kung fu.

Yo, tu souhaite return ta variable $req et sauter le fetch uniquement si le statement est un INSERT, UPDATE, DELETE ;), ta condition est inversée, il te sufit de la remplacée par :

        strpos($statement, 'UPDATE') !== false ||
        strpos($statement, 'INSERT') !== false ||
        strpos($statement, 'DELETE') !== false

Merci énormement poru vos réponses !!
@Noire Munich Tous tes conseils me seront d'une grande utilité !! Tu as raison sur toute la ligne :p
@ToToSe De même ! le problème venait de là, et peut être résolu comme cela, ou comme tu le l'a conseillé avec un

Merci encore !! :)