Participez à la FAQ

[Eusebe]

Y aurait-il une coquille dans la FAQ ?

Question : http://php.developpez.com/faq/?page=..._forcedownload
remplacer attachement par attachment ?

Voir le sujet :
http://www.developpez.net/forums/sho....php?p=3512971

[Eusebius]

Envoyé par Eusebe

Y aurait-il une coquille dans la FAQ ?

Question : http://php.developpez.com/faq/?page=..._forcedownload
remplacer attachement par attachment ?

Voir le sujet :
http://www.developpez.net/forums/sho....php?p=3512971

Oui, ça a l'air.
(Pfff, et en plus on suit les mêmes topics, ça va aider tiens pour pas nous confondre !)

[gege2061]

Une question par forcement fréquente mais la réponse n'est pas clairement expliquée dans la doc :

Pourquoi isset renvoi toujours false ?

Comme précisé dans la documentation officiel, isset fonctionne uniquement avec les variables.

Pour les constantes, il faut utiliser defines.

Et pour les variables "magiques" (ie: gérée avec les fonctions magiques __set et __get), il faut définir la méthode __isset qui sera automatiquement appelée via la fonction isset. Exemple :

Code :

[Moubai]

il y a une erreur de code dans la FAQ

http://php.developpez.com/faq/?page=...ner_couleur_tr


"Pour alterner les couleurs, il suffit de faire ainsi : "

Code :

1
2
3
4
5
6
7
$i = 0;
while(condition) 
{
  $couleur = ($compteur % 2 == 0) ? "#CCCCCC" : "#FFFFFF";
  echo '<tr bgcolor="'.$couleur.'"><td>texte</td></tr>';
  $i++;
}

la variable $compteur doit être remplacée par la variable $i

donc

Code :

1
2
3
4
5
6
7
$i = 0;
while(condition) 
{
  $couleur = ($i % 2 == 0) ? "#CCCCCC" : "#FFFFFF";
  echo '<tr bgcolor="'.$couleur.'"><td>texte</td></tr>';
  $i++;
}

[Seb33300]

J'ai une proposition pour la question :
Explications et correction de l'erreur "headers already sent"
http://php.developpez.com/faq/?page=...s_already_sent

Dans la liste de ce qui cause l'envoi des en-têtes, il serait peut être intéressant d'y ajouter : "Les fichiers php encodés en UTF8 avec BOM"

En effet c'est un cas assez particulier, car aucun texte n'est renvoyé à l'écran et un débutant pourrait pas mal galérer pour trouver la solution. Surtout que la tendance va justement vers l'UTF8.

[s.n.a.f.u]

Envoyé par Seb33300

J'ai une proposition pour la question :
Explications et correction de l'erreur "headers already sent"
http://php.developpez.com/faq/?page=...s_already_sent

Dans la liste de ce qui cause l'envoi des en-têtes, il serait peut être intéressant d'y ajouter : "Les fichiers php encodés en UTF8 avec BOM"

En effet c'est un cas assez particulier, car aucun texte n'est renvoyé à l'écran et un débutant pourrait pas mal galérer pour trouver la solution. Surtout que la tendance va justement vers l'UTF8.

Waouh ! J'avais commencé un petit texte, et au moment de faire mon copier-coller, je vois que je ne suis pas le seul à y avoir pensé !

Pour la description précise du problème, je renvoie vers Wikipedia qui est assez claire sur le sujet, et je ne citerais que ce passage :

Problèmes liés à l'utilisation de la marque d'ordre des octets
Beaucoup de logiciels Windows (incluant Windows Notepad) en ajoutent un aux fichiers UTF-8. Cependant, sur des systèmes de type Unix (qui utilisent beaucoup les fichiers textes pour la configuration) cette pratique n'est pas recommandée, car cela peut interférer avec le traitement adéquat de codes importants tels que le sha-bang au début d'un script interprété. Il peut également interférer avec le source pour les langages de programmation qui ne le reconnaissent pas. Par exemple, gcc reporte des stray characters au début du fichier source, et en PHP, si l'output buffering est désactivé, cela a pour effet subtil de faire que la page commence immédiatement à être envoyée au navigateur, et d'empêcher les custom headers d'être spécifiés par le script PHP. La représentation UTF-8 du BOM est la séquence d'octets EF BB BF, qui apparaît en codage ISO-8859-1 comme "" dans les éditeurs de textes et navigateurs mal préparés pour traiter l'UTF-8. Ils peuvent également échouer à appliquer la première règle d'une feuille CSS.

J'ai eu à intervenir plusieurs fois chez des amis ou connaissances qui développent sous windows avant de charger leur site en FTP sur un système linux.
Le BOM et l'output buffering ne faisaient pas bon ménage (les vues Zend_View avec ce caractère explosaient le rendu), mais il leur était impossible de trouver cette erreur, qui est assez discrète pour qui n'en a pas eu l'expérience précédemment.
Pour compliquer la chose, ajoutons à cela que les éditeurs actuels (Notepad++ par exemple) masquent le BOM par défaut.

Le problème a déjà été rencontré plusieurs fois sur le forum, aussi serait-il judicieux de préciser cette source d'erreur.

Enfin, si ça peut aider, je peux apporter ma petite contribution sous la forme de ce mini-script qui repère les fichiers incriminés dans une arborescence.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
<?php
/** JML - findBom.php
Ce script va parcourir toute l'arborescence à partir de son emplacement pour repérer les fichiers contenant le BOM utf8
La sortie est une table récapitulative des fichiers testés
*/
 
$path = realpath('./');
$objects = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($path), RecursiveIteratorIterator::SELF_FIRST);
 
echo "<table>\n<tr><th>Fichier test&eacute;</th><th>R&eacute;sultat</th></tr>\n";
 
foreach($objects as $name => $object){
    if (!preg_match('/php|txt|p?html?$/', $name)) continue;
    echo "<tr>";
    printf ("<td>%s</td>", $name);
    $content = file_get_contents($name);
    if (preg_match('/\x{feff}/u', $content, $match))
        echo '<td style="color: red;">BOM</td>';
    else
        echo '<td style="color: green;">OK</td>';
    echo "</tr>\n";
}
echo "</table>\n";

La correction des fichiers incriminés peut se déduire de ce script, bien que personnellement je préfère le faire en Perl lorsque je dispose d'un accès ssh.

Qu'en pensez-vous ?