Salut,

Vous aurez peut-être qu'un sujet Erreurs fréquentes en PHP / SQL vient de faire son apparition dans le forum PHP. Il a pour but de réduire les topics où les solutions aux problèmes sont relativement simples, quand on les connait. Car vous avez sans doute dû le remarquer, quelques fois, plusieurs fois par jour, de nombreux topics ayant un problème similaire sont créés.

Dans ce sujet, vous pourrez réagir à ce sujet, proposer des questions/réponses à ajouter aux Erreurs fréquentes mais aussi, si vous avez simplement un commentaire à faire.



Bonne soirée à vous.

Salut,
je voulais préciser que l'erreur des en-têtes déjà envoyés ne se produit avec session_start() que si celui-ci utilise les cookies pour stocker l'identifiant de session. Puisque ce qui pose problème c'est l'enregistrement du cookie en fait.

Citation : anonymousguest

Salut,
je voulais préciser que l'erreur des en-têtes déjà envoyés ne se produit avec session_start() que si celui-ci utilise les cookies pour stocker l'identifiant de session. Puisque ce qui pose problème c'est l'enregistrement du cookie en fait.

C'est corrigé merci.

Je crois que tu n'as pas bien interprété les propos d'anonymousguest...
En fait les headers (en-têtes) HTTP doivent être, selon le protocole HTTP, envoyés dans la réponse avant le corps (la page HTML en général).
Du coup si on commence à afficher du texte, on ne peut plus rajouter d'en-têtes car PHP a déjà envoyé les en-têtes et le début du corps au navigateur (il envoie au fur et à mesure), et c'est là le problème.
Avec ob_start() aucun texte n'est envoyé au navigateur de suite, tout est mis dans un buffer puis envoyé à l'appel de ob_end_flush().
Le rapport avec les cookies, c'est que les cookies à placer sont précisés dans les en-têtes.
Mais session_start() n'a besoin de créer un cookie que si c'est dans un cookie que l'on veut placer l'ID.
C'est ce qu'à voulu dire anonymousguest.
Edit : Enfin ce que je veux dire c'est que même si le serveur n'utilise pas les cookies pour stocker l'ID de session on peut avoir cette erreur en appelant header() / setcookie() / tout autre fonction nécessitant un envoi d'en-tête.

Edit 2 : Sinon, c'est pas très important mais avec foreach en PHP 5 on peut aussi itérer des objets.
Et au passage, j'ai oublié de le préciser mais je trouve que ce topic est une excellente idée.

Notice: Use of undefined constant

Cette erreur peut se produire lorsque vous avez oublié le $ au début d'une variable.


Avertissement retourné :
Notice: Use of undefined constant maVariable - assumed 'maVariable' in /var/www/blog/index.php on line 9

Egalement lorsque l'on omet les cotes sur l'index (string) d'un tableau (erreurs très fréquentes chez les débutants).

Avertissement retourné :
Notice: Use of undefined constant titi - assumed 'titi' in /var/www/blog/index.php on line 7

Mmh, je me permettrais ausis de rajouter un truc sur les parses error... Si l'erreur "Parse Error - Unexpected $end in [...]", c'est parce qu'il y a eu un oubli d'une accolade fermante.

Ça arrive aussi si tu oublies une parenthèse fermante ou un point-virgule.

J'ai mis à jour en conséquence.

Il faudrait lister les erreurs SQL aussi cf le titre du sujet.
Notamment Column count doesn't match value count at row X, qui revient souvent, et qui apparaît lorsque le nombre de valeurs précisées dans une liste de valeurs à insérer ne coincide pas avec le nombre de champs de la table.
Exemple :
=> Il manque la valeur pour le champ champ2 dans la première liste de valeurs et il y a une valeur en trop dans la deuxième liste de valeurs.
Ces deux problèmes génèreront l'erreur citée plus haut.

Il y a souvent des questions à propos des différents encodages, utf-8 et iso-8859-1.
Le problème peut se présenter sous 2 formes distinctes :

1. les caractères spéciaux (caractères accentués notamment) sont remplacés par des points d'interrogation ou
2. les caractères spéciaux sont remplacés par des trucs barbares du style : é.

Dans le premier cas, ça veut souvent dire que le navigateur essaie d'interprêter en utf-8 un caractère qui est en iso-8859-1. Le second cas correspond au phénomène inverse.
NB : pour connaître l'encodage utilisé pour interprêter une page sous firefox il suffit d'aller dans : Affichage > Encodage des caractères.

Les causes sont multiples, l'encodage est présent un peu partout, il suffit de faire une erreur à un endroit pour fausser le tout.
L'encodage doit être configuré correctement pour :

• les fichiers en eux-même, dans notepad++ on peut définir l'encodage dans le menu "Format". (Si vous voulez utiliser iso-8859-1, sélectionnez : "Encode in ANSI".)
• Dans MySQL, vous pouvez définir l'interclassement par défaut des bdd, l'interclassement des tables et celui des champs indépendamment.
• Dans les en-têtes HTTP envoyés automatiquement par PHP. Cet encodage est défini par la directive default_charset du php.ini. Pour ne pas envoyer d'encodage, il suffit de mettre comme valeur une chaîne vide (ou de commenter la ligne puisque c'est la valeur par défaut).
• Dans les fichiers html. En effet la balise "<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />" permet de définir l'encodage à utiliser pour la page.

Salut,

Cela na pas trop de rapports avec le php et mysql en lui-même mais son développement sur les serveurs de free.

L'ajout du dossier sessions à la racine du FTP, car cette erreur est très courante mais très peu détaillée sur le net.

@+

Sperca

ceci est un peu faux http://www.siteduzero.com/forum-83-193950-1732954.html#r1732954
.
Il suffit juste de mettre ob_start au debut

ob_end_flush() éteint la tamporisation de sortie, je ne vois pas le problème ?
La doc est très claire à ce sujet : http://fr.php.net/manual/fr/function.ob-start.php

ben pourtant je met que ob_start et sa marche

Bah sans doute ça marche mais, selon moi, quand on ouvre la tamporisation, on doit la fermer.
Après, si ça marche tant mieux mais c'est mieux de faire les choses bien.

D'ailleurs faudra que je fasse un modèle en zCode pour les gens qui veulent proposer des erreurs fréquentes car là, je m'y retrouve plus entre les gens qui proposent des corrections ou qui proposent des questions/réponses.

Le ob_end_flush() force l'envoi du buffer avant la fin du script, mais dans tous les cas le contenu du buffer est envoyé au client à la fin du script.

C'est comme le mysql_close(), si c'est pour le placer à la fin du script, ça sert à rien, mais si c'est pour le mettre bien avant la fin du script, ça peut servir à un peu moins que rien.

Tu devrais préciser que php est un peu flou dans les numéros de lignes en erreur. en général, si manque un ; en fin de ligne, il nous indiquera un parse error au n° de ligne suivante (ce qui peut se comprendre). Donc penser à regarder au dessus.
Et en cas d'un oubli de fermer la dernière accolade, il nous met une erreur sur une ligne, en général la dernière, qui est :
}
c'est assez déroutant de s'entendre dire qu'y a une parse error sur une ligne avec juste ça!

Euh nan hin, PHP est bien précis dans la ligne qui concerne l'erreur.
Si t'oublies un ;, PHP considère que l'instruction n'est pas finie (ce qui est le cas), il lit le caractère suivant, un \n (ou\n\r), tombe sur un truc inattendu et indique qu'il trouve un truc inattendu à cette ligne là.

C'est tout à fait logique.

je dis pas que c'est pas logique.
je dis juste que c'est le numéro de ligne suivant.

Resource id #5

Cette erreur survient lorsque vous avez utilisé le résultat d'un mysql_query() directement avec une fonction d'affichage (echo, print, print_r(), ... )



Le résultat que mysql_query() renvoi lors d'une requête SELECT retourne une ressource qui ne peut-être exploitée qu'avec les fonctions réservées à cet effet et qui sont pour les principales et plus utilisées :

• mysql_fetch_assoc()
• mysql_result()
• mysql_fetch_array()
• mysql_fetch_row()