Je ne sais pas trop ou mettre mon message car ce dernier concerne un
CMS, dans mon cas, c'est Joomla, que j'ai installé en local sur ma
becane Linux Ubuntu 8.04 LTS server ; toute l'installation de Joomla
s'est passé sans problème, sauf qu'a l'exécution, j'ai ces erreurs
suivantes et je ne sais pas d'ou cela peut provenir, s'agit il de
permissions de repertoires ??? Ou d'un probleme propre a l'installation ?
J'ai donc ces trois erreurs :
Warning: session_start() [function.session-start]: Cannot send session
cookie - headers already sent by (output started at
/var/www/configuration.php:2) in
/var/www/libraries/joomla/session/session.php on line 423
Warning: session_start() [function.session-start]: Cannot send session
cache limiter - headers already sent (output started at
/var/www/configuration.php:2) in
/var/www/libraries/joomla/session/session.php on line 423
Warning: Cannot modify header information - headers already sent by
(output started at /var/www/configuration.php:2) in
/var/www/libraries/joomla/session/session.php on line 426
Avec ces dernières, impossible de passer dans le repertoire
administrator et de faire des modifications du CMS en local, or distant
et sur un repertoire de l'hebergeur OVH, aucun pépin !
Avez vous eu ce genre d'erreurs ? Pouvez vous me conseiller ?
Un de tes fichiers est pourri, au hasard celui que tu as édité pour changer les paramètres d'accès à la base. Il y a quelque part un caractère qui traîne avant un <?php de première ligne ou après un ?> de fin de fichier. Les trois plus classiques sont : - ESPACE - CR / LF / CRLF - BOM
HTH JG
PS: rappel des options de "cat" permettant de voir les caractères non imprimables et les fins de ligne: cat -vet toto.php|more
Un de tes fichiers est pourri, au hasard celui que tu as édité pour
changer les paramètres d'accès à la base.
Il y a quelque part un caractère qui traîne avant un <?php de première
ligne ou après un ?> de fin de fichier. Les trois plus classiques sont :
- ESPACE
- CR / LF / CRLF
- BOM
HTH
JG
PS: rappel des options de "cat" permettant de voir les caractères non
imprimables et les fins de ligne:
cat -vet toto.php|more
Un de tes fichiers est pourri, au hasard celui que tu as édité pour changer les paramètres d'accès à la base. Il y a quelque part un caractère qui traîne avant un <?php de première ligne ou après un ?> de fin de fichier. Les trois plus classiques sont : - ESPACE - CR / LF / CRLF - BOM
HTH JG
PS: rappel des options de "cat" permettant de voir les caractères non imprimables et les fins de ligne: cat -vet toto.php|more
Regis
Merci John, en effet, un espace + un CRLF, mais j'ai galéré pour le trouver, heureusement que le cat a permi de le visualiser, je crois que le mieux c'est d'utiliser des editeurs de fichiers bruts, pas ceux clinquant sous l'interface graphique, ca peut poser probleme.
Merci encore, je croyais que c'etait un probleme purement PHP, mais je ne savais pas que ce genre d'erreurs hors <? ?> pouvait exister !!!
Bien amicalement,
Régis.
--
Merci John, en effet, un espace + un CRLF, mais j'ai galéré pour le
trouver, heureusement que le cat a permi de le visualiser, je crois que
le mieux c'est d'utiliser des editeurs de fichiers bruts, pas ceux
clinquant sous l'interface graphique, ca peut poser probleme.
Merci encore, je croyais que c'etait un probleme purement PHP, mais je
ne savais pas que ce genre d'erreurs hors <? ?> pouvait exister !!!
Merci John, en effet, un espace + un CRLF, mais j'ai galéré pour le trouver, heureusement que le cat a permi de le visualiser, je crois que le mieux c'est d'utiliser des editeurs de fichiers bruts, pas ceux clinquant sous l'interface graphique, ca peut poser probleme.
Merci encore, je croyais que c'etait un probleme purement PHP, mais je ne savais pas que ce genre d'erreurs hors <? ?> pouvait exister !!!
Bien amicalement,
Régis.
--
John GALLET
> Merci John, en effet, un espace + un CRLF, mais j'ai galéré pour le trouver,
Classique.
heureusement que le cat a permi de le visualiser,
Pas pour rien que je le "rappelais" ;-)
je crois que le mieux c'est d'utiliser des editeurs de fichiers bruts, pas ceux clinquant sous l'interface graphique, ca peut poser probleme.
edlin && vi RULEZZZZ :-)
Merci encore, je croyais que c'etait un probleme purement PHP, mais je ne savais pas que ce genre d'erreurs hors <? ?> pouvait exister !!!
Ce n'est pas une erreur, c'est le fonctionnement de php: sauf à mettre en place de l'output buffering (ob_start ou auto dans php.ini) un caractère quel qu'il soit déclenche l'envoi du flux html, y compris nécessairement les headers http. Donc si on essaie plus tard d'en remettre une couche, c'est cuit. Pour une fois que le message d'erreur est parfaitement explicite...
a++; JG
> Merci John, en effet, un espace + un CRLF, mais j'ai galéré pour le
trouver,
Classique.
heureusement que le cat a permi de le visualiser,
Pas pour rien que je le "rappelais" ;-)
je crois que le mieux c'est d'utiliser des editeurs de fichiers bruts, pas ceux
clinquant sous l'interface graphique, ca peut poser probleme.
edlin && vi RULEZZZZ :-)
Merci encore, je croyais que c'etait un probleme purement PHP, mais je
ne savais pas que ce genre d'erreurs hors <? ?> pouvait exister !!!
Ce n'est pas une erreur, c'est le fonctionnement de php: sauf à mettre
en place de l'output buffering (ob_start ou auto dans php.ini) un
caractère quel qu'il soit déclenche l'envoi du flux html, y compris
nécessairement les headers http. Donc si on essaie plus tard d'en
remettre une couche, c'est cuit. Pour une fois que le message d'erreur
est parfaitement explicite...
> Merci John, en effet, un espace + un CRLF, mais j'ai galéré pour le trouver,
Classique.
heureusement que le cat a permi de le visualiser,
Pas pour rien que je le "rappelais" ;-)
je crois que le mieux c'est d'utiliser des editeurs de fichiers bruts, pas ceux clinquant sous l'interface graphique, ca peut poser probleme.
edlin && vi RULEZZZZ :-)
Merci encore, je croyais que c'etait un probleme purement PHP, mais je ne savais pas que ce genre d'erreurs hors <? ?> pouvait exister !!!
Ce n'est pas une erreur, c'est le fonctionnement de php: sauf à mettre en place de l'output buffering (ob_start ou auto dans php.ini) un caractère quel qu'il soit déclenche l'envoi du flux html, y compris nécessairement les headers http. Donc si on essaie plus tard d'en remettre une couche, c'est cuit. Pour une fois que le message d'erreur est parfaitement explicite...
a++; JG
Nico D\.
John GALLET a écrit :
Merci John, en effet, un espace + un CRLF, mais j'ai galéré pour le trouver,
Classique.
Bonjour, jsute un petit truc pour éviter les caractères à la fin des fichiers, c'est tout simplement d'omettre le ?> de fermeture qui n'est pas obligatoire (PHP considère la fin du fichier comme la fin du script).
-- Nico D.
John GALLET a écrit :
Merci John, en effet, un espace + un CRLF, mais j'ai galéré pour le
trouver,
Classique.
Bonjour,
jsute un petit truc pour éviter les caractères à la fin des fichiers,
c'est tout simplement d'omettre le ?> de fermeture qui n'est pas
obligatoire (PHP considère la fin du fichier comme la fin du script).
Merci John, en effet, un espace + un CRLF, mais j'ai galéré pour le trouver,
Classique.
Bonjour, jsute un petit truc pour éviter les caractères à la fin des fichiers, c'est tout simplement d'omettre le ?> de fermeture qui n'est pas obligatoire (PHP considère la fin du fichier comme la fin du script).
-- Nico D.
Pascal PONCET
Nico D. a écrit :
jsute un petit truc pour éviter les caractères à la fin des fichiers, c'est tout simplement d'omettre le ?> de fermeture qui n'est pas obligatoire (PHP considère la fin du fichier comme la fin du script).
Bonjour,
C'est vrai, et même recommandé par Zend (dans leur framework, je crois).
Et pourtant... ça risque de poser problème avec les éditeurs à colorations syntaxique, et encore plus avec les IDE qui vont coller des icônes d'alertes sur tous les fichiers ! Je pense même que le plugin Zend Studio pour Eclipse n'échappe pas à cette règle, ce qui est un comble !!!
J'utilise Eclipse ou NetBeans pour les projets moyens-lourds, et Notepad++ en appoint ou pour des projets plus légers. Ils me permettent tous de voir en un clic les caractères invisibles. Et, de fait, je ne connais plus ce problème de sortie avant en-tête depuis bien longtemps, alors que je ferme normalement ma balise PHP.
Cordialement, Pascal
Nico D. a écrit :
jsute un petit truc pour éviter les caractères à la fin des fichiers,
c'est tout simplement d'omettre le ?> de fermeture qui n'est pas
obligatoire (PHP considère la fin du fichier comme la fin du script).
Bonjour,
C'est vrai, et même recommandé par Zend (dans leur framework, je crois).
Et pourtant... ça risque de poser problème avec les éditeurs à
colorations syntaxique, et encore plus avec les IDE qui vont coller des
icônes d'alertes sur tous les fichiers !
Je pense même que le plugin Zend Studio pour Eclipse n'échappe pas à
cette règle, ce qui est un comble !!!
J'utilise Eclipse ou NetBeans pour les projets moyens-lourds, et
Notepad++ en appoint ou pour des projets plus légers.
Ils me permettent tous de voir en un clic les caractères invisibles.
Et, de fait, je ne connais plus ce problème de sortie avant en-tête
depuis bien longtemps, alors que je ferme normalement ma balise PHP.
jsute un petit truc pour éviter les caractères à la fin des fichiers, c'est tout simplement d'omettre le ?> de fermeture qui n'est pas obligatoire (PHP considère la fin du fichier comme la fin du script).
Bonjour,
C'est vrai, et même recommandé par Zend (dans leur framework, je crois).
Et pourtant... ça risque de poser problème avec les éditeurs à colorations syntaxique, et encore plus avec les IDE qui vont coller des icônes d'alertes sur tous les fichiers ! Je pense même que le plugin Zend Studio pour Eclipse n'échappe pas à cette règle, ce qui est un comble !!!
J'utilise Eclipse ou NetBeans pour les projets moyens-lourds, et Notepad++ en appoint ou pour des projets plus légers. Ils me permettent tous de voir en un clic les caractères invisibles. Et, de fait, je ne connais plus ce problème de sortie avant en-tête depuis bien longtemps, alors que je ferme normalement ma balise PHP.
