プロジェクトでの PHP の使用を無効にする方法を探していinclude_path
ます。
バックグラウンド
おそらく、あなたは驚くでしょう: なぜ私はそのような便利な機能の使用を禁止したいのですか?
残念ながら、答えは簡単だと思いますが、正確に説明するのは簡単ではありません。
簡単に言えば、include_path
(明らかに) package-/library-blind です。
より具体的には、ライブラリの 2 つの異なるバージョンを 2 つのフォルダーに入れることができます。どちらも にありinclude_path
、実行されたコードは両方が混在しています。次の設定を検討してください。
include_path=/some/server/path/lib:
/var/www/apache/htdocs/yourApplication/library
ここで、使用したいライブラリの正規の場所が に/some/server/path/lib
あり、ビルド プロセスによってそこに配置されたが、開発者がその一部にパッチを適用しようとして、誤ってライブラリを に同期させたとし/var/www/apache/htdocs/yourApplication/library
ます。これが起こると想像してください:
/some/server/path/lib/moduleYouWant
'--> A.php (old version)
/var/www/apache/htdocs/yourApplication/
'--> SomeFile.php (uses B.php from module; previously used A.php)
/var/www/apache/htdocs/yourApplication/library/moduleYouWant
'--> A.php (new version)
'--> B.php (new file; uses A.php from module)
突然、あなたのアプリケーションは不思議なことに (あなたのオートローダーがinclude_path
使用する場合、私が知る限り、ほとんどのフレームワーク提供のオートローダーがそうします) 、あなたが行った変更の半分だけを使用または自動ロードします - 新しいB.php
ものではなく古いものA.php
です。
もちろん、他の理由で決して起こらないという理由で、私が説明したセットアップに反対するかもしれません. それは公正です。私も同意するでしょう。たとえば、上記のシナリオは下位互換性のない変更であり、あまり良くありません。
それにもかかわらず、これまでのところ、実際に2回発生するのを見てきました(十分に複雑なプロジェクトでchroot
、水が濁っています)、数え切れないほどの混乱したデバッグ時間が費やされました...そして私はその問題を二度と起こしたくありません. この種の星座ではなく、他の星座でもありません。
PHP が魔法のように自分のファイルを見つけようとするのは望ましくありません。どのファイルをロードするかを特定することを PHP に要求してもらいたいのです。
include_path が必要ない理由
__DIR__
(またはdirname(__FILE__)
古いバージョンの PHP では)、意味的に「相対」パスを作成するのは簡単です。また、ライブ サーバーとテスト サーバーの区別が必要な場合は、絶対位置を定義する定数が役に立ちます。
だから...(および関連する機能)に提供される非絶対パスinclude()
が失敗することを望みます。
2011年のこのスタックオーバーフローの質問は、空白にできないことを教えてくれますinclude_path
。この機能を無効にできる他の方法はありますか? 私の Googlefu は弱いですが、それにもかかわらず、答えは「いいえ (PHP 自体にパッチを適用しない限り)」ではないかと忍び寄る疑いがあります。
コード規約の合意 (または関連する「私が書いたこのカスタム関数を使用しないでくださいinclude()
」)以外でこれを止める方法を誰かが知っている場合は、知りたいです。:)