Ses derniers messages sur les forums
Ce n'est pas vraiment une question de PHP. C'est un problème lié à HTTP. Nous utilisons des scripts PHP pour générer des requêtes HTTP. Ces requêtes sont composées d'un en-tête et d'un corps.
Si le code produit du code à destination du corps de la requête HTTP, PHP commence par envoyer les en-têtes.
Les sessions sont généralement basées sur l'échange d'un cookie entre le serveur et le client HTTP, et que le cookie se trouve dans les en-têtes.
PHP n'attend pas la fin d'exécution du script pour commencer à envoyer des données. Il le fait dès que possible.
Tout ces éléments font que l'usage des fonctions header et session_start vont logiquement échouer si les en-têtes sont déjà envoyés.
Bref, il y a quelques bonnes pratiques qui permettent d'éviter le problème :
- l'usage des fonction de contrôle du buffer de sortie (ob_start)
- ne jamais utiliser echo, printf, etc endehors d'un contexte approprié.
- commencer tout fichier PHP inclus par <?php et ne jamais le fermer, à l'exception des fichiers templates.
- utiliser un éditeur de texte qui ne rajoute pas de saut de ligne à la fin des fichiers (comme cette merde d'Eclipse en son temps)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Quel est le rapport avec la choucroute ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(dark_nemo) Ben non, ça affiche le premier, 'fin, ça dépend ce que tu appelle le dernier et le premier.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(bibi) Je m'en fiche d'où du pense que viennent les erreurs :p Si tu ne trouve pas de solution avec ton interprétation des erreurs, c'est peut-être que tu en as une mauvaise lecture. Alors donnes !
En ce qui concerne DOM, c'est une idée, mais il ne faut pas oublier que DOM est avant tout un parser XML, qui attend des documents valides. Ceci dit, ce n'est pas une mauvaise idée.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Tu devrais installer un correcteur orthographique. Merci pour nos yeux.
Et aussi lire les conditions d'utilisation des forum, même raison (parce que La Globule ne s'est pas décarcassé pour rien).
Ceci dit, c'est normal que ton code affiche tout. C'est ce que tu lui demande. Il n'y a de notion de pagination nulle part. Ni dans la requête SQL, ni dans le template Smarty. Essaye de chercher avec ce mot-clé, « pagination », qui te permettra de trouver ce que tu souhaite.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Pour des raisons de sécurité, c'est imposible* en Javascript.
(*) En fait tu peux, mais ce sera spécifique au navigateur, que ça utilisera ActiveX, Flash, Java ou des objets Javascript spéciaux.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Pour le composant COM, je ne me prononcerait pas, je ne fais pas dans les microsofteries.
En ce qui concerne la classe dont tu as parlé plus haut, ce serait intéressant que tu nous donnes les messages d'erreur. Parce que de toute façon, si le script PHP ne peut pas sortir, tu ne pourras pas récupérer les pages et créer des archives web.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Modifier $_POST n'est pas stupide, ça manque juste d'élégance. Certaines personnes justifie la modification de $_POST pour des raisons de performances.
La gestion des erreurs n'est pas évidente, car il faut distinguer différents types d'erreurs. Les erreurs liées au fonctionnement du site et les erreurs liées à la logique de ton application.
Et tu t'en es bien rendu compte. Les erreurs générées par l'usage de la base de données ne doivent pas être traitées de la même manière que les erreurs de logique (mauvais prénom, etc).
Pour le problème de collision de noms de variables, c'est la raison pour laquelle j'ai précisé un préfixe dans la fonction extract.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Je plus-une dark_nemo sur mysql_real_escape_string et print_r (même si je préfère var_dump).
Ensuite quelques points :
<?php
//Mesure de sécurité.
$_POST['pseudo'] = mysql_real_escape_string(htmlentities($_POST['pseudo']));
Ceci est tout sauf une mesure de sécurité. Tout d'abord, tu modifie le tableau $_POST. C'est problématique car tu modifie la sémantique d'une donnée que tout le monde comprend comme étant l'ensemble des paramètres HTTP POST. En modifiant le tableau, tu prends le risque « d'oublier » que tu as modifier ce tableau. De plus, une mesure de sécurité doit être prise au bon moment. Pour mysql_real_escape_string, ceci correspond à l'insertion en base. Pour htmlentities, au moment de la création du corps de la réponse HTTP. De plus, htmlentities doit être utilisé différemment selon que ta donnée prendra place dans un text node ou un attribute node.
<?php
$_POST['pseudo'] = addslashes($_POST['pseudo']);
Ah ben tu as oublié que tu as déjà « protégé » les données soumises. Mais pourquoi tant de haine et utiliser addslashes ?
<?php
header('Location: ?pages=erreur&err=20');
1. La redirection doit être utilisée avec parcimonie (c'est l'enfer à déboguer, et ça contraint à une requête supplémentaire alors qu'on sait déjà quoi faire).
2. Je ne crois pas que ton URL est correctement formée
3. Les codes d'erreur en dur, c'est mal ©
Pour en revenir à ton problème, on s'en fout que tu rencontres des erreurs : on veut les voir ! Donc dis-nous quelles sont les erreurs qui surviennent lors de la mise en production.
Et par la même : versions PHP, modules installés, plate-forme de dev et celle de déploiement, etc
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(aquievreux) Au temps pour moi, je n'ai pas testé, et j'ai oublié d'expliquer.
Je vais repaster en ajoutant quelques commentaires :
<?php
/**
* \param array& $array Référence sur le tableau inspecté
* \param (string|int) $key Clé ou index du tableau
* \param mixed $default Valeur à retourner en cas d'absence de la valeur
* \return mixed Valeur associée à la clé dans le tableau, ou la
* valeur par défaut.
*/
function array_get(& $array, $key, $default = '')
{
return isset($array[$key]) ? $array[$key] : $default ;
}
/** Requerche les données associées à un client dans un tableau.
* \param array& $array Référence sur le tableau issu de la requête du
* formulaire de soumission.
* \return array Le tableau contenant les données pertinentes.
*/
function client_reception(& $requete)
{
$filtre = array() ;
// Récupération des données
$filtre['num'] = array_get($requete, 'num_client') ;
$filtre['prenom'] = array_get($requete, 'prenom_client') ;
/* ... la suite des attributs à récupérer */
$filtre['date_expir'] = array_get($requete, 'date_expir_client') ;
return $filtre ;
}
// La fonction client_reception garanti que l'ensemble des attributs nécessairent au
// concept de client sont définis, et initialisés.
$client = client_reception($_POST) ;
// À partir de là, tu utilises $client pour afficher et manipuler les données issues du
// formulaire.
export($client) ;
echo $nom ;
export($client, EXTR_OVERWRITE | EXTR_PREFIX_ALL, 'client_') ;
echo $client_nom ;
(dark_nemo) strip_tags n'est pas une bonne idée, ça introduit plus de bogues que ce n'est pratique. La seule solution qui vaille le coup, à mon sens, c'est htmlentities (auquel tu as fait référence) et htmlspecialchars. Quand à filter_var, ce n'est pas destiné à sécuriser les données, mais je crois que c'est un problème qui sort du cadre de la question de notre amie.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
