tidy 拡張機能のコードをざっと見てみると、出力バッファー ハンドラーの構成を変更する方法があります。
とはいえ、それは良い方法ではありません。将来のバージョンで明らかに変更される可能性のあるコードの機能を悪用しています。
バッファ処理を処理する関数は、php_tidy_output_handler
1191行目でマクロを呼び出しますTIDY_SET_DEFAULT_CONFIG
。
が設定されていない場合tidy.default_config
、マクロは何もしません。設定されている場合、構成ファイルがディスクから読み取られ、オプションが解析されます。
構成ファイルは出力バッファーの解析中に読み込まれるため、解析が始まる前にPHP スクリプトから構成ファイルを変更することができます。
つまり、tidy.default_config = /file/writable/by/php
このファイルを作成して動的に更新し、必要なオプションを含める必要があります。(私はそれが良い方法ではないと言いました)。
これにはすぐに問題があることがわかります。潜在的な競合状態があります。
2 つのスクリプトが異なるオプションを必要とし、両方が同時に実行される場合、スクリプトの 1 つが間違った構成を受け取る可能性があります。
ファイルは明らかにその場しのぎに変更されるようには設計されていません。オプションはドキュメントに固有であるため、おそらく拡張コードからたどることができるように、構成オプションを挿入するための他の利用可能なパスはありません。
- 新しい TidyDoc が作成されます。
- いくつかの構成フラグが設定され、default_config が読み込まれました。
- バッファが解析されます。
すみません、結局は悪いニュースを伝えているだけのように感じます。
最善の解決策は、ドキュメント オプションを完全に制御できるカスタムの ob_start コールバックを使用することです。
編集:
少しブレインストーミングを行い、これを回避するためにいくつかのことを試みました。すべてが失敗に見舞われました。
スクリプトごとの値を返すカスタム ストリーム ラッパーを登録してみましたtidy.default_config = tidy://config
。ストリーム ラッパーが構成ローダーによって解決されず、これが機能しないことが判明しました。
私が正しくテストできなかったものの 1 つは、ディレクトリごとの構成.user.ini
または[PATH=]
ini セクションです。これらは両方とも CGI/FastCGI SAPI (FPM ではない) でのみ使用できます。これもおそらく役に立たないと思います。