Discussion :

[Black_Layer]

Bonjour,

Je suis perdu.

J'ai fait le formulaire suivant :

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<form action="register.php" method="post"><br /><br />
Nom : <input type="text" name="name" size="40" maxlength="256" /><br /><br />
Pseudo : <input type="text" name="login" size="40" maxlength="256" /><br /><br />
Mot de Passe : <input type="password" name="pass" size="40" maxlength="256" /><br /><br />
Adresse e-mail : <input type="text" name="email" size="40" maxlength="256" /><br /><br />
Localisation : <input type="text" name="location" size="40" maxlength="256" /><br /><br />
Site internet / Blog : <input type="text" name="website" size="40" maxlength="256" /><br /><br />
<input type="submit" value="S'inscrire" />
</form>

Rien de bien compliqué jusque là. Puis je veux écrire ces infos dans une base de données mysql :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
<?php
 
 
 
	if (isset($_POST['login']) and isset($_POST['pass']))
 
	    {
		  if ($_POST['login'] != "" and $_POST['pass'] != "")
		   {
		   		$nom = $_POST['name'];
				$pseudo = $_POST['login'];
				$motdepasse = $_POST['pass'];
				$email = $_POST['email'];
				//$date_creation = now();
				$localisation = $_POST['location'];
				$site = $_POST['website']; 
				$pass = md5 ($motdepasse);
 
 
				require ("connexion.php");
 
				$query = 'INSERT INTO users (user_login, user_password, user_email, user_name, user_location, user_website) VALUES ($pseudo, $pass, $email, $nom, $localisation, $site)';
				$stmt = $bdd->prepare($query);
 
 
 
				$stmt->execute();
 
							 }
		   		   else
		   {
		   echo 'Les informations saisies sont incorrectes !';
		   }
		}
?>

Au final, ça n'écrit rien du tout dan ma bdd et je ne comprends pas pourquoi si ce n'est que comme je débute sur PDO je dois avoir loupé qqch mais je ne sais pas trop quoi.

Quelqu'un peut m'aider, svp ?

[ABCIWEB]

Regardes les exemples de la doc http://php.net/manual/fr/pdo.prepare.php
Tu trouve que cela ressemble à ce que tu as fait ?

EDIT : Si tu fais une requête préparée, il faut :
1/ Utiliser des marqueurs nommés ou interrogatifs pour symboliser tes variables dans la préparation de la requête
2/ Associer tes marqueurs avec bindParam ou bindValue avant d'utiliser execute(), ou sinon passer le tableau des marqueurs et de leur valeur dans execute()

[Black_Layer]

J'avais vu cette doc et j'ai recopié aussi la méthode avec bindparam mais j'avais tjs le même problème !!

[Black_Layer]

Bon, j'ai tout relu et corrigé le code.

J'obtiens donc ceci :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
<?php
	if (isset($_POST['login']) and isset($_POST['pass']))
 
	    {
		  if ($_POST['login'] != "" and $_POST['pass'] != "")
		   {
		   		$nom = $_POST['name'];
				$pseudo = $_POST['login'];
				$motdepasse = $_POST['pass'];
				$email = $_POST['email'];
				$localisation = $_POST['location'];
				$site = $_POST['website']; 
				$pass = md5 ($motdepasse);
 
				require ("connexion.php");
 
				$query = 'INSERT INTO users (user_login, user_password, user_email, user_name, user_location, user_website) VALUES (:pseudo, :pass, :email, :nom, :localisation, :site)';
				$stmt = $bdd->prepare($query);
 
				$stmt->bindParam(':pseudo', $pseudo);
				$stmt->bindParam(':pass', $pass);
				$stmt->bindParam(':email', $email);
				$stmt->bindParam(':nom', $nom);
				$stmt->bindParam(':localisation', $localisation);
				$stmt->bindParam(':site', $site);
 
				$stmt->execute();
			 }
		   		   else
		   {
		   echo 'Les informations saisies sont incorrectes !';
		   }
		}
?>

Ce code est fonctionnel...

... mais... ça m'a pas l'air très propre tout ça...

Vous en pensez quoi ?

[ABCIWEB]

C'est parfaitement propre.

Cela dit souvent on utilise un tableau avec les marqueurs et leurs valeurs correspondantes que l'on passe en paramètre dans execute(). C'est souvent plus rapide et pratique que de binder séparément les valeurs.

Mais d'un autre côté le fait de binder séparément les variables permet de leur attribuer séparément un type spécifique (option que tu n'utilise pas dans ton exemple), alors que quand on passe un tableau le mode chaine de caractère (PDO:: PARAM_STR) est utilisé par défaut pour toutes les valeurs du tableau.


EDIT: Utilises plutôt l'opérateur "&&" à la place de "and", ce n'est pas tout à fait la même chose et "&&" à un comportement plus prévisible dans les conditions multiples (les priorités d'exécution ne sont pas les mêmes).

[Black_Layer]

ok je remplace mes and par des &&

autre chose ; j'aimerais afficher un texte selon que mon enregistrement s'est bien passé ou non.

avec mysql, j'aurais fait un if (!$stmt) mais là ça n'a pas l'air de marcher.

une idée ?

[ABCIWEB]

Ben si c'est pareil,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
//renvoie true ou false
$result = $query->execute();
 
if($result)
{
//OK
}
else
{
//erreur
}

Cela dit comme tu t'intéresse à PDO tu devrais jeter un oeil du côté de la gestion des erreurs avec PDO::ERRMODE_EXCEPTION que tu peux mettre en paramètre dans ta connexion ou sinon plus tard dans le code en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$bdd->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

et donc après tu peux utiliser le gestionnaire d'exception en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
//...
require ("connexion.php");
 
$bdd->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
 
$requete_ok = true;
 
try {
        $query = 'INSERT INTO users (user_login, user_password, user_email, user_name, user_location, user_website) VALUES (:pseudo, :pass, :email, :nom, :localisation, :site)';
	$stmt = $bdd->prepare($query);
 
	$stmt->bindParam(':pseudo', $pseudo);
	$stmt->bindParam(':pass', $pass);
	$stmt->bindParam(':email', $email);
	$stmt->bindParam(':nom', $nom);
	$stmt->bindParam(':localisation', $localisation);
	$stmt->bindParam(':site', $site);
 
	$stmt->execute();
    }
catch(PDOException $e)
    {
        // en phase production
        $requete_ok = false;
 
        //en phase de développement on affiche les détails
       echo $e->getMessage();
    }
 
if($requete_ok) ...

l'avantage est que tu gère en une seule fois toutes les erreurs de ta requête, pas seulement au niveau du execute comme précédemment mais aussi au niveau du prepare et du bind des variables.

[Black_Layer]

Effectivement j'essaye de faire un maximum de gestion d'erreurs pour obtenir un résultat assez professionnel.

Toutefois, ton idée me pose un petit problème... récupérer les erreurs est une chose qui m'intéresse mais le getMessage() me fait afficher l'erreur sous l'oeil de l'utilisateur.
Deux cas se présentent alors :
- l'utilisateur est mal intentionné et grâce au message d'erreur il peut trouver une faille.
- l'utilisateur s'en fiche et je lui affiche donc des trucs qu'il ne comprend pas et dont il se moque pas mal.

Je fais fausse route ?

Sinon pourquoi pas écrire l'erreur dans une table de la bdd et l'affiche dans un "panneau d'administration" ?

[ABCIWEB]

Toutefois, ton idée me pose un petit problème... récupérer les erreurs est une chose qui m'intéresse mais le getMessage() me fait afficher l'erreur sous l'oeil de l'utilisateur.
Je fais fausse route ?

Tu n'as pas lu le commentaire juste au dessus de echo $e->getMessage(); ??
Il va de soit qu'on écrit cette ligne (si besoin) uniquement en phase de développement, et qu'on l'efface ou qu'on la met en commentaire lors de la phase de production (si tu préfère quand le site est en ligne).

Si tu fais pas attention à ce qu'on écrit... et en plus même pas un point pour dire que mes messages t'ont aidés
Grossier personnage va!

[Black_Layer]

Ok alors 2 choses :

1- Je n'avais pas lu le commentaire
2- Tes messages ne m'ont pas simplement aidé ; ils m'ont rendu un énoooooorme service

[ABCIWEB]

Bon ça va mieux alors un dernier petit conseil sur pdo : il est aujourd'hui très conseillé de désactiver l'émulateur de requêtes préparées avec l'option

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES,false);

(qu'on ne met généralement qu'une fois dans les options de sa connexion).

Le gros avantage est que l'émulateur de requêtes préparées va passer la main à l'émulateur de la bdd, si possible, et sinon reprendre la main en cas de besoins. On y gagne en performances et aussi en facilité pour le typage des données car le typage sera par défaut celui demandé par la bdd. Cela évite au passage l'erreur grossière des variables passées dans la clause LIMIT qui posent un problème si on ne type pas les variables explicitement en entier, vu que l'émulateur PDO type en string par défaut (et mysql exige un entier).

par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
$_GET['limite'] = 2;
try
{
	$query = "SELECT * FROM membres LIMIT ?";
 
	$stmt = $bdd->prepare($query);
 
	$stmt->execute(array($_GET['limite']));
}
catch (PDOException $e)
{
	echo $e->getMessage(); 
}
// SYNTAXE ERREUR : impossible de typer un tableau dans execute donc pas de solution sauf si on désactive l'émulateur de requêtes préparées.
// Si l'on ne désactive pas l'émulateur il faut utiliser un bind en spécifiant un type entier :
$_GET['limite'] = 2;
try
{
	$query = "SELECT * FROM membres LIMIT ?";
 
	$stmt = $bdd->prepare($query);
 
	$stmt->bindParam(1, $_GET['limite'],PDO::PARAM_INT);
 
	$stmt->execute();
}
catch (PDOException $e)
{
	echo $e->getMessage(); 
}
// OK
 
// Le plus simple, pratique et optimisé est encore de désactiver l'émulateur de requêtes préparées
$_GET['limite'] = 2;
try
{
        $bdd->setAttribute(PDO::ATTR_EMULATE_PREPARES,false);
 
	$query = "SELECT * FROM membres LIMIT ?";
 
	$stmt = $bdd->prepare($query);
 
	$stmt->execute(array($_GET['limite']));
}
catch (PDOException $e)
{
	echo $e->getMessage(); 
}
// OK

Donc il est très recommandé de désactiver l'émulateur de requêtes préparées qui est trop généraliste pour pouvoir être optimisé (ne pas oublier que l'on y gagne aussi en performances).

EDIT : Et pour la route, md5 est aujourd'hui complètement dépassé. A n'utiliser que pour compatibilité avec d'anciennes données. Le minimum pour les nouveaux codes aujourd'hui est sha256 disponible entre autre avec la fonction hash :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$hash_mdp = hash("sha256",$pass);

Sinon pour le forum, quand un message va dans la bonne direction on suggère de cliquer sur les pouces levés en bas des messages. Perso on y gagne rien mais c'est utile pour les éventuels visiteurs qui cherchent une réponse en parcourant le forum

[Black_Layer]

Whaouuu !! J'ai vraiment de la chance que tu te sois intéressé à mon topic !!

- Pour ce qui est du :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES,false);

si je le mets directement dans connexion.php, ça le fait ou c'est pas bon ?

- Je ne savais pas que le md5 était dépassé ; merci de m'en informer.

- Toujours dans mon soucis de faire un bon code, j'aimerais vérifier que le pseudo n'est pas déjà utilisé (quoi de plus con que deux personnes sous le même pseudo).
J'ai cherché sur le net et j'ai vu pas mal de scripts utilisant SELECT count(*) puis data[0] etc... mais ce script génère d'après les retours pas mal d'erreurs car "data[0] ce n'est pas le nombre de résultats retournés par la requête mais la première colonne demandée dans le select".

Je pourrais donc faire un script classique parcourant la bdd à la recherche du login et comparant avec le login recherché... mais là ça m'a l'air lourd.

Une idée de script plus simple ou de correction du select count(*) ?

- Dernière chose, j'ai vu un script de connexion où il y avait tout le code php, puis tout le code html et ce dans le même fichier "inscription.php".

C'est mieux de travailler avec un seul fichier ou de séparer les deux ?

[ABCIWEB]

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES,false);

si je le mets directement dans connexion.php, ça le fait ou c'est pas bon ?

Oui, la manière la plus lisible (à mon avis) pour passer des options lors de la connexion est de faire comme dans cette petite classe de connexion

- Toujours dans mon soucis de faire un bon code, j'aimerais vérifier que le pseudo n'est pas déjà utilisé (quoi de plus con que deux personnes sous le même pseudo).
J'ai cherché sur le net et j'ai vu pas mal de scripts utilisant SELECT count(*) puis data[0] etc... mais ce script génère d'après les retours pas mal d'erreurs car "data[0] ce n'est pas le nombre de résultats retournés par la requête mais la première colonne demandée dans le select".

Cela devrait fonctionner mais cela dépend de comment c'est mis en place.
Avec pdo on recommande d'utiliser fetchColumn comme dans l'exemple n°2 de ce lien

D'un autre côté, si ta table est bien construite tu devrais avoir le champ "pseudo" en tant que champ unique, ou comme clé primaire. Tu pourrais donc - à cette condition seulement - te servir de cette caractéristique pour faire ton insert et simplement gérer l'exception car l'insert ne fonctionnera pas si deux pseudo sont identiques.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$pseudo_multiple = null;
 
$bdd->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
 
try
{
	$query = "INSERT INTO membres (pseudo) VALUES(?)"; 
 
	$stmt = $bdd->prepare($query);
 
	$stmt->execute(array($_POST['pseudo']));
}
catch (PDOException $e)
{
	$pseudo_multiple = true;
}
 
 
if (isset($pseudo_unique)) echo 'ce pseudo est déjà utilisé';

- Dernière chose, j'ai vu un script de connexion où il y avait tout le code php, puis tout le code html et ce dans le même fichier "inscription.php".

C'est mieux de travailler avec un seul fichier ou de séparer les deux ?

C'est comme tu veux mais on à l'habitude d'essayer de ne pas trop compliquer les choses. Au final, il faut un maximum de lisibilité pour se repérer rapidement dans les scripts. Evidemment plus on entasse de code plus cela devient compliqué, mais cela dépend aussi de l'organisation. Ta question pose donc plus généralement le problème de l'organisation du code. Tu peux regarder du côté du modèle MVC qui est un exemple d'organisation de code et que tu peux adapter suivant tes besoins (en reprenant tout ou partie des idées développées). Enfin bon c'est un vaste débat.
Dans ton cas précis et en considérant que l'on ne connait rien au modèle MVC tu vas te poser des questions contradictoires entre redondance de code (si tu emploies deux fichiers totalement distincts) et complexité du contrôleur : si tu n'as qu'un seul fichier le contrôleur aura pour mission d'utiliser et d'afficher le code suivant la fonctionnalité demandée (il peut bien entendu appeler des scripts externes via des "include").
A toi de voir. En fait sur de petits sites où il y a peu d'évolution, on se prend généralement pas trop la tête et on fait plutôt comme on le sent (souvent au plus rapide et simple). On apprécie surtout les avantages d'un modèle bien conçu quand il y a beaucoup de maintenance et d'évolution, autrement le temps de conception/mise en place peut être disproportionné par rapport au besoin final. Cependant certains on leurs habitudes et emploient systématiquement un modèle bien défini. Comme je le disais c'est un vaste débat.

[Black_Layer]

la manière la plus lisible (à mon avis) pour passer des options lors de la connexion est de faire comme dans cette petite classe de connexion

Les classes et moi, ça fait 4... je vais donc me contenter d'insérer la ligne dans connexion.php et je verrai pour les classes plus tard.

Dois-je rajouter aussi [PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION ou pas ?
Dans la faq ça dit "émet une exception". Cette exception va-t-elle s'affiche aux yeux de mes utilisateurs ?

D'un autre côté, si ta table est bien construite tu devrais avoir le champ "pseudo" en tant que champ unique, ou comme clé primaire.

le champ pseudo est effectivement en unique mais je veux effectuer un test avant la tentative d'inscription pour éviter que SQL ne me retourne l'erreur "barbare" 1062 (me disant que le champ est identique à un autre).

Concernant le modèle, je vais continuer en MVC car j'ai "appris" à tout séparer ; c'est plus simple quand il n'y a qu'un petit truc à changer.

Le minimum pour les nouveaux codes aujourd'hui est sha256

Le mot "minimum" sous-entendrait-il qu'il y a mieux encore ? Si oui, quoi ?

Merci pour tout le temps que tu me consacres !

[ABCIWEB]

Concernant les options PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION etc. il faut bien prendre conscience qu'elles valent pour toutes la durée d'exécution du script, * à moins bien sûr de changer leur valeur plus loin dans ton script avec setAttribute (comme montré dans mes exemples).

Donc si par exemple du déclare l'option PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION dans la classe de connexion citée plus haut - et qu'on appelle simplement en faisant $bdd = C_PDO::getC(); - cela implique que tu devras gérer les erreurs avec un bloc try/catch (comme dans mes exemples) pour toutes tes requêtes (* à moins bien sûr...) Ce n'est généralement pas un problème mais il faut bien s'en souvenir car sinon pour toute erreur tu auras un message d'erreur détaillé qui commencera par "uncautch exception ..." même pour les visiteurs.

[ABCIWEB]

Les classes et moi, ça fait 4... je vais donc me contenter d'insérer la ligne dans connexion.php et je verrai pour les classes plus tard.

Oui mais en même temps elle est déjà toute faite cette classe. Il suffit juste de lui indiquer le lien vers ton fichier (qui contient les variables de connexion) dans le "require_once" et c'est tout. Et éventuellement d'ajouter ou supprimer des options de base pour la connexion.
Pour le reste elle n'a qu'une seule manière d'être utilisée c'est de l'appeler en faisant $bdd = C_PDO::getC(); pour avoir la connexion.
L'avantage est que tu peux l'appeler cinquante fois dans ton script (depuis une fonction, une classe, bref depuis n'importe où et plusieurs fois dans ton code) et la connexion ne se fera qu'une fois et proprement.

Dois-je rajouter aussi [PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION ou pas ?
Dans la faq ça dit "émet une exception". Cette exception va-t-elle s'affiche aux yeux de mes utilisateurs ?

Tu n'as pas encore compris ? Quand on utilise ce mode c'est justement pour gérer les erreurs. Plutôt que d'afficher ou cacher les erreurs le code émet une exception, mais le code continue, et s'il y a une erreur elle sera reportée dans le bloc "catch". Mais on fait bien ce que l'on veut dans le bloc "catch", soit afficher l'erreur en question (ce qui peut être utile dans la phase de développement du site), soit faire tout autre chose...

le champ pseudo est effectivement en unique mais je veux effectuer un test avant la tentative d'inscription pour éviter que SQL ne me retourne l'erreur "barbare" 1062 (me disant que le champ est identique à un autre).

... et donc si tu fais comme je t'ai montré avec le bloc try/catch pour l'exemple d'insertion dans ce précédent message, tu verras qu'en cas de doublon cela ne fait rien d'autre que de passer la variable "$pseudo_multiple" à true, simplement parce que cela nous arrange de faire ainsi. Et le code continue et l'on pourra utiliser "$pseudo_multiple" pour dire que (si on est passé dans le catch c'est que la requête ne fonctionne pas et très probablement dû à un pb doublon) le pseudo est déjà utilisé.
Fais des tests !
Dans l'absolu l'erreur pourrait venir aussi de la table "membres" qui n'existerait pas ou que ta requête est mal écrite. Mais bon une fois que ton script est rodé... Cela dit rien ne t'empêche de faire plusieurs bloc try/catch pour distinguer plus précisément les erreurs.

Le mot "minimum" sous-entendrait-il qu'il y a mieux encore ? Si oui, quoi ?

Oui sha512 si tu préfère. Mais bon déjà sha256 offre des performances normalement suffisantes et puis il ne faut pas croire que cela soit le principal pb de sécurité. Quelque soit le hashage un mot de passe trop court et commun est mort d'avance.

[Black_Layer]

Il suffit juste de lui indiquer le lien vers ton fichier

Dans ce cas je vais voir pour la rajouter mais j'aime bien comprendre le code que j'utilise donc je vais tenter de la comprendre complètement avant.

dans le "require_once"

Pourquoi require_once plutôt que require ? dans les faqs, il est dit que require_once n'est appelé qu'une seule fois... mais je ne comprends pas car require aussi !

Tu n'as pas encore compris ?

Si si, après de multiples relectures, ça y est j'ai compris le système d'exception (désolé, j'ai parfois un peu de mal avec les nouveautés).

... et donc si tu fais comme je t'ai montré avec le bloc try/catch pour l'exemple d'insertion dans ce précédent message, tu verras qu'en cas de doublon cela ne fait rien d'autre que de passer la variable "$pseudo_multiple" à true, simplement parce que cela nous arrange de faire ainsi. Et le code continue et l'on pourra utiliser "$pseudo_multiple" pour dire que (si on est passé dans le catch c'est que la requête ne fonctionne pas et très probablement dû à un pb doublon) le pseudo est déjà utilisé.
Fais des tests !

Jutement j'en fais des tests et ce qu'on peut dire c'est que je galère.
En effet, si je pratique de la sorte, dans le try, j'exécute une requête insert sauf que comme justement mon login est en champ unique, ça crée dans ma bdd une erreur 1062 Duplicate entry ; ce qui est logique mais du coup ça ne va pas plus loin et ça m'affiche une page blanche (même si je mets un echo dans le catch) !!!!

Pour palier à celà, j'ai donc envisagé de faire le test avec les fameux select count(*) et fetchColumn ; à savoir que ce test est fait avant l'insert grâce jutement au select.
Le problème, c'est que ça ne fonctionne pas non plus !!!

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
// [...]
require ("connexion.php");
 
				 // on recherche si ce login est déjà utilisé par un autre membre
 
				 	$log_in = $_POST['login'];
					$reqcount = "SELECT count(*) FROM users WHERE user_login=:log";
					$sth = $bdd->prepare($reqcount);
					$sth->bindParam(':log', $log_in);
					$sth->execute();
 
					$result = $sth->fetchColumn();
					//echo $result;
 
				 //$sql = 'SELECT count(*) FROM membre WHERE login="'.mysql_escape_string($_POST['login']).'"'; 
 
 
					 if ($result>0) 
					 { 
							$nom = $_POST['name'];
							$pseudo = $_POST['login'];
							$motdepasse = $_POST['pass'];
							$email = $_POST['email'];
							$localisation = $_POST['location'];
							$site = $_POST['website']; 
							$pass = hash("sha256",$motdepasse);
							$query = 'INSERT INTO users (user_login, user_password, user_email, user_name, user_foundation, user_location, user_website) VALUES (:pseudo, :pass, :email, :nom, now(), :localisation, :site)';
							$stmt = $bdd->prepare($query);
							$stmt->bindParam(':pseudo', $pseudo);
							$stmt->bindParam(':pass', $pass);
							$stmt->bindParam(':email', $email);
							$stmt->bindParam(':nom', $nom);
							$stmt->bindParam(':localisation', $localisation);
							$stmt->bindParam(':site', $site);
							$passed = $stmt->execute();
									if($passed){
										echo "passed";
									} 
									else {
										echo "failed";
									} 
							exit(); 
					}
					else 
					{ 
						$erreur = 'Un membre possède déjà ce login.'; 
					} 
// [...]

Si je rentre un login existant, ce code retourne... failed !!!
C'est à s'en arracher les yeux !!

Oui sha512 si tu préfère. Mais bon déjà sha256 offre des performances normalement suffisantes

J'avoue, pour le coup la question était juste à titre informatif.

Et tout cas, au risque de me répéter, merci de ton aide ; elle m'est très précieuse !!

[ABCIWEB]

Pourquoi require_once plutôt que require ? dans les faqs, il est dit que require_once n'est appelé qu'une seule fois... mais je ne comprends pas car require aussi !

Nan, require_once ne peut être appelé qu'une seule fois, require peut être appelé plusieurs fois.

Jutement j'en fais des tests et ce qu'on peut dire c'est que je galère.
En effet, si je pratique de la sorte, dans le try, j'exécute une requête insert sauf que comme justement mon login est en champ unique, ça crée dans ma bdd une erreur 1062 Duplicate entry ; ce qui est logique mais du coup ça ne va pas plus loin et ça m'affiche une page blanche (même si je mets un echo dans le catch) !!!!

Sans doute que tu as oublié d'indiquer l'option PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION et dans ce cas les erreurs ne sont pas interceptées ni gérées par le try/catch

Pour palier à celà, j'ai donc envisagé de faire le test avec les fameux select count(*) et fetchColumn ; à savoir que ce test est fait avant l'insert grâce jutement au select.
Le problème, c'est que ça ne fonctionne pas non plus !!!

C'est dans ces cas qu'on utilise echo $e->getMessage(); dans le bloc catch pour avoir plus d'information sur la cause de l'erreur. Ce qui t'aurais sans doute indiqué "duplicate entry..." en effet c'est si $result == 0 que tu devrais faire l'insertion

Quand on utilise de nouvelles techniques il faut avoir une page de travail minimaliste pour faire pas mal de test et ensuite on intègre dans le code final. Si tu vas trop vite en ne faisant pas assez de tests et que tu veux tout de suite tester en situation réelle tu perdras finalement beaucoup de temps car il sera plus difficile d'isoler les erreurs.
Par exemple fais des tests avec simplement mes bouts de code dans une page séparée puis modifies les options, et triture le code jusqu'à ce que tu aies bien saisi le fonctionnement (sans oublier de consulter la doc et les exemples de la doc concernant les fonctions que tu emploies).

EDIT : Eventuellement si tu pouvais renommer le titre de ton premier message par "migration de mysql vers pdo" ou quelque chose dans le genre cela me semblerait plus approprié car pour l'instant on a pas parlé de formulaire d'inscription et le sujet évoqué est centré sur le passage vers pdo (je dis cela pour faciliter les recherches des utilisateurs du forum).

[Black_Layer]

Nan, require_once ne peut être appelé qu'une seule fois, require peut être appelé plusieurs fois.

L'instruction require_once est identique à require mise à part que PHP vérifie si le fichier a déjà été inclus et si c'est le cas, ne l'inclut pas une deuxième fois.

Mis à part le cas où je suis un gros boulet et où j'écris donc deux fois l'inclusion d'un même fichier, ce cas de figure peut-il se produire autrement ?

Sans doute que tu as oublié d'indiquer l'option PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION et dans ce cas les erreurs ne sont pas interceptées ni gérées par le try/catch

Non non, je n'ai pas oublié ; je ne sais pas ce qui se passe avec mon hébergeur (one.com) mais dès que le code dans le try a planté, il ne va même pas au catch (j'ai essayé avec un echo), il m'affiche directement une page blanche !!

C'est dans ces cas qu'on utilise echo $e->getMessage(); [...] en effet c'est si $result == 0 que tu devrais faire l'insertion

Hé ouais, à force de coder jusqu'à 3 heures du matin en recopiant certaines lignes de codes prises sur le net avec la fatigue, on fait n'importe quoi !
Morale de cette histoire : pensez à dormir

Si tu vas trop vite en ne faisant pas assez de tests et que tu veux tout de suite tester en situation réelle tu perdras finalement beaucoup de temps car il sera plus difficile d'isoler les erreurs.

Ayant fait pas mal de développement lors de mes études (cobol, fortran, c,c++,c#, java, etc), c'est pas moi qui vais dire le contraire.
Cependant, il est impératif que le site "fini" soit en ligne dans 2 mois et je suis bien loin d'avoir fini (certaines pages sont déjà prêtes, j'ai une ébauche de css mais encore pas mal de boulot de codage sur la partie "blog") et c'est pour cette raison que j'essaye de sauter certaines étapes (parfois à tort comme dans le cas présent, parfois à raison dans d'autres cas non cités puisque n'ayant pas posé de problèmes).
Mais sinon, je suis entièrement d'accord avec toi, je fais ce qu'il ne faut pas faire !

Eventuellement si tu pouvais renommer le titre de ton premier message

Je l'avais envisagé mais je ne savais pas quoi mettre ; c'est donc chose faite.

Concernant les options PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION etc. il faut bien prendre conscience qu'elles valent pour toutes la durée d'exécution du script, * à moins bien sûr de changer leur valeur plus loin dans ton script avec setAttribute (comme montré dans mes exemples).

Donc si par exemple du déclare l'option PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION dans la classe de connexion citée plus haut - et qu'on appelle simplement en faisant $bdd = C_PDO::getC(); - cela implique que tu devras gérer les erreurs avec un bloc try/catch (comme dans mes exemples) pour toutes tes requêtes (* à moins bien sûr...) Ce n'est généralement pas un problème mais il faut bien s'en souvenir car sinon pour toute erreur tu auras un message d'erreur détaillé qui commencera par "uncautch exception ..." même pour les visiteurs.

Du coup cette idée qui me semblait géniale le paraît un peu moins.
Non pas que je ne sois pas capable de mettre un try/catch, mais que je pourrais oublier par-ci par-là et ça ne serait pas propre !!

[ABCIWEB]

Du coup cette idée qui me semblait géniale le paraît un peu moins.
Non pas que je ne sois pas capable de mettre un try/catch, mais que je pourrais oublier par-ci par-là et ça ne serait pas propre !!

Bah oui et en même temps c'est pas propre à cette option. A la base on défini les options qui sont sensées nous servir le plus souvent et ensuite on emploie setAttibute au coup par coup suivant des besoins spécifiques. Si tu utilises principalement le mode "exception" et que tu l'a configuré dans ta connexion, rien ne t'empêche par la suite de faire à tout moment

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$bdd->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT);

pour revenir à la configuration de pdo par défaut.

T'as bien fait de passer à pdo. Non seulement parce que l'extension mysql sera obsolète en php5.5, mais en plus à l'usage pdo est plus agréable à écrire et accessoirement plus portable