web-dev-qa-db-ja.com

PHPディレクティブを.htmlファイルに入れ、サーバーにそれらをPHPとして解釈させるのは悪い習慣ですか?

2014年後半から、すべてのページで同じヘッダー、フッター、左の列を使用する会社のWebサイトを運営しています。このため、ApacheサーバーをセットアップしてHTMLドキュメントをPHPであるかのように解釈します。私はinclude()を使用して、header.htmlfooter.html、およびleftcolumn.htmlを各ページに取り込み、他のいくつかのマイナー変数の交換などを行っています。

今、私は自分のウェブサイトに取り組んでおり、同じ動きをするつもりでしたが、ここでHTMLをPHP(PHPフォーム作成の回答、私は無理なく実装に成功しました)。

質問: HTMLファイルをPHPとして解析するようにサーバーを構成するのは悪い習慣ですか?そうすることでSEOに影響が及ぶ可能性はありますか?ファイル拡張子をすべて忘れて、フォルダー構造に移動する必要がありますか? (.com/players/の代わりに.com/players.html

同様の質問には明確な答えがないように思われるので、これは「議論」タイプの質問と見なされる場合があります。その場合、HTMLをPHPに強制することをオンにします。これは私にとって最も簡単なオプションと思われるため、フォルダー構造に再構築することを検討してください。

5
Kyle Postlewait

Htmlを強制的にphpとして読み取ることは悪い習慣ですか?そうすることでSEOに影響が及ぶ可能性はありますか?

検索エンジンは、ページがどのように生成されるかを知りません。リクエストURLが提供する出力(つまり、PHPファイルの出力)のみが表示されます。

ファイル拡張子をすべて忘れて、フォルダー構造に移動する必要がありますか? (.com/players.htmlではなく.com/players /)

クールなURIは変更されません。 ファイル拡張子があるかどうかは関係ありません。ファイル拡張子を使用しても、テクノロジーを変更しても変わりません。だから、あなたが管理し、それに固執するのが最も簡単だと思うものを選んでください。

8
John Conde

すべての.htmlファイルにPHPコードが含まれているため、needでPHPエンジンによって解析される場合、解析の間に違いはありません。 PHPの.htmlファイルは、ファイル拡張子を.phpに変更します。開発者の観点を除いて、.phpファイルは明らかにPHPファイルであり、一部のエディターはこれを異なる方法で処理する場合があります(構文の強調表示、コード補完など)。

ただし、新しいサイトを開発している場合や変更が簡単な場合は、PHPの.htmlファイルを解析するためのneedはありません。 .phpファイル拡張子に固執するだけです。また、このコードが異なるサーバーにデプロイされることを意図している場合は、.phpファイル拡張子を使用してください。いくつかの共有サーバーは、.htmlファイルがPHPによって解析されることを許可しておらず、サーバーの正しいAddType/AddHandlerディレクティブを想起しようとするのは簡単ではありません。

ファイル拡張子をすべて忘れて、フォルダー構造に移動する必要がありますか? (.com/players/の代わりに.com/players.html

.phpファイル拡張子を参照するときは、物理ファイルの基本的なファイル拡張子について文字通り話しているだけで、これは必ずしも何の関係もないことに注意してください。ユーザーに表示されるURL。ファイルシステム上の物理ファイルには、常にファイル拡張子が必要です。

.com/players/」によって、それぞれのディレクトリからのDirectoryIndexの提供に依存する場合、たとえば.com/players/index.phpを使用すると、混乱を招く可能性のある「異なる」index.phpファイルが数百/ 1000になるため、このアプローチを避けます。 1つのページにアクセスするURLは、スラッシュIMOで終わってはなりません。

4
MrWhite

いいえ、htmlファイルでこれをしないでください。私はあなたのコードをきちんと保つためにもう少し仕事をすることを固く信じています。 CSSは.cssファイルに、htmlは.htmlファイルに、PHPは.phpファイルに*。現在のファイルの分離は良いことです。それは「HTMLファイルでPHPを実行している」部分です-これはお勧めしません。
*もちろん、これは100%適用できませんが、試してみてください。

これを行うことにより、(少なくとも基本的には)あなたと他の人々は(長期的には)ベストプラクティスにこだわるので維持しやすいプロジェクトを作成できます。 .htmlファイル内のPHPを処理するようにサーバーをセットアップすることは可能かもしれませんが、一般的に推奨されるものではありません。

あなたのコードは保守可能でなければなりません。 HTMLファイルでPHPを探しません(または期待しません)。コードをきれいに保つことは、長期的には役立ちます。すべてを分離しておくことで、特定のコーディング標準に自動的に準拠し、スキルの向上に役立ちます。
「html in php」でGoogleを検索した場合、.htmlファイルではPHPができないという多くの回答/返信が得られます。彼らは間違っていますが、それがどれほど珍しいかを示しています。

URLについて:テクノロジーを変更しても、URLは変わらないはずです。 URLにファイルの拡張子を含めることはできません。ただし、これには簡単な修正があります。.htaccessで内部的にURLを書き換えてください。 URLで.htmを使用する製品ページがあるため、.htaccessで簡単に選択できますが、HTMLファイルではありません:)


私と同様の応答 https://stackoverflow.com/a/11312349/2519416 .
これもいい読み物かもしれません: "PHPとHTMLを混ぜないでください!"

4
Martijn

PHPレンダリングにより、Webサーバーの応答が遅くなりますわずかに遅くなります

HTMLをPHPとして解析することの主な技術的な欠点の1つは、処理に消費される余分な時間とサーバーリソースです。 HTMLにPHPの指示がない場合、これは認識できない可能性があります。 PHP解析をオフにすることで、数マイクロ秒節約できます。

Pingdom のようなツールでPHPをオンまたはオフにしてロード時間をテストすることで、これを測定できます。 (1週間のキャッシュに関するアドバイスは無視してください。)それほど大きな違いはないと思います。

サイトを高速化するもっと効果的な方法がおそらくあります。たとえば、90年代に得点していない場合、 Google PageSpeed Insights で最初にスコアを改善することにエネルギーを費やします(特にSEOが気になる場合)。

大量のサイト

PHPペナルティを無視するというアドバイスは、典型的なWebサイトに当てはまります。 1秒の範囲で複数のページビューでボリュームを取得している場合は、Webサーバーの負荷を軽減するために、必要な場合を除き、必ずPHPをオフにしてください。

セキュリティ

サイトでPHP処理を行うと、Webサイトへの攻撃の可能性が広がります。これは少し妄想的ですが、使用していない場合はPHP処理を停止する正当な理由です。

3
Tim Grant

さまざまな答えが示唆しているように、RL物理ファイル名を区別する必要があります。 URLの最も簡単なマッピングは、ファイルシステムへの直接的なものです。http://example.com/foo.htmlは、ディレクトリ内のfoo.htmlというファイルを指しますが、URLをSEO(または、理想的な世界では、UX )ツールを使用すると、とにかくより複雑なマッピングを使用する可能性が高くなります。

物理ファイル名の選択は、SEOとは何の関係もなく、パフォーマンスとセキュリティのみです。たとえば、http://example.com/foo.htmlscripts/generate_page.php?page=fooに、http://example.com/bar.htmlstatic_pages/bar.htmlにマッピングできます。

他の人が言ったように、PHPでまったく何もしないページでは、PHPプロセスにまったくルーティングしないことでパフォーマンス(および潜在的なセキュリティ)の利点があります。このようなページの物理ファイル拡張子を予約するのが最も簡単な方法です-上記のマッピングを考えると、Apacheにbar.htmlを直接提供するように指示するのは簡単ですが、generate_page.phpをPHPに渡す_プロセッサ。

PHPを使用するdoのページでは、どのファイルがPHPであり、どれがそうでないかを認識するためのツールの構成にかかる時間を短縮できるため、一般的な規則に従う利点があります。他の慣例と同様に、物事が期待する場所にある場合、他の人が将来あなたのプロジェクトで作業しやすくなります。

2
IMSoP

同じドキュメントでHTMLとPHPを混在させる習慣はかなり前に始まりましたが、WordPressなどの人気のあるオープンソースプロジェクトはまだこれを行っていますが、時代遅れの慣行であり、コーディングの観点からは悪い慣行でさえあると考えます。

Googleが気にするのは出力だけなので、明らかにSEOには影響しませんが、コードとプロジェクトの編成方法に大きな影響を与えます。

今日の一般的なフレームワークのほとんどは、MVCデザインパターンを使用しています。モデルビューコントローラー。この設計パターンは、ロジックとビュー/出力を別々のファイルに分けて、コードの保守を容易にすることです。

すべてのHTMLとPHPを単一のファイルにまとめる現在のパターンとは異なり、明確で保守しやすいクラスを使用した、よりオブジェクト指向のアプローチに従います。

追加の利点は、作業している同じファイル内のバックエンドロジックを考慮する必要がないため、フロントエンドプログラマが仕事をしやすくなることです。

0
Marcus Lind