Skip to content

Kévin Dunglas

Founder of Les-Tilleuls.coop (worker-owned cooperative). Creator of API Platform, FrankenPHP, Mercure.rocks, Vulcain.rocks and of some Symfony components.

Menu
  • Talks
  • Resume
  • Sponsor me
  • Contact
Menu

Ne fermez pas vos tags à la fin des fichiers PHP

Posted on July 24, 2008August 1, 2008 by Kévin Dunglas

Pendant que NikO nous présente ses conventions de codage, parlons d’une autre bonne pratique concernant les tags de délimitation de blocs en PHP.

Le langage PHP n’impose pas de fermer un bloc de code avec ?> si se bloc se trouve tout à la fin du fichier, et pour cause, mieux vaut l’omettre dans les fichiers susceptibles d’êtres inclus par d’autres !

Prenons ce bout de code :
date.php

<?php
$year = date('Y');
?>
 

Notez bien la ligne blanche après le tag de fermeture. Et maintenant :

redirige.php

<?php
include('date.php');
if($year < 2009) {
  header('Location: //dunglas.fr');
  exit;
}
?>
Si notre serveur est à l'heure, nous ne sommes plus en 2008 et vous pouvez voir cette page !

Catastrophe ! C’est la très pénible erreur Warning: Cannot modify header information – headers already sent by… qui s’affiche.

PHP a envoyé la ligne blanche (\n) de notre fichier date.php au navigateur, avec les en-têtes HTTP qui vont bien. Impossible d’ajouter de nouveaux en-têtes ni de rediriger l’utilisateur une fois que le début du corps de la requête a été envoyé.

Il faut savoir que certains éditeurs de texte ajoutent automatiquement un retour charriot à la fin des fichier lors de leur création ou de leur enregistrement.

Otez les ?> à la fin de vos classes, bibiliothèques et tout autres fichiers qui seront inclus par d’autres. Même si votre éditeur n’a pas se malheureux comportement, ce n’est peut-être pas le cas de ceux de vos collègues, des contributeurs du projet sur lequel vous travaillez… ou que vous utilisez.

Related posts:

  1. PHP et ses tags
  2. Sécuriser tant bien que mal une application Symfony installée dans un sous-répertoire
  3. Sécurisez votre blog WordPress !
  4. Google indexe les sites en Flash : un coup d’épée dans l’eau

10 thoughts on “Ne fermez pas vos tags à la fin des fichiers PHP”

  1. Oncle Tom says:
    July 24, 2008 at 9:50 am

    Bonne remarque oui.
    Juste pour info, c’est devenu facultatif en PHP 5 il me semble.

    Reply
  2. Kévin Dunglas says:
    July 24, 2008 at 2:00 pm

    Qu’est ce qui est devenu facultatif Oncle Tom ?

    Reply
  3. Oncle Tom says:
    July 24, 2008 at 11:03 pm

    De mettre la déclaration fermante, pardon : ?>

    En PHP 4 si on faisait ça, de mémoire, ça criait au loup.

    Reply
  4. Kévin Dunglas says:
    July 25, 2008 at 10:26 am

    Bonne question 🙂
    Ca fait bien longtemps que je n’ai plus de PHP 4 pour tester :p

    Reply
  5. Lupus Michaelis says:
    July 27, 2008 at 6:30 pm

    Je suis curieux de connaître les mauvais éditeurs de texte qui rajoutent des \n là où il n’en faut pas. Histoire que je les évites.

    Enfin bref, conseiller une mauvaise pratique est de mauvais goût. Surtout quand c’est pour contourner un bogue plutôt que de le résoudre.

    Au fait, la norme PHP n’existe pas. PHP n’est pas un langage normalisé.

    Reply
  6. Kévin Dunglas says:
    July 27, 2008 at 8:39 pm

    Mea culpa, PHP n'est pas normalisé (au sens Java du terme).

    Disons que l'implémentation du langage de The PHP Group ne l'impose pas 😉

    Omettre ce tag peut causer problème en cas d'utilisation du fichier source PHP par un analyseur XML, ce qui est très rare, beaucoup plus que celui d'envoyer involontairement des caractères invisibles après le ?>.

    Après, suivant les cas, ça peut ne pas être super élégant (j'omets ce tag quasi-exclusivement dans mes classes, jamais dans mes templates).

    Voyons ce que la documentation officielle en dit :

    Note: La balise fermante d'un bloc PHP à la fin d'un fichier est optionnel, et parfois, il est utile de l'omettre lors de l'utilisation de la fonction include() ou de la fonction require(), car les espaces non désirés n'apparaîtront pas à la fin des fichiers, et ainsi, vous pourrez toujours ajouter des en-têtes à la réponse plus tard. C'est utile également si vous voulez utiliser l'affichage du buffer et que vous ne voulez pas voir d'espaces blancs ajoutés à la fin des parties générées par les fichiers inclus.

    http://us2.php.net/basic-syntax.instruction-separ…

    Reply
  7. Kévin Dunglas says:
    July 27, 2008 at 10:00 pm

    Je viens de jeter un œil au code source du Zend Framework (qui pourrait faire référence vu ses auteurs :P) et à celui de Symfony, deux projets réputés d’excellente facture : tous les deux ne ferment pas les tags en fin de fichiers.

    Reply
  8. Lupus Michaelis says:
    July 31, 2008 at 3:23 am

    Ça me conforte dans mon opinion sur PHP :p

    Ceci dit, je préfères m’imposer un peu de rigueur, ça ne fait pas de mal (et terminer est la moindre des choses).

    Ensuite c’est une affaire de goût.

    Reply
  9. Pingback: Anonymous
  10. solstice says:
    June 23, 2009 at 8:24 am

    php5 justement et dans le future tend à se normaliser de plus en plus au contraire ! Il y a une grande différence entre php4 et php5.
    PHP4 était bien trop laxiste et PHP5 se professionnalise beaucoup plus et demande de plus en plus de la rigueur dans la manière de coder (qui se rapproche on peut allègrement le remarquer de l'ASP3 en terme de rigueur.

    Donc "la norme php n'existe pas ?" J'en doute fort il suffit de voir l'axe que prend zend.

    Reply

Leave a ReplyCancel reply

Social

  • Bluesky
  • GitHub
  • LinkedIn
  • Mastodon
  • X
  • YouTube

Links

  • API Platform
  • FrankenPHP
  • Les-Tilleuls.coop
  • Mercure.rocks
  • Vulcain.rocks

Subscribe to this blog

Top Posts & Pages

  • JSON Columns and Doctrine DBAL 3 Upgrade
  • Securely Access Private Git Repositories and Composer Packages in Docker Builds
  • Preventing CORS Preflight Requests Using Content Negotiation
  • FrankenPHP: The Modern Php App Server, written in Go
  • Symfony's New Native Docker Support (Symfony World)
  • Develop Faster With FrankenPHP
  • How to debug Xdebug... or any other weird bug in PHP
  • HTTP compression in PHP (new Symfony AssetMapper feature)
  • PHP and Symfony Apps As Standalone Binaries
  • Generate a Symfony password hash from the command line

Tags

Apache API API Platform Buzz Caddy Docker Doctrine FrankenPHP Go Google GraphQL HTTP/2 Hydra hypermedia Hébergement Javascript JSON-LD Kubernetes La Coopérative des Tilleuls Les-Tilleuls.coop Lille Linux Mac Mercure Mercure.rocks Messagerie Instantanée MySQL performance PHP Punk Rock Python React REST Rock'n'Roll Schema.org Security SEO SEO Symfony Symfony Live Sécurité Ubuntu Web 2.0 webperf XML

Archives

Categories

  • DevOps (84)
    • Ubuntu (68)
  • Go (17)
  • JavaScript (46)
  • Mercure (7)
  • Opinions (91)
  • PHP (170)
    • API Platform (77)
    • FrankenPHP (9)
    • Laravel (1)
    • Symfony (97)
    • Wordpress (6)
  • Python (14)
  • Security (15)
  • SEO (25)
  • Talks (46)
© 2025 Kévin Dunglas | Powered by Minimalist Blog WordPress Theme