Meilleures pratiques pour PHP


11

Lorsque vous faites un modèle tel que single.php et que vous avez php enveloppé en html, est-il préférable de:

  1. Démarrer + arrêter PHP? par exemple

     <h1 class="post-tilte"><?php the_title(); ?></h1>
     <p class="post-content"><?php the_content();?></p>
    

Ou

  1. Echo HTML et PHP d'échappement? Par exemple -

    <?php echo '<h1 class="post-title">' . get_the_title() . '</h1>
    <p class="post-content"' . get_the_content() . '</p>
    

Je n'ai pas de choix préalable et je me retrouve à faire les deux, juste curieux d'entendre quelques pensées


6
La première méthode est plus conviviale pour les concepteurs. Donc, lorsque vous utilisez des modèles avec beaucoup de HTML et peu de PHP, faites le premier. Le second est utile quand il y a beaucoup de PHP et un peu de HTML. Faites-le functions.phpou plugins etc.
Fayaz

3
Vous avez oublié qu'il y a aussiprintf( '<h1 class="post-title">%s</h1>', get_the_title() );
Howdy_McGee

Réponses:


10

Cette question n'est pertinente que parce que WordPress utilise un mélange d'un langage de codage et d'un langage de mise en page. Si vous souhaitez utiliser un langage de modèle, une syntaxe, cette rubrique n'est pas pertinente. Mais à votre question. Si vous utilisez votre exemple de source pour un thème, un langage de mise en page beaucoup plus comme le HTML, alors je préfère le premier - il est beaucoup plus lisible pour le concepteur et les utilisateurs, il doit lire le balisage. Il est plus facile de créer un aperçu du balisage, de disposer des balises d'ouverture et de fermeture, etc.

Pour l'inclusion dans les plugins, le code avec plus de logique et de flux est le deuxième exemple plus facile à implémenter. Le sujet principal est le php, pas le balisage et cela devrait être visible dans la source. C'est également un point à considérer pour exclure ce balisage dans les fichiers de modèle et séparer le balisage de la logique.


1
Un autre avantage du premier est que certains éditeurs mettront en surbrillance la balise d'ouverture ou de fermeture correspondante si vous y placez votre curseur, mais ce dernier casse généralement cette commodité.
MonkeyZeus


5

Comme expliqué dans la réponse ci-dessus, la première méthode est conviviale pour le concepteur et la deuxième méthode peut convenir dans les cas de plugins et de codes PHP complexes où le nombre de balises html n'est que peu.

Mais la plupart des balises de modèle WordPress a beforeet afterparamètres et il est plus approprié d'utiliser vos codes HTML à l' intérieur de l' appel de fonction.

par exemple, dans le cas où the_titleil a trois paramètres

the_title( $before, $after, $echo );

vous pouvez passer votre html aux paramètres avant et après comme ci-dessous

the_title( '<h2 class="title">', '</h2>', true );

les avantages de cette méthode sont

  • Concepteur amical
  • n'imprimera pas les balises html si le titre est vide
  • peut être utilisé dans des codes php complexes ainsi que dans des fichiers modèles simples

0

La première méthode est préférable car:

  • Il sépare clairement la mise en page HTML fixe du contenu dynamique.
  • C'est plus facile à lire.
  • Il est mieux pris en charge par la coloration syntaxique dans la plupart des éditeurs, car les attributs html en chaîne ne sont généralement pas reconnus.
  • Il vous empêche d'intermêler trop facilement HTML et PHP.

Pour les raisons exposées ci-dessus, la première méthode conduit à un code plus facile à comprendre et donc plus facile à maintenir.

D'après mon expérience, dans certaines situations, il peut sembler plus pratique d'utiliser la deuxième méthode. Cependant, cela est généralement dû à une conception (logicielle) faible et doit être considéré comme un signe d'avertissement.


0

Votre exemple de code est marginal car il ne montre que deux lignes de code, mais je pense que la réponse globale est assez situationnelle. Si vous utilisez une ligne PHP dans un bloc HTML, utilisez la première méthode. Si vous utilisez une ligne HTML dans un bloc PHP, choisissez la seconde.

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.