Merci pour le lien.
J'ai essayé session_start avant le header mais dans mon cas cela ne fonctionne pas.

Voici l'adresse de la page sur les variables superglobales : https://openclassrooms.com/courses/concevez-votre-site-web-avec-php-et-mysql/variables-superglobales-sessions-et-cookies

et voici une petite copie d'écran alors ils ne parle pas de le placer avant le header mais à mon avis tu peut essayer
[img]http://moodle.livehost.fr/Capture.PNG[/img]

[quote="DD-78"]Par contre dans le code que tu présentes il y a des lignes vides entre session_start et le header ce qui est strictement interdit ![/quote]
Pas du tout, ce sont les lignes vides [b]en HTML[/b] et pas en PHP qui sont à proscrire avant la fonction header().

Bonjour,

Merci pour ton conseil mineyou, peux-tu me donner l’adresse http de openclassroom où ils disent de placer session_start avant le header ?

Par contre dans le code que tu présentes il y a des lignes vides entre session_start et le header ce qui est strictement interdit !

Concernant OVH je retiens ton conseil mais par rapport à 1 & 1 c’est moi qui était en erreur comme je l’ai cité précédemment.

Cordialement.

<?php

session_start();

header('Content-type:text/html; charset=UTF-8');	// encodage UTF-8

Bonjour,
Je te conseil de mettre le session_start en tout debut de page, comme ceci:

[php]<?php

session_start();

header('Content-type:text/html; charset=UTF-8'); // encodage UTF-8[/php]


Sur openclassroom ils disent qu'il faut bien le mettre au debut sinon il ne fonctionne pas .
Et si tu veut changer d'hébergeur OVH est super =)

Merci aussi à @rthur.

Bonjour,

Je cite "au final je note que le conf 1&1 par défaut colle plus à la réalité et que sur OVH tu peux faire des bêtises sans t'en rendre compte".
Tout à fait d’accord avec toi car le fait que le code fonctionne chez OVH m’a empêché de voir mes erreurs rapidement.

Tu n’as pas à être désolé pour le BOM car c’était à moi de réfléchir plus.

Pour moi tout ceci est positif, ton aide Moogli et apprendre qu’il faut être très méfiant avec les codes en PHP selon les serveurs.

Cordialement.

pour ce qui est des lignes / espace vide, idem il ne faut rien mettre avant la fonction header ou un session_start (qui envoi une entête cookie).
Les entêtes doivent toujours est "envoyées" avant tout affichage et un espace ou un ligne vide en dehors du code php c'est un affichage. Les bonne pratique en php (PSR-XX) veulent que l'on commence à la première ligne par un <?php et que, si le fichier finit par du php, on ne mette pas de ?> qui est optionnel (et du coup pas de problème de ligne vide ou de caractère invisible qui s'insère après le ?> et peux générer ce genre de problème lors d'une inclusion du fichier.
Le coup du BOM utf-8 est vieux comme php, je m'en veux de pas y avoir pensé désolé :/

au final je note que le conf 1&1 par défaut colle plus à la réalité et que sur OVH tu peux faire des bétises sans t'en rendre compte :-)

Merci de ton retour.

@+

Effectivement, maintenant je le saurai.

:arrow: UTF-8 (sans Bom)

Le BOM ne doit jamais jamais jamais être présent dans des fichiers PHP

Bonjour,

J’ai fini après de longues heures de recherches par trouver la solution pourquoi mon code fonctionne chez OVH et non chez 1 & 1

Pour qu’il fonctionne chez 1 & 1, il faut encoder les pages en UTF-8 (sans Bom)
et supprimer en début de fichier la ligne blanche entre le header et session_start puis aussi entre la balise <?php et le header.

Voici le code rectifié sur chaque page :

[code]
<?php // PAS d'ESPACE AVANT !
header('Content-type:text/html; charset=UTF-8'); // PAS d'ESPACE AVANT !
if( session_id()=='' ){ session_start(); } // PAS d'ESPACE AVANT !
[/code]

Par contre la ligne blanche est bien supporté chez OVH et en local sur mon PC ainsi que l’encodage en local.

La seule chose que j’ignore c’est si chez OVH, il faut un encodage UTF-8 ou UTF-8 (sans Bom).
Mais bon, il suffit d’effectuer le test avec les 2 encodages diffèrent pour le savoir.

Je laisse encore un peu de temps avant de clore cette discussion en résolu au cas où je ne serais pas suffisamment
explicite dans mes explications.

Merci encore à Moogli pour son aide.

Conclusion :

Il s’agissait bien d’une erreur de ma part dans mon code et de l’encodage de mes pages et non d’un problème chez 1 & 1
qui malgré tout voulait me faire changer de contrat.

Enfin, je constate que le serveur chez OVH avec PHP 7 est plus permissif que chez 1 & 1.

Cordialement.

Effectivement je ne comprends pas.
Ils sont censés me contacter aujourd’hui mais j’en doute, si pas de nouvelle je les contacte cette après-midi.

de rien, bon courage.

Perso je n'ai jamais de problème, c'est dommage :s

Je vais changer d'hébergeur, trop de problèmes avec 1 & 1.

En cherchant à droite et à gauche je me suis aperçus que je n'étais pas seul dans ce cas là!

Je pense opter pour OVH.

Merci Moogli.