Est-ce une mauvaise pratique de mettre les directives PHP dans des fichiers .html et de les interpréter en tant que PHP?
Je gère le site Web de mon entreprise, qui utilise le même en-tête, le même pied de page et la même colonne de gauche sur toutes les pages, depuis fin 2014. C'est pourquoi j'ai configuré le serveur Apache pour interpréter les documents HTML comme s'il s'agissait de PHP. J'utilise include() pour amener le header.html, footer.html et leftcolumn.html dans chaque page, avec quelques autres échanges de variables mineures, etc.
Maintenant, je travaille sur mon propre site Web et j'allais faire la même chose, mais j'ai vu que d'autres questions sur ce sujet ne devaient pas forcer HTML à être lu comme PHP (in PHP réponses à la création de formulaire, que j’ai implémentées avec succès, sans forcer).
Question: Est-ce une mauvaise pratique de configurer un serveur pour analyser les fichiers HTML en tant que PHP? Y a-t-il des répercussions possibles sur le référencement? Dois-je renoncer complètement aux extensions de fichier et passer dans une structure de dossiers? (.com/players/ au lieu de .com/players.html)
Comme il ne semble pas y avoir de réponse claire à des questions similaires, cela peut être considéré comme une question de type "discussion"; Si tel est le cas, je vais forcer HTML à forcer PHP, car cela me semble l'option la plus simple, et envisagerai de le recréer dans une structure de dossiers.
Est-ce une mauvaise pratique de forcer html à être lu comme php? Y a-t-il des répercussions possibles sur le référencement?
Les moteurs de recherche ne savent ni se soucient de la façon dont vos pages sont générées. Ils ne voient que la sortie fournie par l'URL de la requête (en d'autres termes, la sortie de votre fichier PHP).
Dois-je renoncer complètement aux extensions de fichier et passer dans une structure de dossiers? (.com/players/au lieu de .com/players.html)
Les URIs sympas ne changent pas. Peu importe que vous ayez une extension de fichier ou non, et si vous en utilisez une, cela ne change pas lorsque vous changez de technologie. Alors, choisissez ce que vous croyez le plus facile à gérer et respectez-le.
Si tous vos .html fichiers contiennent PHP code et donc nécessité d'être analysés par le moteur PHP de toute façon, il n'y a pas vraiment de différence entre l'analyse vos fichiers .html pour PHP vers modifiant vos extensions de fichier en .php. Excepté du point de vue des développeurs, un fichier .php est évidemment un fichier PHP et certains éditeurs peuvent le traiter différemment (coloration syntaxique, complétion de code, etc.).
Cependant, si vous développez un nouveau site ou s'il est facile de le changer, il n'y a pas de nécessité pour analyser les fichiers .html pour PHP. Il suffit de coller à l'extension de fichier .php. De plus, si ce code est destiné à être déployé sur différents serveurs, utilisez l'extension de fichier .php. Certains serveurs partagés n'autorisent pas l'analyse des fichiers .html par PHP. Il est également possible d'essayer de créer la directive AddType/AddHandler correcte pour le serveur. .
Dois-je renoncer complètement aux extensions de fichier et passer dans une structure de dossiers? (
.com/players/au lieu de.com/players.html)
Notez que lorsque vous vous référez à .phpextensions de fichier, nous ne parlons que de l’extension sous-jacente fichier sur le fichier physique, cela n’a rien à voir avec l'URL que l'utilisateur voit. Le fichier physique sur le système de fichiers doit toujours avoir une extension de fichier.
Si, par ".com/players/", vous avez l'intention de servir le DirectoryIndex à partir du répertoire correspondant, par exemple. .com/players/index.php, j'éviterais donc cette approche car vous obtiendrez des centaines/milliers de fichiers "différents" index.php - ce qui peut prêter à confusion. Les URL qui accèdent à une seule page ne doivent pas se terminer par une barre oblique IMO.
Non, ne faites pas ceci dans un fichier HTML . Je suis fermement convaincu de mettre un peu plus de travail pour garder votre code soigné. CSS va dans un fichier .css, html dans un fichier .html et PHP va dans un fichier .php *. Votre séparation actuelle des fichiers est une bonne chose, c’est la partie "que je fais PHP dans les fichiers HTML" et que je ne recommande pas.
* Bien sûr, cela ne s'applique pas à 100%, mais vous devriez essayer.
En procédant ainsi, vous (au moins dans une certaine mesure) et d'autres personnes (à long terme) créerez un projet plus facile à gérer car vous vous en tenez aux meilleures pratiques. Bien qu'il soit possible de configurer un serveur pour gérer PHP dans un fichier .html, ce n'est pas quelque chose qui est couramment recommandé.
Votre code devrait être maintenable . Je ne chercherais pas (ni n'attendrais) PHP dans les fichiers HTML. Garder votre code soigné vous aidera à long terme. En gardant tout séparé, vous vous conformerez automatiquement à des normes de codage spécifiques, ce qui vous aidera à améliorer vos compétences.
Si vous recherchez Google pour "html in php", vous obtiendrez de nombreuses réponses indiquant que vous ne pouvez pas utiliser PHP dans un fichier .html. Ils ont tort, mais cela montre à quel point c'est rare.
Concernant votre URL: Vos URL ne devraient pas changer lorsque vous changez de technologie. Vos URL ne doivent pas avoir une extension du fichier. Cependant, il existe une solution rapide à cela: Laissez le .htaccess réécrire l'URL pour vous en interne. J'ai des pages de produits où j'utilise .htm dans l'URL, ce qui me permet de les récupérer facilement dans mon .htaccess, mais ce ne sont pas du tout des fichiers HTML :)
Réponse similaire à la mienne https://stackoverflow.com/a/11312349/2519416 .
Cela pourrait aussi être une lecture agréable: "Ne mélangez pas PHP et HTML!"
Le rendu PHP obligera votre serveur Web à répondre légèrement plus lentement
L’un des inconvénients techniques de l’analyse HTML en tant que PHP serait le temps supplémentaire et les ressources du serveur que le traitement consomme. S'il n'y a pas d'instructions PHP dans votre code HTML, il est peu probable que cela soit perceptible. Vous pourriez économiser quelques microsecondes en désactivant PHP.
Vous pouvez mesurer cela en testant votre temps de chargement avec PHP ou en utilisant un outil tel que Pingdom . (Ignorez leurs conseils sur les caches d’une semaine.) Je ne pense pas que vous verrez une grande différence.
Il existe probablement des moyens beaucoup plus efficaces d'accélérer votre site. Par exemple, si vous n’avez pas marqué dans les années 90 Google PageSpeed Insights dépensez votre énergie pour améliorer votre score là-bas en premier (surtout si vous vous souciez du référencement).
Sites à volume élevé
Le conseil d'ignorer la sanction PHP s'applique à votre site Web typique. Si vous obtenez du volume dans la plage de vues de page multiples par seconde, alors désactivez certainement PHP sauf si vous en avez besoin, afin de réduire la charge sur votre serveur Web.
Sécurité
Le traitement de PHP sur votre site ouvre la voie à des attaques sur votre site Web. C’est un peu paranoïaque, mais c’est une raison valable pour arrêter le traitement de PHP si vous ne l’utilisez tout simplement pas.
Comme différentes réponses l'ont laissé entendre, vous devez distinguer entre les URL et les noms de fichiers physiques . Le mappage le plus simple des URL est directement au système de fichiers - http://example.com/foo.html pointant vers un fichier nommé foo.html dans un répertoire - mais dès que vous pensez à des URL en tant que SEO (ou, dans un monde idéal, UX ), vous utiliserez de toute façon une cartographie plus complexe.
Le choix du nom de fichier physique n'a alors plus rien à voir avec le référencement, mais uniquement les performances et la sécurité. Par exemple, vous pouvez associer http://example.com/foo.html à scripts/generate_page.php?page=foo et http://example.com/bar.html à static_pages/bar.html.
Comme d'autres l'ont dit, pour les pages qui ne font absolument rien avec PHP, il existe un avantage en termes de performances (et de sécurité potentielle) de ne pas les acheminer via le processus PHP. Réserver le plus facilement est de réserver une extension de fichier physique pour ce type de pages. Compte tenu des correspondances ci-dessus, il est facile de dire à Apache de servir bar.html directement, mais de passer generate_page.php à PHP. _ processeur.
Pour les pages qui utilisent PHP, il est avantageux de respecter les conventions communes suivantes, car vous passerez moins de temps à configurer des outils pour reconnaître les fichiers qui sont PHP et qui ne le sont pas. Comme pour toute convention, il sera également plus facile pour d’autres personnes de travailler avec votre projet à l’avenir si tout se passe comme prévu.
La pratique consistant à mélanger HTML et PHP dans un même document a commencé il y a longtemps, et même si certains projets open source populaires tels que WordPress le font toujours, commence-t-il à devenir une pratique dépassée et je la considérerais même comme une mauvaise pratique du point de vue du codage.
Évidemment, cela n’aura pas d’impact sur le référencement puisque tout ce qui intéresse Google, c’est la sortie, mais cela a un impact important sur la manière dont vous organisez votre code et votre projet.
La plupart des infrastructures populaires actuelles utilisent le modèle de conception MVC. Modèle Vue Contrôleur. Ce modèle de conception consiste à séparer la logique et les vues/sorties dans des fichiers séparés pour faciliter la maintenance de votre code.
Contrairement à votre modèle actuel dans lequel vous mettez tous les éléments HTML et PHP dans un seul fichier, vous suivrez une approche plus orientée objet avec des classes claires et faciles à gérer.
Un avantage supplémentaire est qu'il sera plus facile pour votre programmeur front-office de faire son travail, car il n'aura pas à prendre en compte la logique d'arrière-plan dans les mêmes fichiers que ceux sur lesquels il travaille.