Pourquoi aurait-on omettre la balise de fermeture?

Question

Je lis c'est une mauvaise pratique d'utiliser la balise de fermeture PHP ?> à la fin du fichier. L'en-tête problème ne semble pas pertinent dans le contexte suivant (et c'est le seul bon argument à ce jour):

Les versions récentes de PHP définir l'output_buffering drapeau en php.ini Si le tampon de sortie est activé, vous pouvez définir des en-têtes HTTP et les cookies après la sortie html car code de retour n'est pas envoyé au navigateur immédiatement.

Chaque bonne pratique livre et wiki commence avec cette "règle", mais personne ne propose de bonnes raisons. Est-il une autre bonne raison pour ignorer la balise de fermeture php?

Answer 1

Bien que je ne me souviens pas de toute autre raison, l'envoi des en-têtes plus tôt que la normale peut avoir de lourdes conséquences. Ci-dessous sont quelques uns d'entre eux qui s'est passé pour venir à mon esprit à l'instant:

1. Alors que les versions de PHP peut avoir le tampon de sortie est sur on, la production de serveurs vous déployez votre code sur sont de loin plus important que le développement ou le test des machines. Et ils n'ont toujours tendance à suivre plus tard PHP tendances immédiatement.

2. Vous pouvez avoir des maux de tête au cours d'inexplicable, de la perte de fonctionnalités. Dire, vous mettez en œuvre une sorte de passerelle de paiement, et de rediriger l'utilisateur vers une URL spécifique après le succès de la confirmation par le processeur de paiement. Si certains type d'erreur PHP, même un avertissement, ou un excès de fin de ligne se produit, le paiement peut rester non transformés et l'utilisateur peut encore sembler non facturés. C'est aussi l'une des raisons pour lesquelles il va sans redirection est mal et si la redirection est utilisé, il doit être utilisé avec prudence.

3. Vous pouvez obtenir "chargement d'une Page web annulée" type d'erreur dans Internet Explorer, même dans les versions les plus récentes. C'est parce que l' AJAX réponse/json inclure contient quelque chose qu'il ne devrait pas contenir, en raison de l'excès de fins de ligne dans certains fichiers PHP, ainsi que je l'ai rencontré il y a quelques jours.

4. Si vous avez quelques téléchargements de fichiers dans votre application, ils peuvent rompre trop, à cause de cela. Et on ne le remarque pas, même après des années, depuis le spécifique de rupture habitude de téléchargement dépend du serveur, le navigateur, le type et le contenu du fichier (et éventuellement d'autres facteurs que je ne veux pas vous ennuyer avec).

5. Enfin, de nombreux frameworks PHP, y compris Symfony, Zend et Laravel (il n'est pas fait mention de cela dans les règles de codage , mais il suit le costume) et le PSR-2 standard (point 2.2) exiger d'une omission de la balise de fermeture. Manuel PHP lui-même (1,2), Wordpress, Drupal et bien d'autres logiciel PHP, je suppose, conseiller de le faire. Si vous faites simplement une habitude de suivre la norme (et de configuration de PHP-CS-Fixateur pour votre code), vous pouvez oublier le problème. Sinon, vous aurez toujours besoin de garder la question dans votre esprit.

Bonus: quelques pièges (en fait actuellement un) liées à ces 2 personnages:

1. Même certains bien connus des bibliothèques peuvent contenir les excès de fin de ligne, après l' ?>. Un exemple est Smarty, même les versions les plus récentes de deux 2.* et 3.* direction de l'avoir. Alors, comme toujours, montre pour la troisième partie du code. Bonus en bonus: Une regex pour la suppression inutile PHP terminaisons: remplacer (\s*\?>\s*)$ avec texte vide dans tous les fichiers qui contiennent le code PHP.

Answer 2

La raison pour laquelle vous devriez laisser tomber la balise de fermeture php (?>) de sorte que le programmeur n'est pas accidentellement envoyez les caractères de saut de ligne.

La raison pour laquelle vous ne devriez pas laisser de côté la balise de fermeture php est parce qu'elle provoque un déséquilibre dans les balises php et tout programmeur avec la moitié d'un esprit qui peut rappeler de ne pas ajouter de l'espace blanc.

Donc pour répondre à votre question:

Est-il une autre bonne raison pour ignorer la balise de fermeture php?

Non, il n'y a pas une autre bonne raison pour ignorer la fin des balises php.

Je vais terminer avec quelques arguments pour ne pas s'embêter avec la balise de fermeture:

1. Les gens sont toujours en mesure de faire des erreurs, peu importe combien ils sont intelligents. En adhérant à une pratique qui réduit le nombre d'erreurs possibles est (à mon humble avis) une bonne idée.

2. PHP n'est pas du XML. PHP n'a pas besoin d'adhérer à XMLs des normes strictes pour être bien écrit et fonctionnelle. Si un manque de fermeture de balise vous agace, vous êtes autorisés à utiliser une balise de fermeture, ce n'est pas un ensemble en pierre à la règle d'une façon ou de l'autre.

Answer 3

C'est un newbie style de codage de la recommandation. C'est pourquoi il est généralement mentionné dans l'introduction des livres.

Sortant ?> peut éviter l'infâme headers already sent problème. La fermeture jeton n'est pas la vraie cause de ce message d'erreur. C'est extra les espaces après l' ?> token qui peut causer que, pour certains d'application de structures, à savoir la sortie inaperçu espaces par inclusion d'autres fichiers.

PHP contient en fait de la magie pour manger un seul \n retour à la ligne après l' php clôture jeton. Voir L'histoire de PHP manger des retours à la ligne après la balise de fermeture
Il y avait quelques premiers numéros de PHP de ne pas consommer \r\n. Il a travaillé sur Windows, mais les scripts téléchargés sur les serveurs Unix généré l'erreur. Il y a donc un écueil supplémentaire. Pas plus d'actualité.

Ce qui est aujourd'hui hante les nouveaux arrivants est la plupart du temps, de la méconnaissance et feuilletée éditeurs. La plupart des éditeurs de texte ont l'habitude d'ajouter une nouvelle ligne à la fin des fichiers de n'importe quoi. Ce n'est pas un problème, mais les nouveaux arrivants ont souvent l'ajouter aussi. Et évidemment, il arrive souvent que l'édition de code le mélange des espaces, des tabulations et extra-retours à la ligne après l' ?> clôture jeton. (Aucune idée de comment ils ne remarquent pas que!)

Donc je pense que c'est vraiment de bons conseils pour PHP noobs. Cependant, il n'est pas vraiment un moyen infaillible pour éviter l'erreur susmentionnée. Il vient de retards sa découverte, comme nous l'avons Pile Overflowers se doit de connaître. Il y a beaucoup plus de moyens pour déclencher headers already sent et les nouveaux venus les découvrir tous. Il y a l'invisible BOM ou même HTML et <!DOCTYPE> avant <?php, ou souvent simplement print relevés avant l' header() appel.
C'est pourquoi, en évitant ?> est souvent considéré comme juste un moyen pour éviter d'expliquer la langue de base de comportement, mais pas plus de solution que la magie ?>\r\n newline manger.

Résoudre automatisé

Manuel de garde d' ?> balises de fermeture n'est pas très contemporaine.

phptags --warn --whitespace *.php

Ou encore:

phptags --unclosed includes/

Le fera pour vous (éditeur de crochet, tâche cron, SCM checkin script). L'ancien résout également les autres pièges potentiels, non seulement closetag question. Voir phptags balise de plus en ordre.

Answer 4

Ce n'est pas une balise...

Mais si vous l'avez, vous risquez d'avoir un espace blanc après.

Ensuite, si vous l'utiliser comme un include en haut d'un document, on pourrait insérer un espace blanc (c'est à dire le contenu) avant de tenter d'envoyer des en-têtes HTTP ... qui n'est pas autorisé.

Answer 5

Il est très utile de ne pas laisser la clôture ?> .

Le fichier reste valable pour PHP (pas une erreur de syntaxe) et comme @David Dorward dit-il permet d'éviter d'avoir un espace blanc / saut de ligne (tout ce qui peut envoyer un en-tête pour le navigateur) après l' ?>.

Par exemple,

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10);
    imagepng ( $img);
?>
[space here]
[break line here]

n'est pas valide.

Mais

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10 );
    imagepng ( $img );

va.

Pour une fois, vous devez être paresseux pour être sûr.