Joomla 3.xをサポートするように拡張機能を更新する際、関数のシグネチャが2.5以降に変更され、_Strict standards
_警告が発生するいくつかのケースに遭遇しました。
たとえばJTableクラスでは、_getAssetParentId()
が
_protected function _getAssetParentId($table = null, $id = null)
{
...
}
_
joomla 3.xでこれを行うには:
_protected function _getAssetParentId(JTable $table = null, $id = null)
{
...
}
_
それは小さな違いですが、警告をスローするのに十分です。
単一のクラスファイルを使用してJoomla 2.5および3.0をサポートする他の拡張機能を見ると、問題を無視しているように見えます。
明らかに、3.xの警告を修正すると、2.5がインストールされ、警告がスローされます…
私たちの選択肢ではない「ソリューション」には、次のものがあります。
この競合をどのように解決しますか?
職場では、すべてのPHP=警告、エラー、および厳密な標準違反)を解決しようとします。このような状況では、シグネチャが異なるため、2つの個別のバージョン固有のクラスを使用してそれを解決する方法はありません。ファイルですが、なぜそれが選択肢にならないのでしょうか。
バージョン固有のクラスファイルは実際に実装するのは簡単ですが、いくつかのコードを複数の場所で更新するため、保守が少し難しくなります。この状況で行う最良の方法、IMOは、オートロード用のすべてのコンポーネントクラスを保持するルートsrc/
フォルダーを用意し、overrides/$VERSION
フォルダーに2.5または3.xバージョン固有のクラスを用意することです。次に、オートローダーをセットアップして、現在のバージョンに基づいて、適切な場所で適切な順序で調べることができます。
もっと簡単な方法があったらいいのにと思いますが、PHPでは、シグネチャを一致させることができる動的メソッドのオーバーロードは許可されていません。
私の知る限り、この厳格な警告を解決することはできません。これは、署名が2.5または3.xで常に異なるためです。
3.xで修正して2.5で無視するか、その逆です。
生産的な環境では、開発設定で厳密な警告のみを表示する必要があるため、この警告は決して表示しないでください。
PHPの状態には大きな問題があり、5.2を使用しているサーバーもあれば、5.3または5.4で安全なサーバーもあります。 5.5で最新の状態を保つものもあります。
これは「何をサポートするか」に大きな問題を引き起こします。さまざまなバージョンの市場を見てみると、5.2が最も広く使用されていますが、安全ではありません。 5.3と5.4はJoomlaが3で探すものですが、ユーザーが5.5の場合、厳密な標準警告は他のバージョンと異なる場合があります。
PHPはエラーでトップを超えませんが、それでもそれが「機能する」ので、その実行方法は現在のバージョンがそれを処理することを意図した方法ではないという警告をまだですが、それでもほとんどの開発者にとって、NoticeとStrict Standardsの警告はほとんど無視できます。1つを修正すると、別のPHPバージョンで別のトリガーをトリガーする可能性があるためです。
それらをすべて削除することは、OCD開発者に最適です。明らかなエラーは修正する必要がありますが、説明したようなエラーはJoomlaを1つに集中させることになりますPHPバージョンを大幅に増やし、PHPバージョンも。
これに対する唯一の真の修正は、Joomlaの「ブートストラップ」でPHPバージョンをテストし、それに基づいてファイルをロードすることです。これにより、Joomlaベースのインストールサイズが2倍になる可能性があります。実際にサイトを壊すことのないエラーについては、さらに作業を行う必要があります。DonGilbertの回答は、これについてさらに詳しく説明しています。
私の答えはちょっと変わっていますが、それは他の人が全体の混乱を理解するのに役立つと思いますPHP is。