Pour fermer ou ne pas fermer php


14

J'ai lu qu'il est conseillé (surtout avec php 7) de ne pas fermer les fichiers php avec ?>

Beaucoup de mes fichiers php WP se terminent comme ceci:

<?php get_sidebar(); ?>
<?php get_footer(); ?>

Dois-je supprimer la balise de fermeture et avoir quelque chose comme ça

<?php get_sidebar(); ?>
<?php get_footer(); 

à la fin de mes fichiers?


2
S'il n'y a rien après votre balise php non fermée, c'est tout à fait correct, comme je l'ai observé dans de nombreux cadres comme Laravel, ils ne ferment pas la balise php à la fin des fichiers, et en passant, les fichiers de base WordPress ont également suivi la même chose motif et ne pas fermer la balise php à la fin, donc je pense que nous devrions suivre le style de codage WordPress et ne pas les fermer.
Amirmasoud

1
Billet éventuellement associé sur trac: # 10633
Sven

Réponses:


19

Oui, veuillez éviter de fermer les balises PHP à la fin du fichier, non seulement avec PHP 7, mais aussi avec PHP 5.

La raison en est que si vous fermez la balise, tout ce qui se trouve après la balise, même une ligne vierge, sera envoyé à la sortie et fera en sorte que PHP envoie des en-têtes, empêchant ainsi la configuration du cookie, la redirection vers le travail, le flux pour être valide, etc.

Je suppose que vous avez déjà rencontré un message comme

Impossible de modifier les informations d'en-tête - en-têtes déjà envoyés par (sortie démarrée à ...) dans ... en ligne ...

Une fermeture ?>à la fin du fichier peut en être la cause.


1
Je pense que c'est la bonne réponse. Même Underscores , d'où j'ai initialement obtenu mon modèle, a supprimé la balise de fermeture dans la dernière mise à jour.
IXN

@IXN Ceci est correct si le fichier entier est PHP et se compose donc d'un seul bloc de code PHP (le bloc de code PHP est implicitement fermé à la fin du fichier). Cependant, si vous avez plusieurs blocs de code PHP et mélangez HTML et PHP, comme l'indique l'exemple de votre question, vous devez fermer explicitement le bloc de code PHP, comme TheDeadMedic l'indique dans sa réponse.
MrWhite

Je pense que la seule exception est si le dernier bloc de code php est suivi par html. Mais si les derniers symboles du fichier sont?> Ils peuvent / doivent être omis. Ou alors je comprends.
IXN

La principale raison d'omettre (ou d'inclure) la balise PHP de fermeture est d'éviter d'introduire des bogues idiots pendant le développement. Comme mentionné ci-dessus, pour un fichier entièrement PHP, cela peut éviter une sortie accidentelle entraînant une erreur. Pour un fichier qui mélange déjà la sortie HTML et PHP, cela ne peut pas entraîner d'erreur. Cependant, l'omission de la balise PHP de fermeture dans ce deuxième cas a le potentiel d'introduire des bogues, car vous devez maintenant vous rappeler de fermer explicitement la balise PHP avant d'ajouter du contenu HTML de fin - ce n'est pas quelque chose que vous faites dans un fichier de code entièrement PHP.
MrWhite

Si vous regardez à travers la source WP, vous verrez que la plupart des PHP incluent omettent la balise PHP de fin. Cependant, les fichiers de modèle (qui mélangent des blocs de code HTML et PHP) incluent toujours la balise PHP de fermeture.
MrWhite

11

Compte tenu de votre exemple spécifique, je conserverais la balise de fermeture, c'est-à-dire les appels de fonction d'une ligne dans un modèle. Il est cohérent et facilite la clarté (de la même manière que WordPress recommande les virgules de fin pour les tableaux ) - sinon imaginez si un non-développeur a récupéré votre fichier et a commencé à y ajouter:

<?php get_footer();

<div>What the hell am I doing wrong?</div>

Cependant, pour tous les autres fichiers (fonctions, inclut etc.), le conseil est certainement une bonne idée:

<?php // Start of file

class MY_Class {
    function just_do_it() {
    }
}

// Bye bye closing tag

Je trouve que c'est plus propre, et comme d'autres l'ont mentionné, aucun risque de redouter les "en-têtes déjà envoyés".

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.